Become a fan of Slashdot on Facebook


Forgot your password?
Security Technology

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."
This discussion has been archived. No new comments can be posted.

Hiding a Rootkit In System Management Mode

Comments Filter:
  • hmm (Score:5, Funny)

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

    by ILuvRamen ( 1026668 ) on Sunday May 11, 2008 @07: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.
  • 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 @07: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 Monday May 12, 2008 @12:13AM (#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.
    • "yes it takes a veeeeery long time to boot"

      A fast CD drive helps, as do light live distros. I find Damn Small Linux boots very quickly.

      You might also boot an ISO image from a flash drive or CF card that is write-protected and/or has no persistent home directory. Google for LOTS of info on doing this. I don't find live CD boot times to be very long on modern PCs, even with full distros like Knoppix.
  • by Anonymous Coward on Sunday May 11, 2008 @07: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 @07: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.
    • by moteyalpha ( 1228680 ) * on Sunday May 11, 2008 @07:42PM (#23372688) Homepage Journal
      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.
      • As someone who doesn't know that much necessarily about the capabilities of this type of exploit, I still have several questions after reading the article. 1. While this rootkit may very well be something that you can't see while inactive, would you be able to see it with some of the Sysinternals suite of programs (e.g. regmon, procmon, filemon) while running? 2. If someone is tricked into flashing their ROM, is there any way of getting rid of it other than a new computer/new hardware? 3. Is there ANY po
        • by rts008 ( 812749 )
          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
          • by srw ( 38421 ) *
            Really not trying to be a pedantic jerk, but you misspelt EEPROM every time. (EPROMs were erased with UV light. EEPROMs are "Electrically Erasable")

            • by rts008 ( 812749 )
              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 EEPROM and flash are distinct technologies. You used the terms interchangeably.

                Please mods, this was an attempt at humor (piling on). Maybe with your help I can be rehabilitated. In the mean time, I've never seen a +5 redundant. BRING ON THE UNDERRATED POINTS!
                • Being a pedantic jerk, EEPROM and flash are NOT distinct technologies. They are, in fact, nearly identical. All flash memory parts are EEPROM, but the converse may not be true. There isn't any generally accepted formal definition of "flash memory" that can be used to definitively determine whether a particular EEPROM is a flash memory. "Flash" is in fact mostly a marketing term.

                  One particular form of flash memory, NAND flash, uses a structure that is distinct from most other kinds of EEPROM. NOR fla

          • by node 3 ( 115640 )

            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.
      • by maxume ( 22995 )
        Is the stuff you do on every single system you use really that important?

        I can see being very careful with systems that are used for a wide range of tasks, but the desktop machine with nightly backups that you use to draft documents doesn't seem like it is going to be so important that you need to inspect all binaries. Most people use computers for stuff that is even less important than that.
      • I will not use a binary program, unless I have the source and can verify it is legitimate.

        Surely your compiler is a binary? And your BIOS? Disk firmware? Processor microcode?

        Unless you built (not assembled, mind you, but rather built from bits of copper and silicon) all the hardware yourself, at some point, there is a binary black box you have to trust.

    • What about environments which have the same hardware build deployed, such as corporate/enterprise networks?
    • 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
      • by rts008 ( 812749 )
        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)

          by node 3 ( 115640 )

          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 ) <> on Sunday May 11, 2008 @07: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)

      by PhireN ( 916388 )
      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.
      • They were using eBay to track down replacements.

        Houston, we have an attack vector.

        I wouldn't deem it unlikely that the military goes through similar venues to get "old hardware" that's no longer being built but has to be used because of specs. I think NASA did something similar when they needed old (and space-proof) hardware.
    • 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.

      • Right, cause when the North Koreans, Russians, Chinese, et al. came in to "save you" from the "evil US military" your freedoms would finally be secure for all time.

        Those countries always bring liberty, equality, and cell-phone coverage to all they conquer.
    • 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
      • Even the military has to use computer hardware, and they don't build it themselves (anymore). The attack vector wouldn't be to bring your malware onto the machines, rather you'd prepare new machines being sold to them with such payload. Or if, like mentioned above, they need to buy replacements on the civilian market because to-spec hardware isn't built anymore, you have a very easy attack vector right there.

        Let's not be paranoid, but we all know that computer hardware today is mostly built outside of the U
  • by landonf ( 905751 ) <> on Sunday May 11, 2008 @07:52PM (#23372744) Homepage

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

    • by netcrusher88 ( 743318 ) * <netcrusher88 AT gmail DOT com> on Monday May 12, 2008 @04:47AM (#23375530)
      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.
  • by fuzzyfuzzyfungus ( 1223518 ) on Sunday May 11, 2008 @08:01PM (#23372784) Journal
    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)

      by cdrguru ( 88047 )
      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
      • cdrguru is correct in noting that a setup requiring significant amounts of admin per system just isn't going to happen. Even admins have limited time and patience.

        That said, the continuum from appliance to fully customized system is, while not orthogonal to it, distinct from the continuum between fully closed and fully open systems.
        Take the Free Telephony Project [] as an example. Their product is a little embedded Astrix PBX in a box. Plug it in, it works. Such a device can easily qualify as an appliance
  • 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)

      by DigitAl56K ( 805623 )

      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.
      • Re: (Score:1, Informative)

        by Anonymous Coward
        The real FA behind PC World's article explicitly stated that they had to reflash the BIOS to carry out the attack. This is why it would be detected (take out the BIOS chip and compare it to a safe one, or check out the chipset-specific flags if the protection is really enabled), or even be impossible (yes, quite some mainboards today still have a hardware flash protection flash, and the chips where this flag could be overridden in software aren't produced any longer).

        At any rate, there are many alternatives
  • by mjg59 ( 864833 ) on Sunday May 11, 2008 @08: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)
  • by DigitAl56K ( 805623 ) on Sunday May 11, 2008 @08: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)

      by Opportunist ( 166417 )
      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.
    • Sure, that may be right. But what do you do with a new computer, especially a used one? Scan with an antivirus to make sure it is clean. If you're going to play safe, you may wipe it clean and install a new, ultra-secure OS.

      Now you feel safe, now you can enter a CC number or password... but guess what - it's still not clean, BIOS was switched by the previous owner or someone who had physical access to the machine before it was sold. How do you detect this? If you can make the system log keystrokes in a comp
  • by rocketPack ( 1255456 ) on Sunday May 11, 2008 @08: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.

    • by Kevinv ( 21462 )
      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
      • I realize it's not targeting the OS, but it just so happens that (until very recently) all computers running Mac OS have a fixed hardware base, unlike PCs. I thought I made this fundamental concept pretty clear.

        My point here is that even if Macs don't own the market, there is frequently at at least one in every major corporate/government network. Since they can be positively identified, and their hardware possibilities narrowed down to a tiny fraction of those for the PC market, it would be a logical entr

    • by jimicus ( 737525 )

      TFS says the code must be specifically targeted to a particular machine which, on a PC, means a very big challenge.

      Regardless of this, it's still a pretty big challenge. It's well out of script-kiddie land and into "determined hacker" territory - and I can't imagine anyone would take it on unless the target was really worth it. Think large bank or governmental organisation.

      Thing is, though, large banks and governmental organisations buy hundreds, if not thousands of identical PCs at a time - and they're likely to be based on relatively conservative hardware, rather than "latest and greatest gaming rig" stuff. Findin

    • Doesn't the fact that the Mac uses EFI instead of BIOS make this irrelevant? You need to mess with the BIOS to get this to work.
    • by mjg59 ( 864833 )
      Every Intel Mac I've seen locks down the SMRAM area in the firmware. There's no way to modify the SMM calls unless you can replace the firmware - and if you can do that, there are easier ways to take control of the machine (such as embedding malicious code in the ACPI tables)
  • It strikes me that Interrupt 19 is a heck of a lot easier to use and not hardware dependant providing that the CPU is any version of x86 and int 19 isn't disabled. Curiously, most CMOS, even modern ones, leave int 19 wide open by default so it can reboot the system without clearing memory or restoring interrupt vectors. How easy is that?
  • by Anonymous Coward
    Have a look at General Software's Firmbase technology. They are using the SMM for lots of crazy stuff - a tiny OS is running in SMM mode. It is interacting with USB, network adapter, serial ports etc. It has a web server, telnet server, snmp server... It is possible to get a prompt on serial port to poke the hw registers, memory, cpu registers etc while the main OS is running and doesn't have a clue what's going on. This comes very handy when developing drivers for such systems, but if some evil bios engine

"Remember, extremism in the nondefense of moderation is not a virtue." -- Peter Neumann, about usenet