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.
i have norton, problem solved.
Oh boy, I love ridiculously overly dramatic BS! Yes it's very easy for it to hide there and for there to be basically no signs that it's there. OMG everyone run for the hills! Oh wait, malware doesn't just sit there, it does stuff. It runs threads, it reads from and writes files on the hard drive, and it has to at some point send some sort of data over the internet or local network. So yeah, no virus can hide and still cause damage and spread while remaining undetected.
Google's Super Secret Search Algorithm: SELECT @search_results FROM internet WHERE @search_results = 'good'
In theory, SMM is the ultimate rootkit hiding place. In practice, it's difficult to exploit on a wide scale. Getting the system to execute rootkit code in SMM isn't easy. You're going to need an exploitable BIOS bug, or the ability to reflash the ROM. Either is going to be very system-specific.
If the code runs in SMM and is launched from the BIOS a live CD doesn't avoid the problem.
What about vulnerabilities in onboard IPMI cards? Our new servers have ARM-based cards running Linux. The built-in HTTP server is vulnerable to a widely-known buffer overflow:
landonf@ahost:~> telnet XXX.XXX.XXX.XXX 80Trying XXX.XXX.XXX.XXX...
Connected to XXX.XXX.XXX.XXX.
Escape character is '^]'.
GET
Connection closed by foreign host.
landonf@timor:~> telnet XXX.XXX.XXX.XXX 80
Trying XXX.XXX.XXX.XXX...
telnet: connect to address XXX.XXX.XXX.XXX: Connection refused
Seems like a recipe for compromised data centers, to me. Re-imaging a machine won't touch the IPMI card.
http://plausible.coop
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)
TFS says the code must be specifically targeted to a particular machine which, on a PC, means a very big challenge.
On a Mac, however, you could easily target a very large number of people using only a very small number of hardware variations. Could this exploit be better suited to Macs than PCs? On the other hand, it also seems like it would be equally easier to detect the problem, since your algorithm can be fairly specific (both in terms of Macs and PCs), since the code needed to exploit would be rather specific.