AMI Firmware Source Code, Private Key Leaked 148
Trailrunner7 writes "Source code and a private signing key for firmware manufactured by a popular PC hardware maker American Megatrends Inc. (AMI) have been found on an open FTP server hosted in Taiwan. Researcher Brandan Wilson found the company's data hosted on an unnamed vendor's FTP server. Among the vendor's internal emails, system images, high-resolution PCB images and private Excel spreadsheets was the source code for different versions of AMI firmware, code that was current as of February 2012, along with the private signing key for the Ivy Bridge firmware architecture. AMI builds the AMIBIOS BIOS firmware based on the UEFI specification for PC and server motherboards built by AMI and other manufacturers. The company started out as a motherboard maker, and also built storage controllers and remote management cards found in many Dell and HP computers. 'The worst case is the creation of a persistent, Trojanized update that would allow remote access to the system at the lowest possible level,' researcher Adam Caudill said. 'Another possibility would be the creation of an update that would render the system unbootable, requiring replacement of the mainboard.'"
Link? (Score:5, Insightful)
I could care less about the security implications. Where's the link to the full key and source code?
There's so much "I told you so" in this... (Score:5, Insightful)
...it's not even funny.
Re:Ok... this chould be bad. (Score:4, Insightful)
And there was much rejoicing.
Why is only the worst case is mentioned? (Score:1, Insightful)
Why is only the worst case is mentioned? This can actually be good and help projects like coreboot support more hardware. Or maybe someone will make opensource fork of their firmware as there is a lot to improve in current uefi implementation.
As for the viruses I don’t think even with the signing key we will not see many bios viruses as it is really hard to write that actually does anything beside bricking the hardware. And on most systems it is impossible to update bios after the os is loaded.
Security Through Obscurity (Score:5, Insightful)
How can you trust what you can never see, or even know is there?
Thesis: Security requires trust.
You are not trusted to know these secrets, therefore you are not secured through their application.
The whole UEFI boondoggle is false security. Worse, this proves that it is vulnerability risk, sold under masquerade, as security.
Re:Keys and source... (Score:5, Insightful)
It might do even better than that! You might be about to create a custom bios image; with the secure boot check deliberately broked to not actually check the boot loader is signed but still return attest that it was.
This could allow you to compromise the DRM all the way up the chain.
Re:So much for SecureBoot (Score:2, Insightful)
There is nothing wrong with SecureBoot, and in fact is a good idea. The problem is security by obscurity. Current SecureBoot implementations are just hoping you never discover the private key. A CORRECT way to do it is to allow custom keys to be loaded by people who have physical access to the machine. If you want Windows to be booted, you load their public key into your secure boot list. If you want to also boot Fedora/Ubuntu/Debian/Redhat, you install their public key. If you want to install a custom Linux, you generate a keypair, sign the binaries, and load the public keys.
Custom Firmware? (Score:4, Insightful)
Like? (Score:2, Insightful)
What did you "tell them"? Since you didn't elaborate I fail to see what you are going for or how this is insightful.
I can only guess this is something along the lines of the people crying about "Waaaaa security through obscurity!" in which case I want to hear their solution to code signing/verification on a system that doesn't involve a secret private key. You might note that public/private key signing is how Linux distros secure and verify their application distribution services.