Slashdot Mirror
Hiding a Rootkit In System Management Mode
Sniper223 notes a PC World article on a new kind of rootkit recently developed by researchers, which will be demoed at Black Hat in August. The rootkit runs in System Management Mode, a longtime feature of x86 architecture that allows for code to run in a locked part of memory. It is said to be harder to detect, potentially, than VM-based rootkits. The article notes that the technique is unlikely to lead to widespread expoitation: "Being divorced from the operating system makes the SMM rootkit stealthy, but it also means that hackers have to write this driver code expressly for the system they are attacking."
Nope! This isn't using Virtualization mode.
If the code runs in SMM and is launched from the BIOS a live CD doesn't avoid the problem.
Depending on the BIOS, the chipset itself can be configured to explicitly make it impossible for the OS's kernel to even read or write the specific memory range that it being used for SMM.
The attack vector is made a lot easier because most BIOS vendors don't blockhole the address range as they need to support USB devices DMAing into the Aseg and Tseg segments (the memory ranges utilized by SMM). This is what you pay for to be able to use a USB keyboard in DOS. Legacy emulation so that all those ancient BIOS interrupt calls continue to work with your latest input devices..
If there is a modern operating system running, there is a handoff between the OHCI driver and the SMM using a mailbox register on the usb controller so that the BIOS stops using the USB controller. What this means that modulo BIOS services that do things like control fans (and aren't implemented in ACPI), something could slip into SMM quite easily and flip the bit that makes it impossible for your antivirus to find it.
This has already been discussed about two years ago. Basically you can't carry it out because every chipset blocks write access to this memory part by doing a complete remapping of the memory layout in hardware. Together with a very short list of mainboards where the developers forget to set up the necessary flags through the BIOS code.
In system management mode, the processor runs code from memory (SMRAM) that can't be seen by the operating system. The usual way of handling this is to map the SMM memory into the address space at 0xa0000 - that is, where the legacy graphics framebuffer is. Normal accesses to this address space are redirected to the graphics card by the northbridge. In SMM, accesses to this address space are diverted to real memory and the magic code is run.
Obviously, it has to be possible for the BIOS to put code their in the first place. There's a configuration flag in the northbridge (on recent Intel chipsets, it's byte 0x9d of the PCI configuration space on the host bridge) that controls whether accesses are directed to the graphics hardware or physical memory. The BIOS can set that to do the initial setup. Once it's done that, the bit is flipped and normal code can no longer see the SMM code. The vulnerability lies in the fact that OS code could reset that bit, gain access to the SMRAM and modify it. Any BIOS I've seen from the past couple of years has gone a step further and set an additional bit that prevents this from occuring. Once that bit is set, the only way for normal code to gain access to the SMRAM region is for the machine to be reset. This happens before any OS code gets run, so there's no opportunity to install hostile SMM handlers.
Is it still possible to exploit? Yes. If the attacker can modify your BIOS they can modify the code that it copies into SMRAM. However, if the attacker can modify your BIOS then they've already won even without using SMM. The initial bootloader uses BIOS calls to read data off disk, so a sufficiently intelligent attack could rewrite that in order to boot a modified kernel. In versions of Windows before Vista, most graphics drivers still made BIOS calls. A modified BIOS could do anything it wanted to with those without looking suspicious in the slightest. Like the article says, it's unlikely that this'll be common. But to be honest, I don't see it happening in the real world at all.
(Today I have been trying to work out just WTF a Dell laptop does when it enters system management mode in response to a brightness hotkey press. The locking down of SMRAM makes this effectively impossible)
[quote]or the ability to reflash the ROM. Either is going to be very system-specific.[/quote]
Manipulating the ROM image is trivial. It basically consists of the emergency boot block, a small LHARC decompressor, and a mini filesystem (basically a linked list) containing some modules of position-independent code in LHARC archives. If you want to add a module, simply compress it, read out the existing image, append your achive to the list, and write the result back. People have been doing this so often, f.e. for adding the PXE boot rom from the LinuxBIOS project without fully replacing the BIOS.
Flashing itself is also pretty easy. Take a look at UniFlash, which is a FOSS program written in Pascal that supports virtually every existing flash chip. The procedure is pretty much always the same and very simple. It allows allows for flashing PCE/AGP/PCIe expansion ROMs.
(You will also find some very interesting details. F.e. on some chips, apparently the hardware flash protection switch can be overridden by a software flag, rendering it absolutely useless.)
So please stop spreading the myth that BIOS rootkits would be hard or unstable. It's really just that seemingly no-one ever bothered to write a proof-of-concept, since the concept really is too trivial.
As are EEPROMs, which is the specific type of ROM we are talking about here (electronically erasable, programmable, read-only memory), since they don't require a UV light to erase the chips.
To further confuse things, flash memory (such as SD cards, USB flash drives, internal memory for iPods, cameras, phones, as well as SSD drives) are actually a type of EEPROM, even though they aren't strictly read-only in the sense most people would think. ROM actually refers to the memory being non-volatile and not to it being non-writable.