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'
With all the security issues that we hear so much about, I have decided that one potential way of avoiding most of them is to run a liveCD distro of whatever OS when working with sensitive data.
I do all my internet banking via freeBSIE now - yes it takes a veeeeery long time to boot, and I know that it doesn't solve ALL of the problems but it has to eliminate enouogh problems to be a viable solution.
Agree / disagree ?
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.
Lets say you are an evil terrorist hell-bent on infultrating the American military and wrecking havoc.
It seems to me that this would be exactly the sort of thing you'd look for. Military machines are specced very precisely, you'd know exactly what hardware was on the system so drivers wouldn't be much of an issue.
All you'd have to do is sneak your code in here once, and the timebomb would be ticking for when you want to activate it. Yeah, it wouldn't be easy to get it on there, but it means breaking through once allows you to lay a trap for another time. That sounds pretty serious to me.
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
Obviously I don't like hearing about nasty, or potentially nasty, vulnerabilities in common systems; but these sorts of situations do seem like an argument for more openness in computer systems, right down to the dark, embedded corners. Particularly with these dark, embedded, corners taking on more and more functions. If you can pull stuff like this with the BIOS, I hate to think what a full EFI setup could be doing(particularly if the OEM enthusiasm for shittastic bundleware reaches that level of the system). Time and again, we see that we cannot trust what we cannot verify.
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)
The problem with the "invisible to antivirus" argument is that it assumes the system is pre-infected. To root a remote system you need to get the code onto the system and execute the software that puts it in SMM, and during that process any anti-virus is able to inspect it. The question is will the anti-virus heuristics or signature-based methods actually catch it?
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.
Science Museum of Manitoba, eh!
Infuriate left and right