Slashdot Mirror

Those opportunities will be hard to come by if the BIOS is a distant memory by the time networking is up.

That is absolutely false. If you can compromise the firmware then it does not matter what is loaded afterward, you can modify it as it is loaded or before it is loaded. Even if you boot with PXE or HTTPS the firmware still has to load the eventual image. You can have a persistent threat that does not require the flash part to be compromised as long as you have a mechanism available to launch your payload. And the fact that you think this is the epitome of the problem we are currently seeing. The people who write the firmware just cannot honestly conceive of the attacks surface that they are presenting. The only way you'd be able to prevent the kinds of attacks I am talking about is by not loading a single driver to communicate with untrusted hardware. And good luck ever booting a useful general purpose computer that never loads a drive controller or network controller.

A USB device could be a problem if you boot from it,

Again this is incorrect. A USB device could be a problem if you communicate with it. At all. Even if it is just to enumerate the available devices. The firmware could communicate with a USB device for many purposes that have nothing to do with booting the OS. Obviously the attack surface presented by enumerating the devices is not as great as the surface presented when trying to use the device but software bugs can exist anywhere and even a simple typo could open you up to attack.

Believe me, I am not trying to argue that there is no way to improve the situation. One of the nice things about Coreboot is that it does as little as absolutely necessary to initialize the system before passing control onto the OS. As you say, KISS reduces the opportunity for attackers by reducing the number of ways they can attack you. But there is no magic wand you can wave at security and that includes the wand of using ROM to load firmware.

if the BIOS is configured to boot from USB, but EFI and/or firmware updates won't change that. PCI devices could certainly be a problem,

And where does the USB controller sit? Inside the PCH on the PCI bus.

though less so now that chipsets have an IOMMU. If the option ROM contains an exploit, again neither EFI or the ability to update firmware will make it go away.

There have been attacks on IOMMU since at least 2011. And how do you mitigate this VT-D bypass? Through a firmware update. And you'd be naive to think that this is the only exploit possible against IOMMU.

I am aware of how many things have firmware in them. I write some of it. Ignoring the KISS principle is the problem. Ignoring it harder isn't the solution to that problem.

And what are you trying to keep more simple here? Because you're making it basically impossible for probably 95% of the population to update their firmware. By all means, strip out the cruft out of your firmware. Reduce your attack surface anywhere possible. But don't throw the baby out with the bath water and leave most of the world vulnerable by removing their ability to patch their firmware.

Maybe you should look at what Google has done with the Chromebook. They use the silicon vendor's hardware protection of the flash part. They have their Titan device that is able to detect modified flash. They require a physical presence check when tampering with the machine in a way that might compromise the integrity of the device. You have to hit the power button five times in a specific time interval. Assuming that they've implemented their hardware and software properly then you'll find that

VM guests can be better isolated than air gaps.

Physical interfaces are usually more complex and exploitable than the interfaces available from a locked-down hypervisor.

Check this out

http://en.wikipedia.org/wiki/Blue_Pill_(malware)
http://www.invisiblethingslab.com/itl/About.html

A girl even helped create it :)

There's still a hole. See Xorg Large Memory Attacks, section 4. Opening a one-page gap in mapped memory at the top of the stack is a workaround, not a fix.

This looks like bad design. Someone got too cute with the MMU. The basic problem is shared memory between a privileged and a non-privileged program. That just screams "security hole". It was put in to get a performance advantage for graphics-heavy applications on X, probably games. "MIT-SHM" shouldn't be enabled on a production server.

In this presentation we will discuss and demonstrate how to permanently re-flash Intel BIOSes on the latest Intel® Q45-based desktop systems. In contrast to a previous work done by other researches a few months earlier, who targeted unprotected low-end BIOSes, we focus on one of the most secure, vPro-compatible, BIOSes, that normally only allow a vendor's digitally signed firmware to be flashed. We demonstrate how to bypass this verification scheme, using a very sophisticated heap overflow exploit. The attack requires administrator-level access, and also requires one reboot to succeed, albeit doesn't require any user consent or cooperation, nor any physical access to the machine â" thus it is well suited for use by malware. The attack stresses the importance of other means for ensuring trusted boot process, like e.g. TCG's TPM-aided ones, as well as the importance of better review of the core system software and firmware.

Intel implements exactly the sort of switch you describe, in addition to requiring a signed BIOS. And lo, it's still possible to do bad things...

On Linux systems it is trivial for the root user to modify system MTRRs7 via the /proc/mtrr pseudo-file. Assuming your system is an Intel DQ35 board with 2GB of RAM, it is likely that the "caching map" of your memory looks like this, e.g:

[..]

We see here the first entry (reg00) is marking the whole memory as Write-Back cacheable8. Next we see a bunch of "exceptions" -- regions of memory each marked as uncacheable. One of those regions, (reg03) corresponds to the memory where the SMM's TSEG9 segment is located. We can now simply remove this MTRR entry for TSEG, with the following shell command:

echo "disable=3" >| /proc/mtrr

[..]

Of course on different systems than Linux, e.g. Windows, one doesn't have such a convenient access to /proc/mtrr pseudo-file. This is however only a minor technicality, as one can very well modify the MTRRs mapping using the standard WRMSR instructions.

Once the TSEG's memory is marked as WB cacheable, one can do something as simple as:

*(ptr) = evil_data;
outb 0x00, 0xb2 // generate SMI

It's all one liners until someone puts an eye out.

This seems to relate quite similarly.

The quest for ring 0:

http://www.securityfocus.com/columnists/402

http://www.securityfocus.com/comments/columns/402/33600#33600

(^replaces a broken link^)

http://www.mackido.com/EasterEggs/CD-System70.html

Researchers: Rootkits headed for BIOS:
(comments especially)

http://www.securityfocus.com/news/11372

http://www.securityfocus.com/comments/articles/11372/33017/threaded#33017

http://www.securityfocus.com/comments/articles/11372/34206/threaded#34206

http://www.securityfocus.com/comments/articles/11372/33500/threaded#33500

http://www.securityfocus.com/comments/articles/11372/34207/threaded#34207

http://www.securityfocus.com/cgi-bin/index.cgi?c=articlecomments&op=display_comments&ArticleID=11372&expand_all=true&mode=threaded

http://www.spywareinfoforum.com/index.php?s=3a3ce02c4055e269a0220c239560f3f9&showtopic=6056

Nancy:

https://tagmeme.com/exmachina/a/002450.html

This possible variant is out of "beta" (12 years old) it seems and truly roams "at will", those with the coding chops will understand what even a partial AI engine is capable of (SOAR).

On Macintoshes it leaves strings:

http://www.google.com/search?q=NuNV+N%5ENuNV&btnG=Search&hl=en&sa=2

PCs become junk as well:

http://www.derkeiler.com/Newsgroups/microsoft.public.security.virus/2005-09/0230.html

This Gal has a handle on it:

Joanna Rutkowska, Invisible Things Lab:

http://invisiblethingslab.com/itl/About.html