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.'"
Re: (Score:2)
No.
Re:Keys and source... (Score:4, Interesting)
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.
Re:Keys and source... (Score:5, Funny)
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?
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: (Score:1)
Care to elaborate a little?? Please?
Re: (Score:2)
yes, on systems where you can boot anything you want anyways! HAHA
Ok... this chould be bad. (Score:1)
Re: (Score:1)
And this also could be great. Like everything, 90% of firmware sucks. Unlike most other software, replacing the firmware usually isn't even close to an option, and I loathe almost every single hardware company as a result of this.
Re: (Score:2)
Unlike most other software, replacing the firmware usually isn't even close to an option If you do some research [coreboot.org] before buying a new main board its a lot closer.
Re: (Score:2)
Of course, considering the selection of coreboot applicable hardware is extremely limited and mostly ancient...
Re:Ok... this chould be bad. (Score:4, Insightful)
And there was much rejoicing.
Re: (Score:1)
No it hasn't. You're not going to be able to use this to bypass UEFI secure boot even on AMI hardware let alone it being applicable to hardware at large.
Re: (Score:1)
Bad? Part of the UEFI barrier for other OS's has just been Open Sourced.
And there was much rejoicing.
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?
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:1)
So that means we are right back to where we started in the first place. UEFI is useless at best, burdensome and unfair for people wanting to add/change the OS at worst.
Time to toss it.
Link? (Score:5, Insightful)
I could care less about the security implications. Where's the link to the full key and source code?
Re: (Score:1)
Something tells me the admin of AMISource.com [amisource.com] is about to have a bad day!
Re: (Score:1)
Just out of curiosity I would love to have a look at their code. I am sure it will appear in piratebay soon.
Anybody knows if it is illegal to download it and have a peek at it?
Re: (Score:2)
To me it seems the same as having Marijuana seeds or spores of a psilocybin mushroom. It's perfectly legal to be in possession of them. However, if you attempt to start growing them, it's your ass.
Bad analogy?
Re: (Score:1)
Unauthorized access to a computer, computer network or network resources is illegal in the United States of America.
No matter what anyone tells you, it is never actually legal for you to steal from someone else.
Re: (Score:2, Informative)
THEN CARE LESS.
The phrase is "I couldn't care less", you troglodyte.
Re: (Score:1)
Roger. It's not an oversight or a mistake on my part. I prefer to say it that way.
I also sometimes say "I give a damn" too.
Because that's the way how I roll.
Re: (Score:2)
Well, I couldn't care more about your off beet phrasing.
Re: (Score:2)
I did not expect that level of frankness to turnip in a slashdot thread.
Re: (Score:2)
Well, I could care less about this those who couldnt care more, and couldnt care less about those who care more.
SO THERE !
Re: (Score:1)
Seig hail to our new Sintax Nazi Overlord
Re: (Score:1)
oh for the irony...
Re:Link? (Score:4, Interesting)
There is nothing wrong with being on "wife support", assuming she can afford to keep you. Change your title to "home maker" and think of it as an opportunity.
My husband stays home with our kids building block towers and signing about the letter A all day. There is actually a growing community of stay at home husbands, and if you think about it, it is really the next logical step towards equality. If we want women to have the option to go out and earn a 6 figure salary, then we need to be willing to let men stay home and feel proud about it.
If you have no kids to raise, then take the opportunity to reinvent yourself. Start a non-profit. Make soda can sculptures that you can sell at your local craft show. Volunteer. These are the things we expected and praised women for doing and there is no shame in men doing them to.
So pick up your head, take pride in the fact that you have a loving, supportive wife, and turn this into an opportunity. The value of a man, or woman, is not measured solely by their income, but rather how they work to better others.
Re: homemakers (Score:2)
Re: (Score:2)
Trust me you'd feel a lot worse if she thought like you and just gave you the boot because you were unemployed.
Re: (Score:1)
From one of the features FA:
"I’ve contacted both the vendor involved and AMI to alert them to the issue. Obviously, I won’t be releasing the name of the vendor, the FTP address, or anything that was seen on the server."
Maybe we won't see it ever :(
Re: (Score:1)
We shouldn't believe him then. The old 'tits, or GTFO' applies. In fact, it sounds like attempted extortion.
Re: (Score:1)
Yeah, that's right, he's going to post a threat online.
Gee, that's a nice BIOS you get there. It'd be a shame to see anything happen to it.
Re: (Score:1)
*ahem* http://www.mmnt.net/db/0/0/ftp.jetway.com.tw
Re: (Score:1)
http://pastebin.com/LFGhmfS9
Better Writeup (Score:2)
This has the link, but that'll do you no good [virustracker.info] at this point.
In related news, I'm more interested in buying an AMI motherboard now. Especially one with CoreBoot flashed over it.
Re: (Score:1)
So you are more interested in purchasing something malware writters who now know the keys to sign their malware as a rootkit making it impossible to remove?
Re: (Score:2)
Only one of my machines now has a BIOS that's signed (UEFI). The risk of a dangerous flashing malware is just the same as it has been since the early 90's, no?
I always seem to have to reboot into DOS to actually flash when I want to, though. If there's a general way to flash a BIOS from linux, I'm interested.
Re: (Score:2)
The risk of a dangerous flashing malware is just the same as it has been since the early 90's, no?
No. This key is still not public, so it still requires the hacker going after you to guess an incredibly long number of bits correctly in order to fool your system into thinking it is valid.
Your BIOS's from the 90s did basic checksum tests that were designed for detecting corruption, not intentional modifications. They use basic CRC32 type of checksums, trivial to fake with simple modification of any 4 bytes in the file, which you can determine with a single simple function as they weren't designed to be
Re: (Score:2, Flamebait)
I runz the Linux!
I runz the Coreboot! [coreboot.org] ftfy
linux in bios just got even easier (Score:1)
Besides all the gloom and doom, I can see a use case for this. someone tell coreboot.org? it would make updating your (ami)bios with embedded linux a bit simpler, eh?
There's so much "I told you so" in this... (Score:5, Insightful)
...it's not even funny.
Re:There's so much "I told you so" in this... (Score:5, Funny)
C'mon, it's a little funny.
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.
Re: (Score:2)
Sorry for the delay, I forgot that I commented here.
I think this is what you're looking for: http://en.wikipedia.org/wiki/Trusted_Computing#Criticism [wikipedia.org]
Re: (Score:2)
Untrue. I laughed briefly before I started crying.
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.
So much for SecureBoot (Score:2)
What a waste of time.
Re: (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 Linu
Re: (Score:2)
Everything is wrong with secureboot.
Look, all we need is a simple BIOS option to that allows users to enable OS installs on next boot. When active it could flash part of the BIOS with the OS boot loader. FUCKING DONE. The OS will then be able to boot immediately, and can kick off it's own security chains to validate the rest of the kernel / etc. Use public key crypto in the "early kernel" loader and the existing firmware OS code can verify signatures of new kernel updates without being beholden to s
Doh (Score:1)
'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.'
It's safe to assume the latter, as malware commanders don't want the computer offline or under scrutiny. Just give them another vector to attack and easier ways to cover up the bot.../p
NOTHING IS LEAKED (Score:2)
Re: (Score:1)
Re:NOTHING IS LEAKED (Score:4, Informative)
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.
Re: (Score:2)
Re: (Score:3)
The basis of your whole rant was that Microsoft invented this technology, but you were wrong. I suggest that you go read up on [wikipedia.org] the UEFI [uefi.org] 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.
Re: (Score:1)
Re: (Score:2)
The basis of my rant is that this technology is a DRM, causes problems for all non-MS participants,
That is your unsupport assertion that this is just about DRM. The PDF that your linked to does actually say that there are benefits to secure boot, something that you have conveniently omitted (to coin your phrase).
Microsoft controls this technology (by controlling key distribution) and Microsoft has already abused its control.
And yet it is the OEMs who control the platform keys, or so says your document. There is no reason why you couldn't have an OEM that actively supported open source operating systems by including their required keys (just like they provide Linux drivers now). Or you just switch off secure boot.
Regarding UEFI itself: yes, Intel designed original version of it but it was Microsoft who forced additional requirements [ozlabs.org] that made Secure Boot such a pain.
I'm
ftp.asus.com.tw (Score:1, Funny)
If Adam Caudill won't disclose it then I will.
ftp.asus.com.tw [asus.com.tw] (which is currently down)
Implication to secure boot... (Score:5, Interesting)
Re: (Score:2)
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.
All hail our Moot Boot overlords.
... are probably none (Score:2)
Re: (Score:1)
...they may have made some implementation faults that will allow an attacker to falsely keep their checks happy while still modifying boot files.
Well that to.
The key is probably only useful for signing firmware, probably only for this vendor and possibly only for this chipset, maybe even a single main board.
TFA implies it was for "Ivy bridge" so yeah probably tied to chipset, maybe multiple boards but the point is they've demonstrated something arguably close to gross incompetence, misplacing source code is careless, misplacing the signing key is a different league. This is a commercial product how hard would it be to have the key in two parts, held by two individuals on the dev/release team?
This system is built purely on trust and its gone, I mean, yeah "I'm sure they'll be more careful next
magnet link (Score:1)
magnet:?xt=urn:btih:bd8b50ebfc73b4f0ea53bda4f7f6a1861b1eb19c&dn=leaked%5Fbios
Two years (Score:3)
More specific details (Score:1)
Posting as AC for hopefully obvious reasons. I discovered the server while Googling for some obscure AMD datasheets and passed the information off to Mr. Wilson. Not going to provide the exact domain name of the server, but it's operated by Jetway.
In addition to this BIOS code, it contains what appear to be full design files for a few motherboards (Gerbers, schematics, test software) and a number of datasheets (with prominent CONFIDENTIAL watermarks) for chips made by Nvidia, Intel, Atheros, Realtek and oth
Re: (Score:2)
Sounds like a Kevin Mitnick wannabe got his cache discovered...
Custom Firmware? (Score:4, Insightful)
Re: (Score:2)
Possible? Yes. Likely? That's somewhat less clear.
Did it include the build environment also, or just the raw source? Does the source match up with your chipset VERY closely (if not, do you have long road ahead)?
When compiling a Jasper Forest BIOS for example, there is:
1. Source for the Jasper Forest family of CPUs (which is different than the source for all other familes)
2. Source for any BIOS-supported ICs on the system which differ from Intel's reference design (perhaps you have a different super I/
Re: (Score:1)
the best case (Score:1)
Re: (Score:1)
No, never trust upgradable bios. Put the damn chip into a socket, and do upgrades by snail-mail... The internet will never be safe. Which is a good thing, because I don't want anybody telling me what I can upload or download.
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: (Score:1)
The whole UEFI boondoggle is false security. Worse, this proves that it is vulnerability risk, sold under masquerade, as security.
The dogs are always hungry.. This is just part of the show.
Re: (Score:1)
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.
UEFI is a replacement for BIOS. It has many features that let us deal with hardware that BIOS couldn't provide. UEFI is not a boondoggle, nor is it about security.
Re: (Score:1)
Either way, something that can brick your machine so easily with software shouldn't be soldered to the board.
Re: (Score:1)
Either way, something that can brick your machine so easily with software shouldn't be soldered to the board.
UEFI isn't causing bricking any more than any BIOS chip in the past has.
You may as well argue against memory controllers being integrated into CPUs or any northbridge/southbrdge chip being soldered onto a motherboard.
Re: (Score:1)
UEFI isn't causing bricking any more than any BIOS chip in the past has.
No? [slashdot.org].. Okay...
You may as well argue against memory controllers being integrated into CPUs or any northbridge/southbrdge chip being soldered onto a motherboard.
Not really. I've never heard of software being able to brick anything through them..
Re: (Score:2)
And its not the first time a machine has failed to boot due to bios bugs. This is not something new to computers DUE to UEFI, it is in fact the same thing we've been dealing with for over half a century. Bugs exist.
Re: (Score:1)
The whole UEFI boondoggle is false security.
That statement alone proves you actually have no idea what you're talking about and are just repeating someone elses headline.
Whats better is that slashdot has modded you up, showing how the crowd here has become just as ignorant. You might as well say
The whole Linux boondoggle is false security
That makes same amount of sense.
Let me give you a hint. UFI isn't the issue, your ignorance is. You are referring to a protocol known as secure boot. It does not require UEFI and works on other systems as well. You really need to get a clue if you want
Re: (Score:2)