It seems a lot of the work in doing this is done by coreboot, which is pretty sweet, since there’s an easy way to get my hands on that code

I was wondering though, do you have any plans to release any of the code your wrote for this?

Besides the technical discussion about what can or cant be done (and there is a lot to talk about that topic ), I think that what alfred means is that wasn´t our purpose to bypass the most recent firmware protections (breaking or avoiding it) but rather to offer a real probe that this kind of infection really works, and can be used in the most common scenery around there.

With this we tried to show that really makes sense to apply any of the available protection method, at least disabling the Write enable pin, as we’ve mentioned on the talk. So, to avoid future misunderstandings from who wasn`t there and because of the big impact of the presentation, we agreed that would be better to mention it on the slides. We will do it ASAP.

We are open to any other suggestions related to this talk.

I was really looking forward to your presentation, thought it would be the most interesting at CanSecWest. But then was disappointed when saw the slides. I think it is unfair not to mention the obvious prevention against your attack in the slides, prevention that has been used for *years* on many BIOSes…

http://news.zdnet.co.uk/security/0,1000000189,39118129,00.htm

BTW, the requirement that the BIOS accepts only signed updates doesn’t require any Read-only bootblock, TPM or TXT technologies! Trusted Boot it a different thing than BIOS flash protection.

But I just want to add, there are many signed BIOS solutions, as cited by John Heasman’s 2007 Blackhat paper. I’m not familiar with all of them, but there should be two basic ways to verify the BIOS:
1) Doing it on a Read-Only Boot Block (Using TPM or whatever): this can be easily bypassed if you have physical access.
2) Using something better like Intel TXT where Boot Block is no longer the root of trust. But I have heard that some researchers have broken that just weeks ago…

BTW this presentation was only for the first stage of our research. The second stage will be ready in a couple of months, and will put (hopefully) this technique to shame…stay tuned!

Well, you’re right. We have not tested our attack on the newest Phoenix-Award BIOS available. We´ve just targeted the most common BIOS firmware around us (and its updates, so i think that maybe there arent digitally signed firmwares available for every motherboard).

In fact, we also havent tested it against EFI or motherboards with TPM because our intention was only to show that the BIOS firmware can be easily readed and modified. This is enough to “infect” normal and forgotten BIOS in most of the machines.
At the other hand, vmware is a very interesting vector attack because it would be very simple to patch the main vmware executable to get our injected code executed by every vmware booted up.

Vmware also allowed us to show in a very clear way (i hope) how malicious things can be done from the BIOS through the int 0×13 as injecting malicious code, modifying data, detecting and patching running Antiviruses, etc.

Before finishing i would like to add that in our talk we said that this kind of attacks could be mitigated with TPM and digitally signed firmwares.
So, now that you mention it, i think we should take a look to the more recent BIOS firmwares (if my boss gets me some of it to break )

See ya!