AMI-Bios Sourcecode and UEFI Signing Key leaked? | Hacker News Reader

AMI-Bios Sourcecode and UEFI Signing Key leaked?

adamcaudill.com

93 pointsmablae43 comments

I admit that I have no idea at all about all that UEFI signing stuff, but the only thing in the "Keys" directory that does not look completely like random data is this, and "DO NOT TRUST - AMI Test PK0" looks more like something I'd distribute among my development team for testing, but would definitely not be the real thing:

$ strings Ivy_Bridge_018s/Keys/Variables/db

4}7Ve 0%1#0! DO NOT SHIP - AMI Test KEK0 110823215243Z 120823215242Z0%1#0! DO NOT SHIP - AMI Test KEK0 (...)

$ strings Ivy_Bridge_018s/Keys/Variables/KEK

4}7Ve 0%1#0! DO NOT TRUST - AMI Test PK0 110823215221Z 120823215220Z0%1#0! DO NOT TRUST - AMI Test PK0 (...)

$ strings Ivy_Bridge_018s/Keys/Variables/dbx

4}7Ve 0.1,0* #DO NOT SHIP - Microsoft Test KEK CA0 110506224835Z 121106224834Z0+1)0' DO NOT SHIP - Microsoft Test KEK0 (...)

$ strings Ivy_Bridge_018s/Keys/Variables/PK

4}7Ve 0%1#0! DO NOT TRUST - AMI Test PK0 110823215221Z 120823215220Z0%1#0! DO NOT TRUST - AMI Test PK0 )MCn D5g( (...)

Asymmetric keys do look like lots of completely random data. What you've found is likely some kind of fingerprints (hashes).

If there are indeed some keys on this server they could be real, after all this code wasn't supposed to ever go public.

Yes, but you'd expect the key (Keys/FW/.priKey) to be accompanied by some useful metadata (naming the entity the key belongs to, and a certificate from microsoft validating the key) to be added to the firmware image, wouldn't you? And if there's only certificates containing "DO NOT USE" text?

But certainly, I have no idea about all that. If someone could post commands how to verify (or at least dump) connection between DER encoded RSA keys and the PK/KEK/db/dbx files (which seem to have a 40byte header, then, again DER data)... that could shed some additional light on these matters.

There'd be no reason to expect the firmware signing key to have any relation to any of the certificates used in Secure Boot. They're used for separate purposes.

You may have to remove the === BEGIN/END blah === header and run the result through 'base64 -d' first.

     openssl asn1parse (-text or -dump I forget) -inform (pem or der) -in [filename]

The private key should list 'P', 'Q', and the 'modulus'. If the modulus is the same as in the public key, it's the same.

Those are certs. The private key is in /018s/Keys/FW/.priKey

and starts with:

    bash-3.2$ hexdump .priKey | more
    0000000 30 82 04 a3 02 01 00 02 82 01 01 00 ed 71 d6 3f
    0000010 21 ff 0b 45 63 a4 3d 87 1d 22 44 8f c9 b5 84 08
    0000020 29 5b 59 dc 0f 30 d2 a9 4f 52 e1 f2 97 51 0b b5

It's more readable with

openssl rsa -inform DER -in Ivy_Bridge_018s/Keys/FW/.priKey -text

But still, I don't know how to verify that this key is not the one refered to by the "DO NOT USE" certs (which, to me, sounds pretty reasonable to assume).

You are right. This could mean that the key just works on developer boards and is not the one used in production.

>If the code was old, as it’s been when products like Symantec’s were leaked, this might not be so bad - but it’s not.

>http://adamcaudill.com/files/Screenshot_4_4_13_10_04_PM.png

>References in the files indicate that the code is from sometime in February - so this is current code.

Given that that image shows dates in 2012, I think the author has made the classic mistake many of us make at the start of the new year, of still thinking it's the old one.

For firmware, 2012 is actually very new. I don't think manufacturers change the versions too often, even on firmware updates - they usually maintain/patch the original firmware (the version that was used when the hardware launched). A motherboard released in 2012 probably has an older version of firmware than the leaked one.

Microsoft's requirements for Windows 8 certified firmware continued changing until surprisingly far through 2012. Code from early 2012 wouldn't satisfy it.

I don't see how BIOS signing could be really that important.

BIOS flash must be write protected in silicon before the OS boots to prevent flashing by pwned kernel or drivers so we can assume that only BIOS setup application can touch BIOS flash. Flashing inside BIOS setup application can be prevented by password. And if somebody has physical access to the motherboard to reset this password it's game over anyway.

Call me when somebody leaks something interesting or useful like the Secure Boot private key of Microsoft.

Usually there isn't much protection, if you have root on a system.

On an infrequent basis I've used Flashrom (http://www.flashrom.org) to burn new system BIOS's into flash on a running Linux system. Much easier than fiddling with DOS boot disks, etc. Thus, anyone who can exploit to root could theoretically reflash the BIOS in a system with code that would be persistent through OS reinstallations. Personally, I'd focus on the PXE ROM if asked to compromise systems in this way.

Some older systems have jumpers on board that can write protect the BIOS, but frequently they either default to being in the writable state. I haven't noticed these jumpers on modern PC hardware for a while.

This isn't unique to UEFI Secure Boot systems - I'd assume once you're in OS, all bets are off in terms of who can do what to the hardware.

I'm talking about really secure systems, although I'm not sure if such exist in real world.

If we take BIOS security seriously, access to BIOS flash must be restricted to BIOS setup application, for example by programming some non-resettable "write protect" bit before booting the OS.

Corporate espionage rarely rises to this standard, which was the author's concern.

Dumpster diving seems to be the high point, if Larry[1] is anything to go by.

At least this is what people have be caught doing!

[1] http://www.time.com/time/magazine/article/0,9171,49039,00.ht...

>I'd assume once you're in OS, all bets are off in terms of who can do what to the hardware.

A common misconception. Even if you are running as ring-0, there are things that you cannot do, and only BIOS can. For example, executing code in SMM mode, mapping/hiding portions of memory, or changing some PCI configuration options that get "locked" after BIOS.

Sounds like a chicken/egg scenario if you're able to reflash the BIOS arbitrarily.

>Flashing inside BIOS setup application can be prevented by password.

That is disabled by default. Most likely the BIOS checks this signature before booting or flashing itself, no difference if you are root or not. It IS useful for a bios rootkit. The private key of Microsoft would be useful for a regultar boot-sector rootkit.

[now this comment became much too long and rambling... ;-) ]

Regarding erase/write protection of flash-memories:

Besides the actual user-acessible bulk-data, a flash-chip typically has additional configuration data that store write-protection of the whole device or parts of the memory (pages). This protection typically is done so that the device is not accidentally overwritten by a misbehaving program (e.g. a process in kernel-space writing randomly to addresses).

Take for example the Intel 28F128[1] (128Mbit) which will appear as a 16bit wide memory on a processor's address/data bus (or some version interfaced to the processor by the northbridge, the details can be found in the AMI Bios sourcecode :-) ). Normally you only read the addresses the flash is mapped to, and you will get your stored data (called "read matrix" mode).

But to make the flash do something special, like identifying itself, executing erase-commands, protecting or un-protecting sectors, you will write some special word to its "command" address: Subsequently the flash will no longer output the stored user-data on reads to its address, but rather whatever the chosen command defines.

For example to identify the flash according to the CFI specificytion, you write the data-value 0x55h to the flash-address 0x98[2], then you will no longer read out user-data, but information about the flash-chip, the manufacturer, timing, ...

To see how that works, you can have a look at the code in u-boot, a pretty common bootloader for arm-, m68k- or mips(?) devices[3], e.g. write_buff() in line #1313, flash_Erase() in #1049. The feature for "write protecting" pages in the 28F128 is called locking/unlocking the data-sheet. "Protection" in the datasheet refers to a different mechanism.

Also the 28F128 _does_ _indeed_ have a hardware write-protect pin (called #WP), and this might be connected to a jumper, or to a GPIO pin as a added layer of protection. But I haven't seen that being implemented "in the wild", at least in embededd devices.

So the only thing a application needs to flash your BIOS is typically a mapping of the processors address/data-bus to the flash-chip, and access to these addresses, either directly from a driver running in 1:1 mapped kernel address-space or mmap()-ed to user-memory. That's how the typical butt-ugly flash-program running directly under Windows7 does it.

(and yes, I know, some devices nowadays employ a mask-programmed mini-loader that loads the 2nd-stage bootloader e.g. from a serial memory, or a mmc/sdcard, as parallel flash such as the 28F128 is a little outdated already)

[1] http://media.digikey.com/pdf/Data%20Sheets/Intel%20PDFs/28F1...

[2] http://wayback.archive.org/web/20090306191719/http://www.jed...

[3] http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mtd/cfi_fl...

My point is that to secure the BIOS you must latch this WP bit after the "press whatever to enter setup" message is gone and you must not accept SWAWARD as wildcard password.

If you fail at these, your system is insecure even in presence of BIOS signing.

If you implement these properly, your system is secure even without BIOS signing.

Ergo, BIOS signing is pointless as a security measure and author's whining about this leak putting users at risk is unjustified.

Well, BIOS flash tools would work in this case by flashing the new BIOS on reboot using a feature of the existing BIOS, which is when the BIOS signature would be validated.

"so we can assume that only BIOS setup application can touch BIOS flash"

Nope. Intel (at least) let you program the flash controller so it'll forbid writes from the OS but permit writes from System Management Mode. Load the firmware into RAM, hand a list of addresses to an SMM trap and wait for it to flash it. Entirely secure, as long as you're using signed images.

How is non-SMM code prevented from doing the same stuff this SMM routine does?

The flash controller knows if you're in SMM or not.

Source appears to be ftp://fxp.jetway.com.tw/CODE/

Looks down for me now.

Not down. Also, information is still there (16:15 GMT).

The hostname is still not resolving for me. I've tried from both my office connection and my home.

I'm in Bath (England). Anybody else finding it won't resolve?

Try replacing the fxp with FTP ;)

Oh, man. That was stupid of me :)

"You have logged in for maximum times. Connection closed."

Coming to your favorite torrent tracker soon.

It seems that something triggered rate-limiting of anonymous logins.

Now it has a password. Oh dear, I'm depressed I've missed out on this. The FTP server appeared to have quite a few interesting things on it (for example, a folder called "Samsung ARM").

Anonymous ftp still works, it's just hitting the maximum connected user limit. Better to use an FTP client than the browser as it will persist the connection.

So, what is the magnet link?

from the article: "This kind of leak is a dream come true for advanced corporate espionage or intelligence operations."

i disagree. this is banal stuff for "corporate espionage or intelligence". they have that and more for ages. no data that has a price is private.

what is interesting is that we could now have a decent open sourced BIOS implementation. ...Maybe if someone in china or other country with less software copyright starts the project we all can contribute?

This is not the first BIOS source to leak (Award BIOS 6 code leaked 10 yrs ago, am sure still available in your fav torrent tracker). Opensource code will certainly not make use of this leaked implementation, it is asking for trouble.

IBM published a technical reference manual for the PC which included (among other things) a complete commented source code listing of the BIOS.

Anything which involves a company rather than an individual keeping a secret is a crock of shit as far as security goes.

The story's been updated with information from AMI - it sounds like the keys are only intended to be used for testing purposes and should be changed before use, but it's obviously possible for vendors to ignore that advice.