Hiding a Rootkit In System Management Mode 119
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."
Re:My BIOS has a toggle for virtualization feature (Score:5, Informative)
Re:LiveCD (Score:5, Informative)
Re:oooooh scary (Score:5, Informative)
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.
Neither news or an issue (Score:2, Informative)
Re:Neither news or an issue (Score:3, Informative)
Not really an issue on recent hardware (Score:5, Informative)
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)
Re:Neither news or an issue (Score:1, Informative)
At any rate, there are many alternatives. On AMD processors you could load a microcode update (Intel CPUs verify those with a digital signature, but AMD doesn't) to manipulate the effects of machine instruction. On any machine, you could install a hook on the Page Table Handler which then marks its own pages as NoRead, NoWrite, Execute while exposing to the rest of the system as Invalid page (this is what the Shadow Walker rootkit mentioned in TFA does). Or virtualization (which means you would at most detect the presence of a virtual machine monitor, which couldn't be differed from an installed legitimate one). I'm pretty sure BluePill can be made nearly impossible to detect if it simply occupied exactly half of the TLB cache (even though it needs less), hooked CPUID to report only half of the TLB cache size, reported the CPU model as one which typically has such a TLB cache size, and hook all instruction that supposedly don't exist on this older CPU model but are present on the actual one. Some people mentioned hiding in PCI/AGP/PCIe cards expansion ROM, or reflashing a harddisk's or DVD driver's firmware to inject code into binaries read from it.
I guess all this leads to way to an obvious conclusion: Damn secure your system that even if your usert account is compromised, there's no reasonable way to escalate privilege to root or kernel rights.
Re:Difficult in practice (Score:3, Informative)
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.
Re:Difficult in practice (Score:3, Informative)
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.