AMI PC firmware upgrade scare: The global security meltdown that wasn't

Analysis A computer hardware maker that leaked the source code to American Megatrends Inc's PC firmware did not reveal private keys for signing firmware updates - contrary to early reports.

The blueprints for AMI's UEFI firmware were found by a security researcher on a wide-open Taiwanese FTP server along with what appeared to be sensitive code-signing keys.

The firmware is typically stored in flash chips on a computer motherboard and is the first piece of code to execute when a computer is turned on: it kickstarts the hardware and boots the operating system.

For security reasons, new versions of the firmware can only be installed if they are cryptographically signed by the motherboard maker's private key. This ensures only software issued by the manufacturer is loaded. The firmware checks the update is appropriately signed before committing the new data to chip. There's more information on this process here [PDF].

Any miscreant with this private key could therefore sign his or her own malicious firmware and permanently install it on a victim's machine by tricking the user or compromising the PC. This malicious code runs underneath the operating system, and could therefore set itself up to spy on everything the user does without being spotted.

It was feared the signing key for AMI firmware upgrades for the Taiwanese vendor's motherboards had been leaked, sparking a global security scare, but AMI insists the key is a dud.

Security blogger Adam Caudill and his research partner Brandon Wilson first stumbled across ‪AMI‬'s UEFI (Unified Extensible Firmware Interface) source code, the key and a cache of internal documents late last week, and blogged about it. The data was later distributed as a torrent by a third party, and the code dates from February 2012 according to comments in the source.

The information was found on a public server operated by an unnamed AMI customer in Taiwan, and not by AMI itself. The signing key exposed in the "Ivy Bridge" archive is a default test key, we're told.

AMI - which supplies its AMI UEFI firmware to PC and server motherboard makers - instructs customers to change the dummy key before building the software for a production system. However it's unclear whether or not the customer followed this advice and the wide variety of other sensitive information - internal emails, various system images, private specification sheets, Excel documents and more - hardly inspires confidence.

"Assuming the vendor was following AMI’s instructions, the private key found on the vendor’s public FTP server should have little practical value; though how this vendor was handling keys isn’t known, so the usefulness of the key is also unknown. There is also the possibility of other AMI customers violating AMI’s instructions. We know we have a key; we don’t know how it’s been used," Caudill wrote in an update to his blog post.

"Publicly revealing the source code still has some potentially interesting implications, even with the assumption that the vendor was following AMI’s instructions on key handling. As this code may be under additional scrutiny from researchers, it’s likely that new flaws will be found that would have been missed otherwise," he added.

'The ability to create a nearly undetectable hole is ideal'

"This kind of leak is a dream come true for advanced corporate espionage or intelligence operations. The ability to create a nearly undetectable, permanent hole in a system’s security is an ideal scenario for covert information collection," Caudill warned.

AMI played down the potential impact of the problem by saying "this is not a general security threat which could 'create a nearly undetectable, permanent hole in a system’s security' if the manner in which production-level BIOS is signed and created uses a production key."

"AMI has examined the security keys referenced in the blog post and confirmed that the keys in question are test keys," it said in a statement. "Test keys are normally used for development and test purposes since developers do not have access to production keys. For production-level BIOS that would be shipped to consumers, AMI’s procedures for creating such a BIOS require the customer to procure or generate production keys. As such, AMI expects that a key such as the one disclosed to the public today will be used for testing purposes only."

The leaked test keys can't be used to derive production keys, so there ought to be no effect for systems in the field, according to AMI.

Subramonian Shankar, American Megatrends chief exec and president, added: "AMI would like to reassure its customers and partners in no uncertain terms that this should not be a security concern for them. If they follow standard operating procedure for BIOS signing, the security features in our BIOS source code and secure signing process will function as designed and remain 100 per cent secure.”

The problem doesn't entirely stop there, though: the leak of AMI source code is problematic for the company because it exposes its intellectual property. It also exposes the code to scrutiny by bug hunters. This is something of a mixed blessing for ordinary punters: someone who finds a flaw could report it to AMI to be fixed, or exploit it. AMI partners and worldwide firmware customers are advised to get in touch with their AMI sales rep or AMI technical marketing. ®