AMI UEFI BIOS source code leaked

[Mumak]

An FTP server in Taiwan that could be publicly accessed, leaked the source code of AMI Aptio UEFI BIOS, including AMI's unique UEFI signing test key. The utterly irresponsible act of holding such sensitive data on public FTPs is suspected to be committed by motherboard vendor Jetway. In doing so, the company may have compromised security of every motherboard (across vendors) running AMI Aptio UEFI BIOS. Most socket LGA1155 and FM2 motherboards, and some socket AM3+ motherboards run AMI Aptio.

Among the leaked bits of software include the source code of AMI BIOS, Aptio, and AMI's UEFI test signing key, which is used by all its clients to sign their BIOS updates. Signing ensures that BIOS updating software verifies the update is genuine, and coming from the motherboard manufacturer. With this key out, malware developers can develop malicious BIOS updates, hack motherboard vendors' customer support websites, and replace legitimate BIOS updates with their malicious ones. Control over the system BIOS could then give hackers access to most ring-0 OS functions.

"By leaking this key and the firmware source, it is possible (and simple) for others to create malicious UEFI updates that will be validated & installed for the vendor's products that use this firmware. If the vendor used this same key for other products - the impact could be even worse," writes Adam Caudill, who along with Brandon Wilson, discovered the open FTP server. "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," he added.

- To clarify, the ‘vendor’ I refer to is a customer of AMI; it is this customer’s public FTP server that exposed this information.
- Per AMI, the signing key included in the ‘Ivy Bridge’ archive is a default test key; AMI instructs customers to change the key before building for a production environment. It’s not currently known if the customer was following recommended practices.
- The ‘Ivy Bridge’ code was unmodified, meaning that the customer had not made any alterations to this specific copy.

Source: Adam Caudill's Blog

Leaked by: Jetway
Contains source code for: Luna Pier, Cedar Trail, Sandy Bridge, Ivy Bridge platforms
Includes proprietary Intel Restricted Secret + SLA stuff
A lot of people won't be happy...

[NEOAethyr]

I found the ftp but it's now pass protected.
Supposedly there's another ftp of jetway's that still has it and isn't protected, I don't know.
I found a torrent.
Getting it now.
AND thanks very very much for sharing this info with us .

http://www.torrenthound.com/torrent/...f34f64b44180c3

[TuKo]

<dreammode> hack our bioses and give us access to all these disabled cores</dreammode>

[zalbard]

Very cool, I wonder what modders can come up with!

<dreammode> hack our bioses and give us access to all these disabled cores</dreammode>

Haha, don't think it's up to BIOS

[NEOAethyr]

It would be cool if you could unlock intel's via the bios...
Who knows, the src would have to be looked through to find out.

I quickly glanced through some of the files.
There's some asm post code in there, oddly there's a feature for using a custom boot logo file from a usb stick.
Or maybe not I don't know yet.

Anyways the post code I saw, it might be possible to start de-compiling the code and writing it out in fresh asm files to be compiled with fasm.
I hope there's code in this thing to tell me what sort of compression they use on there modules, I couldn't figure that out before.
While award uses lzh compression, the ami's I have no clue what they use.

In linux, it says my iommu and virtual stuff isn't setup right in the bios.
I tried xen but it crashes on startup, but then again the error I get others get too so :\.
That's something I might need to fix if it turns out that xen won't work after my 1st prob is fixed.

There's probably plenty to play with if this stuff can be sorted through.
The award bios src code, I've got 2 diff leaks of, was extremely helpful back in the day.
I'm pretty happy to finally get my hands on the src for ami.
Though to be honest, I'm not really in the mood to mod this old bios, I'de rather play with the efi where's there's already stuff to boot exe's and external efi roms.

I'm still waiting on intel though for the freaking chips to come out and new boards .
Which reminds me, back when intel had nvidia chipsets still, they also still had there own romsip code.
I may have to track one of those bios'es down to find it again, then scan for it in the ami modules in a newer board.

I'm gonna scan through it tonight, I've got the leaked files.
I just wish there were more, like amds ver's, maybe it's in there somewhere...
But anyways they all look like intel bios setups that were leaked.

I'de better learn smbus code, if I really want to get back into modding bios'es, I'll need it for storage, need to access the cmos chip directly, those things are at least 64k in size, way larger then 256 bytes of cmos code and the 8 or so cmos profiles you can save in there.

[zir_blazer]

It would be cool if you could unlock intel's via the bios...
Who knows, the src would have to be looked through to find out.

Chances are that if this is possible, it is done thorough microcode. And microcode is a beast on its own.

In linux, it says my iommu and virtual stuff isn't setup right in the bios.
I tried xen but it crashes on startup, but then again the error I get others get too so :\.
That's something I might need to fix if it turns out that xen won't work after my 1st prob is fixed.

Check this Thread. I sended AMD a E-Mail support ticket regarding IOMMU virtualizacion support on Fusion platform 3 weeks ago and still didn't got a reply about this, only an automatic reply 24 hours after I sended it saying it was sended to a higher support level.


I suppose that open source BIOSes projects like CoreBoot would get the most out of it, as not every manufacturer provides them with documentation about some parts. If they need anything that is in this source code, instead of reverse engineering binaries, they can peek in the original stuff.

[Utroz]

Nice!!! Now let the custom bios production commence....

[Mumak]

Don't expect too much from this leak. I haven't yet checked the entire package, but it seems to be a reference AMI package (though a nice one ).
Particular mobo BIOSes need special customizations.

[ajaidev]

Ohh crap this is very serious stuff people already need to do a billion security related things in regards to access and all it does is increase overhead

Work computers full of bloatware well Intel bloatware and the IT security manager thinks he is the freaking Godfather.....

[AMDforME]

This could cause a lot of problems and is very bad of Jetway.

Check this Thread. I sended AMD a E-Mail support ticket regarding IOMMU virtualizacion support on Fusion platform 3 weeks ago and still didn't got a reply about this, only an automatic reply 24 hours after I sended it saying it was sended to a higher support level.

It appears to me that AMD farms out their Tech Support so you may need to follow-up again to get it kicked to in-house where someone with a clue can respond.

[Tuvok-LuR-]

I imagine Norton Bios Security will be available soon

[WangChung]

Exactly, let's hope their mistake is a boon for the modder community.

[Scorpio[pt]]

Am I the only one who thinks this is a terrible mistake . its on amateur level to have a public not protected ftp with such sensitive data , and will have bad repercussions ?

[Aberration]

I think this is going to have some serious repercussions. I am imagining virus'es of unprecedented levels. OK maybe not, maybe we will just see viruses like we used to see, ones that over spin your hard drive and destroy it. I am sure there are equally nasty things to do to an SSD, or peripheral cards.

[kromosto]

nice i always wanted to see a up to date bios source code