Forgot your password?
typodupeerror
Security

Hacker Defeats Hardware-based Rootkit Detection 126

Posted by CmdrTaco
from the immovable-object-vs-unstoppable-force dept.
Manequintet writes "Joanna Rutkowska's latest bit of rootkit-related research shatters the myth that hardware-based (PCI cards or FireWire bus) RAM acquisition is the most reliable and secure way to do forensics. At this year's Black Hat Federal conference, she demonstrated three different attacks against AMD64 based systems, showing how the image of volatile memory (RAM) can be made different from the real contents of the physical memory as seen by the CPU. The overall problem, Rutkowska explained, is the design of the system that makes it impossible to reliably read memory from computers. "Maybe we should rethink the design of our computer systems so they they are somehow verifiable," she said."
This discussion has been archived. No new comments can be posted.

Hacker Defeats Hardware-based Rootkit Detection

Comments Filter:
  • by LiquidCoooled (634315) on Sunday March 04, 2007 @11:08AM (#18226862) Homepage Journal
    I was under the impression that the only way to reliably detect a root-kit is to examine the system from another clean system?

    ie remove the drive/devices and check them all.

    • by Zephiria (941257)
      Whenever I clean a system, thats pretty much what you have to do.
      Trying to clean up a running system is just insanity.
      • To that end do you know of any particularly good live CD's for the task (windows box)?
        -nB
        • by MrShaggy (683273)
          Just off the top of my head .. try
          http://www.bootdisk.com/ [bootdisk.com]. They either have it, or they will have a link for it.
        • by Sancho (17056) *
          BartPE is pretty useful: it's a Windows LiveCD environment.

          http://www.nu2.nu/pebuilder/ [nu2.nu]
          • I've used it for deployment but not for intrusion detection before. Really want to boot linux, just to ensure that windows exploit code can't run at all during a scan.
            Also, while I have a license that covers the PE environment at the office, when moonlighting that license is not available to me, again making linux attractive.
            -nB
    • by JackHoffman (1033824) on Sunday March 04, 2007 @11:19AM (#18226958)
      The rootkits that are written to the disk aren't the biggest problem. Like you said, one can "simply" look at the drive from a clean system. The problem is with rootkits that are only installed in RAM, while the system is running. The attacker exploits some hole in an application or in the OS and then transfers the whole system into a virtual machine that looks exactly like the real thing, so the rootkit can't be detected from inside the OS. Nothing is written to disk, so when the system is powered down, the rootkit vanishes into thin air. Servers are unlikely to be powered down often and even if they are, the cracker can simply attack again. With the rootkit undetected, it is likely that the exploited bug has not been corrected. Common wisdom was that this type of attack can be detected by looking at the contents of the RAM in a way which bypasses the OS. The rootkit has to be somewhere, right? Well, according to this article, there is a way to hide the real RAM contents from hardware assisted forensic methods.
      • Re: (Score:1, Interesting)

        by Anonymous Coward
        There aren't any real technical details at the link. So I can only speculate...

        I've done a fair amount of hardware debugging, one of the problems reading memory directly is that the CPU kind of dictates how and where it is used, potentially on a page by page basis and 4k pages aren't really that much. There are great logic analyzers that will decode instructions in memory and do all the stuff you'd expect, but you still need to know where the right pages are mapped. So what do you do? You ask the CPU

        • Re: (Score:3, Insightful)

          by andreyw (798182)
          No technical information? Did you happen to miss Rutkowska's slides linked from the page? There is more than enough information, when coupled with the freely available manuals from AMD, to understand the issue at hand....
      • There's an exceptionally easy way to detect this types of root kits. At least there is if the root kit does anything. If it just installs itself, virtualizes the host, and then does nothing at all, then you can't detect it. But in that case who cares? In other cases, ie. where something is going on, you can detect them by their impact on system performance. All virtualizations technologies on x86 based systems have a measurable overhead.
        • by nneonneo (911150)
          An "ultrathin hypervisor" as some call it is a very tiny OS wrapper. The wrapper does indeed have negligible effect on the system - about as much effect as, say, running a small background process.

          All virtualizations technologies on x86 based systems have a measurable overhead.

          Wrong -- "measurable" in this sense may not be so measurable. The clever malware could fool the system timer to be a little bit off (say, 0.1%), so that it hides its tiny footprint in the timer. Thus, any attempt to query the timer would just return the expected result.

          • by Score Whore (32328) on Sunday March 04, 2007 @01:55PM (#18228272)

            An "ultrathin hypervisor" as some call it is a very tiny OS wrapper. The wrapper does indeed have negligible effect on the system - about as much effect as, say, running a small background process.


            Like I said, if you are going to do nothing, then sure, you'll have a hard time detecting it. But if it does something, like keylogging or sending spam, then it'll have measurable effects.

            Wrong -- "measurable" in this sense may not be so measurable. The clever malware could fool the system timer to be a little bit off (say, 0.1%), so that it hides its tiny footprint in the timer. Thus, any attempt to query the timer would just return the expected result.


            Not wrong. My timer is on my wrist. There's another one on the wall. Neither one is attached to my computer. There is another on my network for the specific purpose of keeping track of the slew in my various systems' clocks. Additionally if you start screwing with my system clock, other systems on my network would see this behavior in fucked up timings in the local system's network stack. If your hypothetical malware is slowing my system timer to hide its consumption of system resources, then keepalives would be arriving at remote hosts late. Also there would be drift in the system clock vs. my gps receiver.

            Then there are devices that have physical clock rates. Serial ports, PS/2 ports, sound cards, video cards, etc. You can go into a tight loop for X number of intervals of playing a known number of 44.1 Khz samples to your sound card. If you used to be able to get through 250 million interations of the loop and now you can get through 247 million iterations of the loop, then you know something is consuming resources on your system. And if you really want to measure the impact of the malware then make your loop perform privileged operations so that they must be virtualized.

            And there is the fact that you could compare two clocks, the mobo's time of day clock and the CPU's cycle clock. If you screw with them both you'll see all sorts of bad behaviors. If you don't, then you can compare the relative speed of the two to see the loss due to malware.

            Finally the malware has to live somewhere in system RAM. It can't allow itself to be over written. The original OS knows how much RAM is supposed to be there, so just consume all memory. When it attempts to swap out to a local hard drive, go ahead and fill that up too.

            There's a lot of hyperbole and sensationalism about virtualized root-kits.
            • If you used to be able to get through 250 million interations of the loop and now you can get through 247 million iterations of the loop, then you know something is consuming resources on your system.

              This would work great, if your system was running *no software*. Unfortunately, the scheduler's job is to run software as quickly as possible - not give you consistent timing numbers. When it comes to actual computers running actual applications, a 1% timing change is well within normal variance.

              As for being

              • This would work great, if your system was running *no software*. Unfortunately, the scheduler's job is to run software as quickly as possible - not give you consistent timing numbers. When it comes to actual computers running actual applications, a 1% timing change is well within normal variance.

                It's my system. I can make it idle if I want to. I can dedicate 100% of the CPU to a single thread per execution unit if I want to. I can establish a baseline of behaviors. I can run the test 100 times and eliminate

            • by Bri3D (584578) on Sunday March 04, 2007 @04:49PM (#18229864) Journal
              Issues:
              The CPU is idle. A lot. The rootkit could quite easily only run itself when the CPU would otherwise be in nops or a delay loop. It's essentially impossible to use 100% of the CPU, because something, somewhere in a modern OS is generally going to run a few nops or go into a known loop state, at which the malware could just overwrite the nops or delay instructions and not delay the system at all. So your method isn't terribly great.
              Now, calling privileged instructions as you mention is a brilliant way of sensing the malware, as it's unavoidable that the malware must handle most privleged instructions acting as a virtual machine, and then it'd definitely be losing clock cycles.
              Unless you're listening to the samples and counting every one the rootkit could just discard enough of the calls to make the clock rate appear the same.
              The OS has no idea if the virtual machine is swapping for it. And unless you're filling the RAM with random data and then reading it back + timing it memtest86 style, the VM could just discard all the memory you allocate.

              Yes, there is a ton of hyperbole and sensationalism. Virtualized rootkits are among the least common threats currently on the internet and all users and 99% of admins need not worry about them, as they have much more important things to be concerned about. But for the .001% of admins who run with highly sensitive data and audit every line of code going into their systems, this is a definite threat that they should be concerned about detecting. And they're pretty difficult to detect. And they're something new and special, so they're the Next Big Thing.
            • by raddan (519638)
              As a busy sysadmin, I know that I will be spending my time benchmarking sound cards on all my servers! Perhaps I should hire an imaginative CS grad student or armchair slashdotter to do this, no?
      • Nothing is written to disk, so when the system is powered down, the rootkit vanishes into thin air.

        It is worse than this, actually; Joasia as well as other people points out that malware can be flashed into BIOS and firmware memory on the motherboard and peripheral cards. This is why it was reported that after several recent compromises, sensitive government installations opted to completely replace their equipment. Wiping the disks and reinstalling simply isn't good enough anymmore.

        • by mark_osmd (812581)
          Maybe we should make BIOS flashing a bit harder and have a hardware switch or jumper on the motherboard that has to shorted for flashing to occur. That way it the rootkit attacking the bios or firmware via software would not work.
        • after several recent compromises, sensitive government installations opted to completely replace their equipment.

          That presumes that the replacement hardware hasn't had its BIOS and/or firmware flashed with malware itself. Do they checksum the ROMs and compare that against what the vendor tells them? Can they trust the vendor, or were those parts from offshore? Etc, etc....

          Sometimes I wonder if sensitive government installations are paranoid enough. Probably only the wrong ones are.
          • Which is perhaps why Microsoft OEM agreements lock the OEM into installing Microsoft Windows in the first place.

            Who knows what is happening to the BIOS with modern motherboards and Windows.

      • "Like you said, one can "simply" look at the drive from a clean system. The problem is with rootkits that are only installed in RAM, while the system is running."

        Duh! Just remove the RAM from the system and scan it. Oh, wait...
      • one can "simply" look at the drive from a clean system
        Maybe I've written a rootkit based upon an unknown exploit in the code for the library which reads and writes to the file system used by the partition. Then what would you do? So much for the clean system.
  • TWSS (Score:1, Redundant)

    by kv9 (697238)

    "Maybe we should rethink the design of our computer systems so they they are somehow verifiable," she said.

    that's what she said!

  • well (Score:1, Insightful)

    If sony could rootkit your computer and your hardware couldnt tell, would they?
  • 1) that hardware based rootkit detection is unreliable and
    2) that a beautiful girl cannot be a part of the geeky world of cyber security research (considered exclusively a part of male fiefdom).
    • Re: (Score:3, Insightful)

      by Eivind (15695)
      This stopped being funny like literally 2 decades ago, if ever it was.

      It's true that there are more males than females in in CompSci, but the ones which are there are no more and no less attractive than the average girl in any other line of work. Same goes for the males.

      What the people in CompSci do share is an above-average passion for computing, abstract thinking and maths. (or if they don't they don't belong in CompSci regardless of sex) but neither of these things have any influence on looks.

      • ...an above-average passion for computing, abstract thinking and maths. (or if they don't they don't belong in CompSci regardless of sex)...


        Yeah. Because the only valid reason for anyone to have anything to do with CompSci is because they love the art of it. Anyone pursuing CompSci for any other reason should be kicked out and scoffed. Let's forget the fact that maybe they see CompSci as a way to make the world better.

        Lame.
        • by Eivind (15695)
          In general, I seldom see really cool stuff that makes the world better come from people who are not passionate about what they do.

          The human mind has limits. I am not convinced that it is *possible* to keep learning and studying abstract topics at an advanced level for literally decades without passion. Sure, you can go trough the moves, let your eyes scan the pages, but can you force yourself to pay full attention, to think about a particularily hard problems sometimes at 3am in the nigth when by chance y

          • I think you miss my point. People frequently dive into things they have very little interest in because that subject is the means to an end. Someone may not give a shit about thread scheduling but they might learn everything there is to know and extend the state of the art because their simulations of automobile traffic patterns require it.
            • by Eivind (15695)
              I'd argue that they then actualy *do* care about thread-scheduling and *are* passionate about it. Sure, they may be because of what it allows you to do, rather than because of the topic itself, but that is -- if not the same thing -- then very close anyway.

              By the way, simulation of automobile traffic patterns is a perfectly legitimate CompSci topic. (though the compsci major may (or may not) choose to express the same problem in different terms.

    • by daenz (1066304)
      Man, when she sees it, she calls it, and she's ALWAYS looking for it... now if Microsoft would just listen to this angry-lookin' Polska (I think she's angry FOR all of us!) and take some of her advice... maybe even hire her (on a consultant basis ONLY, please -- if she's an employee, I fear they may corrupt even HER).
    • Polish Blood ;]
  • DRM (Score:3, Insightful)

    by Athrun Zala (1071446) on Sunday March 04, 2007 @11:27AM (#18227028)
    "Maybe we should rethink the design of our computer systems so they they are somehow verifiable," she said."

    Yay, DRM in every piece of hardware to the rescue!
    • Re:DRM (Score:4, Insightful)

      by ymgve (457563) on Sunday March 04, 2007 @11:38AM (#18227094) Homepage
      Yay, DRM in every piece of hardware to the rescue!

      Sounds actually like the exact opposite. DRM tries to hide away things, while this would give devices the ability to see everything that goes on inside the system RAM.
      • by arivanov (12034)
        Err, you are mistaking WankerAA (and their servitors) DRM with DRM in general.

        Digital signatures on all OS and software components, in-system messages (down to OS call level) and anything else that happens in the system is actually a very good way to defeat many possible attacks. Unfortunately without hardware acceleration on RSA and friends this is likely to bring even the fastest modern computer to a crawl.
    • Quite the opposite (Score:3, Insightful)

      by Opportunist (166417)
      We don't need DRM, we need truely "trusted computers". But not computers that some content industries trust, computers that we can trust. Computers where we can actually tap the wires and "listen" to what's going on inside.

      DRM is exactly the opposite. Locking away your computer's inner workings from you, taking away your chance to see what's going on inside.
  • AACS "Improvement" (Score:5, Interesting)

    by SydShamino (547793) on Sunday March 04, 2007 @11:47AM (#18227164)
    At this year's Black Hat Federal conference, she demonstrated three different attacks against AMD64 based systems, showing how the image of volatile memory (RAM) can be made different from the real contents of the physical memory as seen by the CPU.

    Isn't this exactly what HD-DVD / Blu-Ray players need to prevent the AACS keys from being stolen? Just last week there was a story saying something like "PC-based movie players are inherently crackable, because the key has to be in main system memory for at least a brief instance, and then we can copy it." Now, this lady says there are methods to prevent anyone from truly reading what is in RAM. I don't understand.
    • by Dunbal (464142)
      Isn't this exactly what HD-DVD / Blu-Ray players need to prevent the AACS keys from being stolen?

            If the player can read it, I can read it.
      • by Phil Resch (447588) on Sunday March 04, 2007 @02:36PM (#18228606)
        Well, no. Not entirely.

        Under normal conditions, that's correct. If a player has loaded the key into memory somewhere in order to use it, you can probably isolate the location in memory and retrieve the key. Which is what has been done to retrieve the AACS keys.

        But the pathological case, the case dealing with rootkits, changes the game. How do you track the contents of your physical memory? Typically, through OS mechanisms. What happens if a rootkit (or a software media player using rootkit technology) subverts the OS mechanisms? You can't be assured of reliably tracking the contents of memory any more; maybe your OS is LYING to you! What is really in memory is not what you're being told is in memory, and maybe you can't find that key any longer.

        Which brings us back to the article. Direct Memory Access (DMA) is a way of taking the responsibility for managing physical memory access (reading, writing, whatever) away from the processor and moving it to some other place in hardware (presumably some place that you can trust). And that's what hardware-based rootkit detection is about. Use hardware with DMA (which you trust) to access memory instead of letting the processor do the work and relying on the OS to tell you the truth.

        The problem is that the way computers are currently designed, there's no way of starting DMA without having to talk to the processor (by way of the OS) first. Your DMA hardware has to ask "Hey, can I access memory?" and the OS has to say "Sure thing! You do it, and we won't bother the processor any more!"

        But if the (subverted-by-a-rootkit) OS has a vested interest in you NOT being able to get true results using DMA, well, what are you going to do? The OS will just interfere. That's why Rutkowska is suggesting a direct, non-subvertable hardware port that you can jack into to use DMA without having to go through the OS first.
        • by qbwiz (87077) *
          First you modify the OS so it can't be subverted in that way, and then you read the keys. It's a bit like trying to solve the halting problem: the hardware detector tries to check if there's any possible rootkit there, which is impossible (although this is because of the way the computer is manufactured, not because of logic). In cracking AACS, you can make a specific solution which will only detect (and prevent) a certain rootkit, but it will work.
        • by jamesh (87723)
          This suddenly reminded me of a trick on the Commodore 64. The 6510 processor had the first 2 bytes of memory space hardwired to an 8 bit in/out port (mapped to physical pins on the cpu), and an 8 port direction register to control the inny or outyness of the other byte.

          As such there was no way to read those two bytes, ever, as any attempt to access them by the CPU would always read the i/o port bytes instead.

          Then someone figured out that you could view them by mapping screen memory to that location (eg star
    • Re: (Score:2, Insightful)

      by Anonymous Coward
      The difference is that with HD-DVD / Blu-Ray players you *know* there is a key in there, so you will try different (unreliable) methods until you find it. For a rootkit, you're not sure if there is one to start with, so you'll never be sure when to stop searching if you're not finding any.
    • >there are methods to prevent anyone from truly reading what is in RAM.

      What she demo'ed was a way to prevent a card on the PCI bus from having the same view of RAM as the CPU does. Unless the players have an architecture like a PC motherboard her attack may not apply. Fundamentally her attack works because there are two channels for getting information from RAM and the two can be configured differently.
    • by Prune (557140)
      Saying "Now, this lady says" for a woman is equivalent to saying "Now, this gentleman says" for a man, yet I don't see you use this courtesy title for men in your other posts. This smells to me of reverse sexism.
  • by kscguru (551278) on Sunday March 04, 2007 @11:55AM (#18227226)
    Let's see ... last year, she got all over the headlines claiming that virtual machines are a Bad Idea because rootkits could use them to remain undetectable (even though virtual machine experts [blogspot.com] discounted her "trivially easy and left unimplemented" parts as technically intractable).

    And now a year later, she claims we need specialized hardware interfaces to scan memory for rootkits, even though this problem is laughably easy in the world of virtual machines.

    And on to the actual work [com.com] ... the research basically observes that MTTR registers (some of the MSRs in the CPU) can cause memory mappings to look different between the CPU and the northbridge, and then comes up with a pretty easy way to cause the northbridge to either lock up or read data that is different (really easy once you see the specs for the appropriate registers). And she totally ignores the possibility of a system defending itself against this attack by verifying the registers she's modifying. Lousy research, girl.

    Oddly enough, this "hack" is ALREADY IN USE ON YOUR SYSTEM and is actually necessary. See, when the processor is running in SMM (System Management Mode), it switches to exactly this configuration: the PCI bus sees VGA hardware mapped at the well-known address, but the processor maps the RAM at that address, which gives SMM mode a few kilobytes of memory that the normal system can't touch. SMM mode is used for things like "legacy USB devices" (e.g. having your USB keyboard act like PS/2 so DOS can use it) and other implement-in-software hacks that your OS doesn't know about, but your BIOS vendor gives you as "value-added features".

    • Re: (Score:3, Interesting)

      by Jah-Wren Ryel (80510)

      Let's see ... last year, she got all over the headlines claiming that virtual machines are a Bad Idea because rootkits could use them to remain undetectable (even though virtual machine experts discounted her "trivially easy and left unimplemented" parts as technically intractable).

      Gee, I read the articles on the other end of those links and they boil down to two points - (1) it is hard to do and (2) it is detectable via timing analysis

      Obviously (1) is really no defense at all because it only needs to be do

      • by kscguru (551278)
        Obviously (1) is really no defense at all because it only needs to be done once and then it is "free"

        If you read the other end of those links, you'll read people who have been working on this problem a long time declaring it technically hard. Pass-through won't work because hardware's view of memory isn't virtualized; virtualizing devices doesn't work because of the need to virtualize every device in the underlying system (and the implicit need to know about every possible interface to do so). Sure it o

        • Rootkit VMs are "impossible" in the same sense that cracking strong crypto is "impossible".

          You really seem to be drinking the same kool-aid you accuse Rutowska of - there is nothing even remotely like the rigorous mathematical proof of crypto in the VM world. All there is the opinion of people, who are certainly experienced but hardly infallible.

          Just an external time source - since the detection code is arbitrary (i.e. I could be sending cryptographically signed timestamps, or reading a timestamp off some

          • by kscguru (551278)

            Rootkit VMs are "impossible" in the same sense that cracking strong crypto is "impossible".

            You really seem to be drinking the same kool-aid you accuse Rutowska of - there is nothing even remotely like the rigorous mathematical proof of crypto in the VM world. All there is the opinion of people, who are certainly experienced but hardly infallible.

            When my doctor says "take this pill or you'll stay sick", he's certainly experienced but hardly infalliable. Yet I don't accuse him of being wrong.

            Anyway, yo

            • When my doctor says "take this pill or you'll stay sick", he's certainly experienced but hardly infalliable. Yet I don't accuse him of being wrong.

              YOU are the one who tried to co-opt the rigorous mathematical proof of strong crypto in the first place, not me.

              If you dispute the last point, I challenge you to come up with a way to virtualize arbitrary hardware devices.

              You've done it again now, twice in a row you have disproven your own original claim about not needing specialized hardware. It really seems li
    • by Wanderer1 (47145)
      This is the second post I've seen on the Internet denouncing her work as "lousy research." I have yet to see a reason to consider it "lousy."

      Can you point out a reason why it would NOT work today? And what mechanisms are in place today to ensure that this trickery does not occur?

      Either rebut the core argument, that hardware-based memory retrieval is subject to manipulation by malware, or join a discourse. But to dismiss out of hand has no merit. Whether the mechanisms for remapping I/O space are legitim
      • by kscguru (551278)
        Either rebut the core argument, that hardware-based memory retrieval is subject to manipulation by malware

        Irrelevant. Hardware-based memory retrieval was already subject to manipulation by malware - she's found a new way of doing so, nothing exciting here. (How was it possible before? As mentioned above, SMM BIOSes already use the same tricks to make some memory non-accessible by devices. They aren't using it for malware - and they aren't deliberately trying to hide themselves - but the effect is the

    • >ignores the possibility of a system defending itself against this attack by verifying the registers she's modifying. Lousy research, girl.

      The case under study is a rootkit preventing external analysis. The real system has lost its ability to defend itself by that point, or else it wouldn't be rooted. The real system is no longer in charge of the memory mapping registers after the rootkit takes over. A system trying to defend itself against an attacking process that has direct hardware access is a system
  • by LS (57954) on Sunday March 04, 2007 @12:09PM (#18227342) Homepage
    and reasonably cute, blah blah basement blah blah over 30 blah blah imaginary blah blah
    • Nah. (Score:1, Offtopic)

      by antdude (79039)
      I diasagree on the cute part. She doesn't look cute and that attractive to me even after doing a Google image search.
      • by Jugalator (259273)
        Lucky for her perhaps -- just imagine all geeks stalking her if she was both a skilled rootkit researcher *and* looked like Natalie Portman!
    • by wamatt (782485) *
      Actually many in the community think "she" is in fact Mr Jan Krzysztof Rutkowski. A security researcher that "dissappeared" circa 2003, the same time Rutowsk*A* appeared on the scene.

      http://en.wikipedia.org/wiki/Talk:Joanna_Rutkowska [wikipedia.org]

      The other hypothesis is of course she/he USED to post as a male (perhaps she/he thought the work would be taken more seriously)

  • good luck... (Score:3, Insightful)

    by sholden (12227) on Sunday March 04, 2007 @12:20PM (#18227436) Homepage
    The MPAA/RIAA would just *love* it if there was a port on your motherboard you could just plug something into and get direct access to the contents of RAM, bypassing OS completely.
  • by btarval (874919) on Sunday March 04, 2007 @12:33PM (#18227574)
    "I'm thinking about motherboard manufacturers adding a special port which would allow for *direct* (this time really "direct") access to RAM and potentially some other critical resources like e.g. CPU system registers and maybe even caches," she said.

    You can already do this, with many common CPUs. It's called JTAG. In short, it allows you to control the CPU directly, so that you can do exactly what Ms. Rutkowska proposes. That includes by-passing the caches and getting direct access to memory.

    JTAG is what embedded people use to port an O.S. to a new hardware platform. And to debug really tough kernel problems. It beats the snot out of printks anyday. And there are certain sections of boot-code and kernel code where it is extremely difficult and annoying to develop without JTAG.

    There are two immediate problems with JTAG however. The first is that not all CPUs support it. Believe it or not, I've met CPU designers who have never heard of JTAG (and this is usually a clue that they don't know what the heck they are doing).

    The second problem is that some CPU manufacturers consider the JTAG interface proprietary. Intel is one (there's only one JTAG debugger available for x86, and it will cost you between $5,000 - 15,000 depending on what you get). That is absolutely silly, as these can be built for well under $500.

    Why they keep the JTAG API interface proprietary is beyond me. I have yet to hear a non-lame excuse yet.

    But in any case, the point is that this problem has already been solved. It's surprising to me that anyone seriously doing forensics wouldn't be using JTAG already, for the reasons that Ms. Rutkowska suggests.

    • by Wanderer1 (47145)
      Just a thought on the "surprising that anyone seriously doing forensics..." part - if the interface costs 5-15k, it's probably not in the hands of the smaller businesses that cranked up the forensics market. Perhaps you have a first-mover advantage in the forensic software business here? ;) I'll invest $500 if I can save $4500.

      W

      • by btarval (874919)
        That's an interesting thought. A collaborative effort in purchasing an x86 JTAG ICE might fly. I suppose if one got enough people together to distribute the costs, in exchange for a guaranteed minimum amount of time with the box, it might work.

        But it's far more likely that someone will just offer more detailed services for a higher price. Or you can rent one probably for about $1,500 per month.

        The other alternative, building one's own, requires getting under NDA with Intel. But even that's no guarantee.

    • When I used to do embedded debug, my employer used 8051 and there were about half a dozen in-circuit emulators around; we needed more grunt and started using the 80188, and the ICEs were about GBP15000 at the time (18 years ago, so about GBP25000 or USD38000 in todays money). There was only one rival emulator at the time, and we tried it and it was crap. Seemed that the ICE had a special version of the microcontroller in it that only Intel's test equipment team could use.

      Another department learned from o

  • The slide set mentions accessing memory via FireWire, but doesn't say much about it. FireWire understands packets for "reading and writing memory", along with ordinary data packets. But whether memory access packets actually read and write physical memory is up to the driver, when it configures the FireWire controller. The driver can set controller registers so that the physical address range accessible from the hardware controller is limited. Other addresses just pass the packets to the driver.

    So i

  • Seems like the Rutkowska paper a) exposes PCI cards used as memory verifiers as unreliable in off-the-shelf hardware--the PCI memory verifier products cited in the paper (one is from BBN no less) might not have been properly reviewed, and might be in use in US DOD computing systems b) sheds some light on how COTS hardware _could_ be less vulnerable to rootkit manipulation, if customers demand it--not unreasonable.
  • Without consideration of the problem at the time all of the system hardware is designed, there is no secure solution. This is in fact a very complex problem.

    For instance, most CPUs and complex driver chips include undocumented registers, which can be used to hide code or data from analysis. Some of these register areas can be quite large. The common solutions almost invariably rely on security through obscurity, since the internal design of chips is not widely available. How can one clear or verify memory

    • by lgw (121541)

      No, you can't build a secure system without secure hadware, and you can't verify the contents of memory without special hardware support.

      On the positive side, it wouldn't take much. Tandem-style computers, where two independent systems share the same motherboard and each CPU can access the memory/PCI bus/etc of the other in an asymetric fashion aren't new. The idea that one of the CPUs is the system master and always has precedence wouldn't be a big change. Such systems are quite expensive simply bacuase

  • Keep in mind I'm actually an Ex HW_Hack ........ From Wikipedia:

    A rootkit is a set of software tools intended to conceal running processes, files or system data from the operating system. Rootkits have their origin in relatively benign applications, but in recent years have been used increasingly by malware to help intruders maintain access to systems while avoiding detection. Rootkits exist for a variety of operating systems, such as Linux, Solaris and versions of Microsoft Windows. Rootkits often modify
  • Joanna Rutkowska's research is catching up to a truth few realized until just recently, This is just the tip of a whole can of worms that has been wiggling right under our noses for years.

    If you check the comments below, (to a very good article) some commenters are rather hysterical, (in a bad way) and for good reason, but reflect the truth.

    Rootkits headed for BIOS
    Comments:

    http://www.securityfocus.com/cgi-bin/index.cgi?c=a rticlecomments&op=display_comments&ArticleID=11372 &expand_all=true&m [securityfocus.com]
    • by Teun (17872)

      After reading this, if you don't have experience in these matters please refrain from commenting.

      "There are more things in heaven and earth , Haratio, than are dreamt of in your philosophies."
      Haratio, is he related to that famous character called Horatio?
      • Teun:
        "Haratio, is he related to that famous character called Horatio? '

        I bet you're right, and I bet you pretty much know what I meant.
        Have you got anything to contribute, as per the subject? Or, are you just checking hall passes?

        Everyone makes mistakes, ... don't you agree?
        Don't feel bad - It' a human condition, you'll get over it, I did.

        http://slashdot.org/comments.pl?sid=221826&cid=179 73182 [slashdot.org]

        "... claiming their IP is being infringes upon and ..."

        Here, check this out, it's pretty fascinating stuff (PC-
        • by Teun (17872)
          Hehe :)
          Yes we all make mistakes.
          It was the 'refrain from commenting' bit that was so inviting...
          Glad you did not take it too seriously and instead contributed another On Topic link!
    • BIOSes, or configuration EEPROMs on peripheral cards. The researcher who pointed out that latter possibility thinks it won't be an issue because conventional rootkits are already so easy. Kind of a cynical reassurance, but probably accurate.
  • http://www.rutkowska.yoyo.pl/ [rutkowska.yoyo.pl]

    "Until July 2003, a computer security researcher Jan Krzysztof Rutkowski used his school-provided e-mail account at Warsaw University of Technology (jkrutkowski@elka.pw.edu.pl) to publish various security materials on Windows kernel rootkit hiding and detection...This person had ceased all public security research mid-2003.

    Within less than two months, a previously unknown researcher named Joanna Rutkowska began to publish papers on Windows rootkit detection and hiding techni

  • I worked for Guardent for a while, and their coders were the elitist of the elite, if you listened to them. Then you read something like this to show what yutzes they were.
  • [Neo sees a black cat walk by them, and then a similar black cat walk by them just like the first one]
    Neo: Whoa. Déjà vu.
    [Everyone freezes right in their tracks]
    Trinity: What did you just say?
    Neo: Nothing. Just had a little déjà vu.
    Trinity: What did you see?
    Cypher: What happened?
    Neo: A black cat went past us, and then another that looked just like it.
    Trinity: How much like it? Was it the same cat?
    Neo: It might have been. I'm not sure.
    Morpheus: Switch! Apoc!
    Neo: What is it?
    Trinity: A d
  • Just when the good guys think they got it right, the bad guy gives a smug and says, "really?" Sometimes we forget that the main motives for hackers to hack are challenge, fame, ideology, and sometimes money...

Did you know that for the price of a 280-Z you can buy two Z-80's? -- P.J. Plauger

Working...