Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Hiding a Rootkit In System Management Mode

Posted by kdawson on Sun May 11, 2008 05:57 PM
from the can-you-see-me-now dept.
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."
+ -
story

Related Stories

[+] VM-Based Rootkits Proved Easily Detectable 128 comments
paleshadows writes "A year and a half has passed since SubVirt, the first VMM (virtual machine monitor) based rootkit, was introduced (PDF), covered in the tech press, and discussed here. Later Joanna Rutkowska made news by claiming she had a VMM-based attack on Vista that was undetectable — a claim that was roundly challenged. Now in this year's HotOS workshop, researchers from Stanford, CMU, VMware, and XenSource have published a paper titled Compatibility Is Not Transparency: VMM Detection Myths and Realities (PDF) showing that VMM-based rootkits are actually easily detectable."
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • hmm (Score:5, Funny)

    by extirpater (132500) on Sunday May 11 2008, @06:12PM (#23372524)
    i have norton, problem solved.
  • oooooh scary (Score:5, Insightful)

    by ILuvRamen (1026668) on Sunday May 11 2008, @06:18PM (#23372560)
    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.
      • Re:oooooh scary (Score:5, Informative)

        by Anonymous Coward on Sunday May 11 2008, @07:03PM (#23372790)
        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.
          • Re:oooooh scary (Score:4, Interesting)

            by Anonymous Coward on Sunday May 11 2008, @07:23PM (#23372916)
            FWIW, an even easier vector for stuffing data into the SMM, and not as a BIOS payload (which will be very motherboard specific) is to chain it into the VGA BIOS (which most PCs have..). The VGA bios is nice because it's a very clean interface (as far as option roms go) for getting called and you can chain in the real VGA bios after doing whatever you see fit.

            You can even have it trigger on the first BIOS calls of the windows bootloader so that you can easily overwrite the SMM memory regions in a nice and portable way.
      • Re:oooooh scary (Score:4, Insightful)

        by ILuvRamen (1026668) on Sunday May 11 2008, @09:59PM (#23373908)
        LEARN HOW TO READ! All I said was this particular gloom and doom bullshit is overstated and shouldn't be as feared as they're making it sound. Where the hell did you get "all viruses aren't dangerous" out of that? All I'm saying is every virus can be detected. All these new "unstoppable supervirus: we're all gonna die!" articles are idiotic and wrong.
        • All these new "unstoppable supervirus: we're all gonna die!" articles are idiotic and wrong.

          That's exactly what the unstoppable supervirus wants you to think!
  • LiveCD (Score:2, Interesting)

    by Anonymous Coward
    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 ?
    • Re:LiveCD (Score:5, Informative)

      by Anonymous Coward on Sunday May 11 2008, @06:39PM (#23372658)
      If the code runs in SMM and is launched from the BIOS a live CD doesn't avoid the problem.
    • At some point you have to write a new LiveCD, yes? Or perhaps you have passwords too complicated and numerous to remember, and need to write them to an encrypted USB stick?

      It seems to me that there are still opportunities to get infected. On the other hand, you have reduced the danger space, so that's good.
    • Would booting from an SD card with the write protect on be any faster? I know that not all computers support booting from USB devices, but for those that do, it should be much quicker than booting from a CD.
    • Re:LiveCD (Score:4, Insightful)

      by Technician (215283) on Sunday May 11 2008, @11:13PM (#23374386)
      and I know that it doesn't solve ALL of the problems but it has to eliminate enouogh problems to be a viable solution.

      It's time to look at the Intel vPro tm. tech that enables this. Look for demo videos online. The level in the BIOS enables remote powering up machines to push OS updates, remote booting repairing crashed/unbootable Windows machines, etc. This protected level of stuff is beyond the OS and even the power switch. IF it can remote boot an unbootable corrupt Windows partition, write fixes to it and boot it up, there just isn't much that a Live CD can hide. You best bet is to use your own known hardware. Turn off the remote management stuff unless your employer is using it. If the employer is using it, their top level management should be able to detect alterations to the protected area.
  • by Anonymous Coward on Sunday May 11 2008, @06:24PM (#23372594)
    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.
    • by garett_spencley (193892) on Sunday May 11 2008, @06:37PM (#23372650) Journal
      "You're going to need an exploitable BIOS bug, or the ability to reflash the ROM. Either is going to be very system-specific."

      Exactly. Windows was written to solve this very problem. All this talk about hiding root kits in SMM is one giant leap backwards.
    • This is one area where I have worked a bit and there is tremendous potential for abuse of VMM and SMM when you combine it with users that trust a company to deliver binaries. I will not use a binary program, unless I have the source and can verify it is legitimate. A bit of social engineering and the right picture and an uninformed user will be flashing their BIOS while they wait for the security update they think they are getting. If it is done right, this type of program can remain dormant and use no CPU time to give itself away, until it is keyed to act in something like a bot net or some other purpose.
        • I don't know much either, but will chip in what I do know.

          1. probably no unless whatever malware was loaded is actually Doing Something actively. Otherwise it is just kind of idling in a 'protected' (from OS) space of RAM

          2. really not trying to be a pedantic jerk, but ROM cannot be flashed (Read Only Memory), did you mean EPROM? (which IS flashable)

          Also sometimes EPROM's can be reflahed to OEM state, sometimes they can be trashed by a faulty/malicious flash-depends (YMMV)

          3. I'm not sure, but as per #2 above
          • Really not trying to be a pedantic jerk, but you misspelt EEPROM every time. (EPROMs were erased with UV light. EEPROMs are "Electrically Erasable")

            • Thanks for the correction.
              You are correct, it's been a few years since I have had to deal with the different types of chips.
              I was just trying to help the guy out.
          • really not trying to be a pedantic jerk, but ROM cannot be flashed (Read Only Memory), did you mean EPROM?
            Not to be a pedantic jerk, but EPROM is a type of ROM.
    • Re: (Score:3, Informative)

      by Anonymous Coward
      [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. f
      • Okay, I'm a little confused here. I did not think that a ROM could be flashed, only an EPROM could.
        Has something changed, or is the term ROM now commonly used for all embedded chips?

        Really not trying to be a pedant, just want to know.
        If this is a case of 'not confusing the proles', then okay- sometimes it is easier to 'go with the flow' instead of being bogged down in technospeak, but I'm really starting to doubt my education and (slim) knowledge here.
        • Re: (Score:3, Informative)

          is the term ROM now commonly used for all embedded chips?

          Erasable, programmable, read-only memory chips, aka EPROMs, are a type of read-only memory chip, aka ROMs.

          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-on

  • by lakeland (218447) <lakeland@acm.org> on Sunday May 11 2008, @06:39PM (#23372664) Homepage
    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.
    • Re: (Score:2, Interesting)

      Its true, I worked in a company involved in air traffic control over the summer, And the computers which they had to use were old Compaq servers from 1998, of a certain model, with exactly x ram.
      They were using eBay to track down replacements.
    • Lets say you are an evil terrorist hell-bent on infultrating the American military and wrecking havoc.

      I think this would, in fact, make you not evil, but very very good.

    • Sure, you are not paranoid if they really are out to get you. Now you just need to figure out how to bridge an air gapped network and then you are all set.
      • Well yes, you do. I never claimed this was anything more than a privilege escalation bug.

        The point is that if you were planning some attack, you would want to co-ordinate a computer system failure with the rest of the attack. You have militants willing to die while making an attack, and you have the ability to screw up an important computer for a short period of time. If you can't co-ordinate them then all you get from both is a bit of annoyance and fear. Co-ordinate them and you get an attack at the sa
  • by landonf (905751) <landonf@plausible.coop> on Sunday May 11 2008, @06:52PM (#23372744) Homepage

    What about vulnerabilities in onboard IPMI [wikipedia.org] 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 80
    Trying XXX.XXX.XXX.XXX...
    Connected to XXX.XXX.XXX.XXX.
    Escape character is '^]'.
    GET /x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/x/ HTTP/1.0
    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.

    • Yes, but presumably you don't let the entire world get on your DC network. If only trusted people access vulnerable systems, the vulnerabilities are less significant. Yes they're still there, and yes there's still a risk, but what would the cost be of replacing or reprogramming all the IPMI cards? Security is all about risk/reward, except with a few more variables. If your demonstrable risk is minimal, the reward to reduce or eliminate it will also be minimal. If the cost outweighs the benefit, it's just bad business. Even if it is a good idea.
  • 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.
    • Re: (Score:3, Insightful)

      The problem is, you would like to turn the "personal computer" into a something that needs attention and continual review and updating. What 99% of the world wants is an email appliance that they can download the latest neat stuff on. We need to move to more of an appliance that needs less, not more administration.

      The second problem is that there is no "administrator", at least no qualified one for most of the home computers in the world. Windows needs some administration, arguably more administration th
        • Isn't that like justifying totalitarian secret government with the argument that people are too stupid understand what they want and vote?
          Yes, but only if you equate your computer, which has no (or, very, very limited) power to force its will upon you, with a government, which can take your wealth, liberty, and even your life.
  • by Anonymous Coward
    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.
    • Re: (Score:3, Informative)

      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.
      But TFA says someone has carried it out and will demo it in August.
  • by mjg59 (864833) on Sunday May 11 2008, @07:15PM (#23372862) Homepage
    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)
      • Yes. The fact that the SMRAM is locked from the OS doesn't matter - it's still accessible when the CPU's in system management mode. Since (in the absence of ridiculous BIOS bugs) there's no way to get a CPU in SMM to execute arbitrary code or rewrite arbitrary sections of the SMRAM, this isn't an issue.
  • by DigitAl56K (805623) on Sunday May 11 2008, @07:17PM (#23372874)
    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?
    • Re: (Score:3, Interesting)

      A signature can only catch what it knows. Now, it may match any variant of a known virus or at least a known exploit strategy, but it as well may not. Malware writers do check their creations against the most used AV kits. In a targeted attack, they usually even know what AV suit their target uses. So it is likely that at the time of launch, no relevant AV suit detects a certain trojan.

      Malware writers ain't dumb. They know they are the offensive player in that game and they use that advantage.
  • by rocketPack (1255456) on Sunday May 11 2008, @07:18PM (#23372878)

    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.

    • Not really.

      a) Mac's have something like 1-4% market share (including the PowerPC models which may not even have this mode), all you have to do is find a processor with greater than 1-4% market share in the windows and target that.

      b) These are rootkits running outside of the OS, so you wouldn't target a particular OS, you target a chip (or perhaps a chipset?). You'd want the most popular ones running. Could be a chip in Mac and Windows would be most popular. Article doesn't mention how much the OS is needed