AMI Firmware Source Code, Private Key Leaked
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.'"
I could care less about the security implications. Where's the link to the full key and source code?
Samsung took back my unlocked bootloader because Google wants me to rent movies. They're both evil.
...it's not even funny.
Bad? Part of the UEFI barrier for other OS's has just been Open Sourced.
And there was much rejoicing.
We should learn what we need to know about issues, before we decide what we need to feel about them.
Actually, yes it can.
"“By leaking this key and the firmware source, it is possible (and simple) for others to create malicious UEFI updates that will be validated and installed for the vendor’s products that use this Ivy Bridge firmware,” "
It will allow those with secure boot, that is on and has no user visible way of shutting it off. Because every extra option in a uefi/bios costs system builders like dell and hp money. a way of disableing it by flashing a bios,uefi image with that option or it permanently set to off.
Assuming for a moment that the validity of this key is confirmed independently then any further question about the technical feasibility of using this to sub/pervert a Secure Boot arrangement is moot when you consider the deeper and more practical implication which is that you can't trust a major motherboard vendor to keep a signing key properly secured. Secure Boot is dead, long live security.
Regards, Phil
It will allow those with secure boot, that is on and has no user visible way of shutting it off. Because every extra option in a uefi/bios costs system builders like dell and hp money. a way of disableing it by flashing a bios,uefi image with that option or it permanently set to off.
Did you write my stereo instructions in the 1980s?
The road to tyranny has always been paved with claims of necessity.
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.
"Flyin' in just a sweet place,
Never been known to fail..."
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.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
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.
I'm hoping we're about two years away from a real PC motherboard initiative along the lines of Raspberry PI. Wouldn't that be nice? A motherboard that isn't infected with vulnerable OEM black boxes and proprietary BS code and OS lock-in?
The basis of your whole rant was that Microsoft invented this technology, but you were wrong. I suggest that you go read up on the UEFI before you start making these sorts of proclaimations. The standard was originally developed by Intel, not Microsoft, and they contributed the initial version to the UEFI Forum (which includes reprentatives from ten other companies other than Microsoft on their board).
I have no doubt that you will consider me to be a "Microsoft stooge" for pointing this out.
Would it be possible that more ambitious/less sinister programmers and/or modders could create a highly customized firmware or BIOS that allowed for more options? I guess I see a positive outcome to any leaked source code rather than the negative weaponry most people imagine.
Libera te ex Inferis!
md5sum Downloads/018s.zip
4ebc77526c2ea7c0387cc993252e682b Downloads/018s.zip
md5sum 018s/Keys/FW/.priKey
198e238540b93095f02ee763bdadba86 018s/Keys/FW/.priKey
There are no American tanks in Baghdad. The situation is completely under control.
I was promised a flying car. Where is my flying car?
Or a piece of malware will now sign itself and change the keys making it impossible to remove. It would be better totally unlocked otherwise. If the keys were in ROM where they could not be rewritten then yes there will be much rejoicing but who is to say the malware wont reimage itself in the UEFI and put another set of keys maybe randomly generated on the host?
You mean like a root kit? That's only existed for forever, and UEFI has been shown to be infeffective in the real world at stopping them. So your illusion of security was shattered. Pick up your hat and move on ... designing a more workable security scheme.
We should learn what we need to know about issues, before we decide what we need to feel about them.
A rootkit in a non signed way is impossible on UEFI unless you disable it by default.
However if it is signed and the AV software does not have the access to it then you are fucked. It is an OS reinstall. Worse if it uses the keys to reimage the rom then it is bricked.
http://saveie6.com/