Hacker Defeats Hardware-based Rootkit Detection

I thought this was invalid anyway by LiquidCoooled · 2007-03-04 04:08 · Score: 4, Insightful

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.

--
liqbase :: faster than paper

Re:I thought this was invalid anyway by Zephiria · 2007-03-04 04:10 · Score: 1

Whenever I clean a system, thats pretty much what you have to do.
Trying to clean up a running system is just insanity.
Re:I thought this was invalid anyway by JackHoffman · 2007-03-04 04:19 · Score: 5, Insightful

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:I thought this was invalid anyway by networkBoy · 2007-03-04 04:42 · Score: 1

To that end do you know of any particularly good live CD's for the task (windows box)?
-nB

--
whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
Re:I thought this was invalid anyway by Anonymous Coward · 2007-03-04 04:55 · Score: 1, Interesting

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, which also means that malware could lie. There is usually a lot more contiguous memory than you might think and there are hardware limitations on some platforms as to how memory can be paged and fragmented but the bottom line is you need something that the CPU has to really know where the memory you think you're reading really is. I would guess that a hardware malware detector wouldn't be terribly useful without some integration to the CPU. I don't have a PCI spec in front of me but I'd bet that hardware can't arbitrarily read any memory it wants without the CPU allowing it. (Shit, think of the firmware malware possibilities if it could, more importantly a PCI device could have it's own memory to hide in that the CPU cannot see..)

Drivers and hardware devices can DMA in and out of memory, but they lock a specific location and they always tell the CPU. The CPU owns memory, that's the rule and unless it gives ownership to some other device (such as it might during a DMA) then you have to involve the CPU anytime you wish to decode memory.

I respect that hell out of Joanna, I kind of think her 2 big findings were a bit of PR though. The Blue pill one was kind of good because a lot of people have virtualization hardware that don't know it but the short of it was if you have v14n hardware you need to use it and at least install some minimal hypervisor so a malware doesn't. This seems like more of the same; if I get my malware in there deep enough, I can really confuse most attempts to debug it. Viruses have had anti-debugging technologies since the 80's. It's kind of the classical host debugging problem, you really need to do certain types of debugging from a different host, even then there are hooks you need on the host machine (unless it has jtag or something) and those hooks can be corrupted. I don't know that this is news exactly.
Re:I thought this was invalid anyway by MrShaggy · 2007-03-04 05:00 · Score: 1

Just off the top of my head .. try
http://www.bootdisk.com/. They either have it, or they will have a link for it.

--
I have mod points and I am not afraid to use them.
Re:I thought this was invalid anyway by Score+Whore · 2007-03-04 05:06 · Score: 0

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.
Re:I thought this was invalid anyway by przemekklosowski · 2007-03-04 05:14 · Score: 1

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.
Re:I thought this was invalid anyway by Anonymous Coward · 2007-03-04 05:20 · Score: 0

Whether that is worse depends on your point of view. An attacker who wants to avoid detection will not write anything to persistent storage. An attacker who wants to make sure that he can get back in could use firmware storage to make the backdoor persistent.
Re:I thought this was invalid anyway by noidentity · 2007-03-04 05:26 · Score: 1

"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...
Re:I thought this was invalid anyway by nneonneo · 2007-03-04 05:37 · Score: 1

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.
Re:I thought this was invalid anyway by mark_osmd · 2007-03-04 05:44 · Score: 1

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.
Re:I thought this was invalid anyway by Sancho · 2007-03-04 06:03 · Score: 1

BartPE is pretty useful: it's a Windows LiveCD environment.

http://www.nu2.nu/pebuilder/
Re:I thought this was invalid anyway by Score+Whore · 2007-03-04 06:55 · Score: 4, Informative

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.
Re:I thought this was invalid anyway by Anonymous Coward · 2007-03-04 08:00 · Score: 0

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
We do, this setup and "dual BIOS" (failover to a second BIOS if the first becomes corrupted) became fairly popular after the CIH virus.
Re:I thought this was invalid anyway by Chandon+Seldon · 2007-03-04 08:33 · Score: 1

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 able to tell *anything* about timing across a network - bullshit. Utter bullshit.

--
-- The act of censorship is always worse than whatever is being censored. Always.
Re:I thought this was invalid anyway by Anonymous Coward · 2007-03-04 08:55 · Score: 0

don't know what you're talking about. devices can dma to any address they want to. the cpu isn't involved in bus transactions and has no way to stop a transaction from happening. the only thing the cpu does is program the "correct" address in the device's registers, so that it accesses the correct memory. program the wrong address and you'll overwrite (or read from) random memory.

control of a device's dma is a very real security concern. if a hacker could do that, they could copy any random memory location to another location, bypassing cpu security.
Re:I thought this was invalid anyway by HomelessInLaJolla · 2007-03-04 09:42 · Score: 1

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.

--
the NPG electrode was replaced with carbon blac
Re:I thought this was invalid anyway by Bri3D · 2007-03-04 09:49 · Score: 3, Informative

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.
Re:I thought this was invalid anyway by Anonymous Coward · 2007-03-04 10:10 · Score: 0

Use two alternative implementations on two identical images of the partition. But you have modified the harddisk firmware to inject the rootkit into the clean system through a bug in the controller driver, right?
Re:I thought this was invalid anyway by FooMoeDee · 2007-03-04 11:04 · Score: 1

you have modified the harddisk firmware to inject the rootkit into the clean system through a bug in the controller driver, right? No need. I've already stored the rootkit in your monitor Energy Star BIOS and have made use of a hardware exploit in your NIC to re-insert it in your MBR every time you power on.

--
Foo'-Mo'-D says,"Wutup foo?"
Re:I thought this was invalid anyway by Score+Whore · 2007-03-04 11:06 · Score: 1

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 the typical background noise.
As for being able to tell *anything* about timing across a network - bullshit. Utter bullshit.

Um. Really? You mean my stratum-1 radio based ntp server can't let my system know what time it is supposed to be? And thus my system can't detect changes in it's clock drift? Or are you saying that I wouldn't be able to detect changes in keepalive intervals over time? What you say is generally true if you are taking a single sample. But if you take 100 samples or 1000 samples you most certainly can detect systemic changes.

Given that private key recovery has been demonstrated by timing CPU cache misses remotely across a network, I would be more careful with your claims of bullshit.
Re:I thought this was invalid anyway by Anonymous Coward · 2007-03-04 11:57 · Score: 0

When you try to measure the overhead, you'll discover the TSC and clock skew are perfectly normal because the hypervisor is changing the code that's reading them - and in fact it's entirely within the normal limits that the clock rate and internal voltages of a processor can drift apart from each other (and no, they don't do it at a constant rate, in fact, they wander around randomly, as it's mostly thermal noise causing it), so even if you compared performance, clock speed or power consumption to some metric in hardware, you couldn't draw a clear conclusion.

Frankly, you'd be better off looking at the behaviour of the L1 instruction cache, but you'd be tripped up on false positives thousands of times by the errata of revisions of the particular core you were using, and the many (now extremely complex) ways in which branch prediction can stall. Are you really going to try to account for that instruction that ran 200 instructions ago that was operating on something completely different in another process that your processor mistakenly thought was worth keeping a 1K chunk of code around for, in case it wants to go there again?

Again, you might be surprised how much noise is present in a perfectly normal, unrooted system. If you're talking about a highly embedded static system like a smart card, exotic techniques like this might be practical. If you're talking about an actual fully-fledged computer from this century running a common, conventional operating system, please allow me to point and laugh.

And again, since you're running under the hypervisor, if it spotted you looking at it in that kind of detail, suddenly everything's Perfectly Normal, and clearly Somebody Else's Problem. If necessary, the rootkit can unload itself cleanly from memory, and then nothing is any the wiser.

This is a rediscovery of an old technique, resurrected in the face of hardware debuggers (which are really terribly rare) viewed as an adversary.

The overhead of a hypervisor whose whole purpose is stealth patches (to spawn a hidden process which even the kernel doesn't know it knows about, because the memory reads - including DMA - one thing, but executes another) and corresponding cloaking of DMA is very much less than that of a fully-fledged virtual machine. As far as you know, it's idle time - and your processor spends a lot of time idle, doesn't it? Even when it's at "100% CPU". You'd be amazed.
Re:I thought this was invalid anyway by raddan · 2007-03-04 13:08 · Score: 1

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?
Re:I thought this was invalid anyway by andreyw · 2007-03-04 13:14 · Score: 2, Insightful

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....
Re:I thought this was invalid anyway by networkBoy · 2007-03-04 14:43 · Score: 1

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

--
whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
Re:I thought this was invalid anyway by Score+Whore · 2007-03-04 17:13 · Score: 1

And again, since you're running under the hypervisor, if it spotted you looking at it in that kind of detail, suddenly everything's Perfectly Normal, and clearly Somebody Else's Problem. If necessary, the rootkit can unload itself cleanly from memory, and then nothing is any the wiser.

Yeah, because those damned root kits with their 2400 SAT scores and their poetry, songwriting, and painting are just too damned intelligent and creative!

Oh wait. It's code. It's not smart. It's not creative. It won't look at code and determine that this piece of code is just your bog standard SQL engine and, AHA!, that piece of code is a loop to detect performance degredation. It can only do what it was programmed to do. It just might reset the TSC to hide the cycles it uses. It might trap accesses to the 18 ms timer and instead return fake results. It might do the same to the high speed timer. Of course once you start doing all this your system's idea of the time of day will start to drift in a persistent direction.
The overhead of a hypervisor whose whole purpose is stealth patches (to spawn a hidden process which even the kernel doesn't know it knows about, because the memory reads - including DMA - one thing, but executes another) and corresponding cloaking of DMA is very much less than that of a fully-fledged virtual machine.

No. The memory reads exactly what it's supposed to read. Always. Either you didn't understand the slides from the presentation or you are just making shit up based on incomplete understanding. There are two tricks being pulled by the malware in this discussion: 1) hiding from DMA transfers by incompletely programming MMIO on AMD CPUs, 2) virtualizing the virtual memory and I/O systems. No, not virtualizing your NIC, but yes, virtualizing the instructions that allow you to talk to your NIC. Capturing every DMA setup so that you don't overwrite the hidden malware. Capturing every interrupt.

Don't forget too that current hardware virtualization is slow. So slow that VMware only uses it if you specifically request that it does so because their software solution is faster.
As far as you know, it's idle time - and your processor spends a lot of time idle, doesn't it? Even when it's at "100% CPU". You'd be amazed.

Unless of course I control the scheduler. I have physical access. I know the passwords that will allow me to run software that can prevent the OS's normal scheduler from operation for a short duration. Then there's no idle time. Then I can go ring-0 or emulated ring-0 (or virtualized if you prefer that language, but either way, the malware has to emulate the correct functioning of the system, failure to do so would be a huge hint that something is going on.) Then I can go into a tight little loop with a fixed number of iterations and start executing a bunch of privileged instructions, like say, modifying page tables or MTRR entries or MMIO settings. Suddenly a lot of CPU cycles are being spent in the malware (servicing the required faults and emulating instructions.) My code is doing a tiny bit of work. So the ratio of cycles can be something like 10% my loop, 90% malware. A loop that may have previously taken 1 second now takes 10. Even with just a plain old stop watch for timing that will be really easy to see.

I'm not saying that OS vendors are going to be implementing this kind of thing as your day-to-day security practice. No more than someone will be running around in your datacenter hooking up hardware memory sniffers. But if you suspect there is a problem, you can detect these kinds of things.

TWSS by kv9 · 2007-03-04 04:13 · Score: 0, Redundant

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

that's what she said!

--
Stop Computers/Cars Analogies on S

well by mastershake_phd · 2007-03-04 04:15 · Score: 1, Insightful

If sony could rootkit your computer and your hardware couldnt tell, would they?

--
Libertarian Leaning Political Discussion Forum.

she shatters two myths really ... by ravee · 2007-03-04 04:16 · Score: 1, Flamebait

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

--
Linux Help
for all things on Linux

Re:she shatters two myths really ... by Eivind · 2007-03-04 04:45 · Score: 2, Insightful

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.
Re:she shatters two myths really ... by Score+Whore · 2007-03-04 05:08 · Score: 1

...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.
Re:she shatters two myths really ... by Eivind · 2007-03-04 05:55 · Score: 1

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 you wake up, without passion for your subject ? I don't think so, but if you can, more power to you.
This ain't nothing special for CompSci by the way, I don't think there's really great musicians, doctors, painters, or sports-people who aren't passionate about what they do.
I never suggested kicking anyone out by the way. I just said I don't think they belong. If they think differently, they're offcourse free to go at it.
Re:she shatters two myths really ... by rajafarian · 2007-03-04 05:59 · Score: 0, Offtopic

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

That reminds me of when I was studying Physics at a small state college, the University of Wisconsin - Whitewater... The physics department was quite small and almost every Physics student knew every other Physics student, and we all knew one thing: there were no girls in Physics, well, there was one but she was quite ugly (but she was real nice).

Anyway, one day it was the first day of Physics and this really HOT blonde rushed in and as she sat way in the back our Physics teacher said, "Excuse me, miss, I think you're in the wrong class room." We all knew that was the case but were hoping it wasn't. She asked if it some other class, the teacher said, "No." After she had walked out the door the whole class, all half dozen or so of us, burst out laughing so loudly that you could probably have heard us laughing in any other classroom in that floor. Now that I think about it, it might have been crying masqueraded as laughing.

True story. Off-topic? So sue me.
Re:she shatters two myths really ... by Anonymous Coward · 2007-03-04 06:33 · Score: 0

You have dont even have a clue re 1) and i wont comment on 2) except to say she's an overrated attention whore. Women have to work harder than men to be acknowledged? BWAHAHAHAHAHA...
Re:she shatters two myths really ... by Score+Whore · 2007-03-04 07:02 · Score: 1

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.
Re:she shatters two myths really ... by Eivind · 2007-03-04 07:11 · Score: 1

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.
Re:she shatters two myths really ... by daenz · 2007-03-04 17:51 · Score: 1

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).
Re:she shatters two myths really ... by harry666t · 2007-03-05 02:25 · Score: 1

Polish Blood ;]

Ryan Naraine by Anonymous Coward · 2007-03-04 04:16 · Score: 0

that guy is hot!

DRM by Athrun+Zala · 2007-03-04 04:27 · Score: 3, Insightful

"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 by ymgve · 2007-03-04 04:38 · Score: 3, Insightful

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.
Re:DRM by Anonymous Coward · 2007-03-04 04:42 · Score: 0

Not only that, it's becoming a non issue. How would a rootkit install itself above a hypervisor on a box where the boot sector is on write protected FLASH? This is where my current desktop is at...
Re:DRM by arivanov · 2007-03-04 05:01 · Score: 1

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.

--
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
Re:DRM by Anonymous Coward · 2007-03-04 05:29 · Score: 0

Just having it in-place makes it easier for the MAFIAA or Government to abuse. I'd prefer to be without DRM at all than give these bastards the opportunity to fuck us all over with it.
Re:DRM by Cheesey · 2007-03-04 07:45 · Score: 1

Not only that, it's becoming a non issue. How would a rootkit install itself above a hypervisor on a box where the boot sector is on write protected FLASH?

Perhaps it might exploit a security hole in the hypervisor itself.

--
>north
You're an immobile computer, remember?

This is news? by Anonymous Coward · 2007-03-04 04:37 · Score: 0

Software can't reliably detect a system problem in all cases.

See also "The Halting Problem." What are they teaching people in IT classes these days?

Re:This is news? by Anonymous Coward · 2007-03-04 04:44 · Score: 0

Read the headline. This is a hardware-based detection method.

BIOS by tepples · 2007-03-04 04:46 · Score: 2, Insightful

How would a rootkit install itself above a hypervisor on a box where the boot sector is on write protected FLASH? By flashing the BIOS.

Re:BIOS by Anonymous Coward · 2007-03-04 04:54 · Score: 0

Would not the interface need to be emulated to do that from within a VM host?
Re:BIOS by tepples · 2007-03-04 08:44 · Score: 1

Would not the interface need to be emulated to do that from within a VM host? Not if the hypervisor has a defect.

AACS "Improvement" by SydShamino · 2007-03-04 04:47 · Score: 4, Interesting

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.

--
It doesn't hurt to be nice.

Re:AACS "Improvement" by Dunbal · 2007-03-04 06:28 · Score: 1

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.

--
Seven puppies were harmed during the making of this post.
Re:AACS "Improvement" by Anonymous Coward · 2007-03-04 06:29 · Score: 2, Insightful

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.
Re:AACS "Improvement" by Phil+Resch · 2007-03-04 07:36 · Score: 4, Informative

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.
Re:AACS "Improvement" by qbwiz · 2007-03-04 08:34 · Score: 1

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.

--
Ewige Blumenkraft.
Re:AACS "Improvement" by Prune · 2007-03-04 18:45 · Score: 1

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.

--
"Politicians and diapers must be changed often, and for the same reason."
Re:AACS "Improvement" by jamesh · 2007-03-05 16:51 · Score: 1

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 starting at address $0000). And, you could then use the hardware based sprite collision detection in the video chip to read them (collision = 1, no collision = 0).

I'm not sure that there was ever a way to write to the memory under the i/o port bytes, so the hack wasn't really very useful, but it does illustrate that you should never say never... and as a system gets more and more complicated, there is more and more opportunity for loopholes like this to creep in.

Re:Why does this chick get so much press on Slashd by Hal_Porter · 2007-03-04 04:55 · Score: 2, Funny

To be honest though, the sharp knees ruin it for me.

Plus when you think about it, sperm is the ultimate malware.

--
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;

Trying to have her cake and eat it too? by kscguru · 2007-03-04 04:55 · Score: 4, Insightful

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

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

--

A witty [sig] proves nothing. --Voltaire

Re:Trying to have her cake and eat it too? by Jah-Wren+Ryel · 2007-03-04 06:44 · Score: 2, Interesting

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 done once and then it is "free" and (2) is deceptively difficult to implement in a fool-proof manner that does not incur large costs on a per-site basis -- it requires an external time source *and* an external performance measurement system because any time data entering the compromised machine (say via NTP) can itself be twiddled to hide timing variations. The obvious method of such a test would be to run a (potentially) trapped instruction that normally takes microseconds but when trapped takes milliseconds. Run it in a loop 100,000 times and the difference will be discernible to a human watching it - but what if the vm is smart enough to recognize such an automated test and temporarily disable the trap for the duration of the test? Not an easy test to implement, not to mention that anytime you have to get a human involved the deployment costs sky-rocket.
she totally ignores the possibility of a system defending itself against this attack by verifying the registers she's modifying. Lousy research, girl.
What is to prevent that rootkit-VM (the one that twiddled the registers in the first place) from faking out any attempt by the legit OS to read those registers? Isn't that point of a rootkit-VM, to fake out any parts of the system that need faking out so that the rooted OS can't detect it?

--
When information is power, privacy is freedom.
Re:Trying to have her cake and eat it too? by Wanderer1 · 2007-03-04 08:29 · Score: 1

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 legitimate or not isn't in question. The question is whether we have a legitimate hole in our use of RAM dumps as forensic evidence.
Re:Trying to have her cake and eat it too? by Beryllium+Sphere(tm) · 2007-03-04 09:29 · Score: 1

>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 in an unwinnable arms race at the very best.

>claiming that virtual machines are a Bad Idea because rootkits could use them to remain undetectable

That's a different reading of her "blue pill" work than mine.
Re:Trying to have her cake and eat it too? by Goaway · 2007-03-04 09:56 · Score: 1

Girls threaten his utter manliness.
Re:Trying to have her cake and eat it too? by kscguru · 2007-03-04 13:03 · Score: 1

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 only needs to be done once ... just like proving P = NP only needs to be done once. That doesn't make it possible.
Rootkit VMs are "impossible" in the same sense that cracking strong crypto is "impossible". Rutkowska's research says "assume VMs are undetectable. Then attack X is possible". This is akin to saying "assume strong crypto can be cracked. Then attack X is possible", except Rutkowska ignores the experts who say that undetectable VMs are as unsolvable as strong crypto.
I'm quite serious when I say that Rutkowska has done some work, stated "the rest is left as an exercise for the reader", and declared victory. Catch is, anyone doing work on VMs sees that she's done 10% of the work and ignored the 90% where there are known difficulties she gleefully ignores. The woman DELETES criticisms from her blog and dismisses other attacks as "theoretical" (Anthony Liguori is a Xen contributor). Odd ... her rootkit is far more theoretical than the attacks against it, since solid rootkit-detectors exist and her rootkit is a self-admitted prototype that ignores the need to hide itself.
(2) is deceptively difficult to implement in a fool-proof manner that does not incur large costs on a per-site basis -- it requires an external time source *and* an external performance measurement system
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 well-known URL like yahoo.com), it's not possible to block the external measurement. (Sure the VM could look for such loops, but it has to detect any POSSIBLE loop, even dynamically generated ones, which is a halting problem variant and thus undecidable).
I've heard a second defense against timing analysis: ban external time sources. But this means banning a machine from the Internet, which escapes the whole security problem anyway.
What is to prevent that rootkit-VM (the one that twiddled the registers in the first place) from faking out any attempt by the legit OS to read those registers?
Because it doesn't have to be the OS reading them - it could be SMM code, or even a device snooping northbridge bus accesses to detect oddly-mapped memory accesses. But anyway, this assumes at rootkit-VM is possible anyway - and we return to point (1).

--
A witty [sig] proves nothing. --Voltaire
Re:Trying to have her cake and eat it too? by kscguru · 2007-03-04 13:21 · Score: 1

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 same).
There are only two new wrinkles here. (1) using the PCI mapping manipulations to deliberately hide code instead of accidentally hiding data, and (2) assuming that the PCI mapping modifications are undetectable because of a fantasy rootkit-VM. In fact, I don't think Rutkowska actually claimed (2); I point it out only because everyone arguing with me assumes it.
The question is whether we have a legitimate hole in our use of RAM dumps as forensic evidence.
If you were assuming RAM dumps are perfect, unforgable forensic evidence before, then yes, there's a new hole there. Me, I look at the whole idea as absurd (if there's a PCI device to capture memory, it has to connect to the PCI bus, which means it has to exist in PCI space, which means any rootkit would be able to see it, and why is it the rootkit is being insanely smart about hiding itself from PCI devices while still being stupid enough to run on a system with a PCI RAM dumper?)

--
A witty [sig] proves nothing. --Voltaire
Re:Trying to have her cake and eat it too? by Jah-Wren+Ryel · 2007-03-04 14:12 · Score: 1

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 well-known URL like yahoo.com), it's not possible to block the external measurement. (Sure the VM could look for such loops, but it has to detect any POSSIBLE loop, even dynamically generated ones, which is a halting problem variant and thus undecidable).
Crypto signatures mean nothing when the machine signing or validating the signatures is compromised, why would you think otherwise? As for being impossible to detect detectors, if the detector is known (e.g. Symantec Norton Anti-VM-Rootkit now with Dynamically Generated Code Timing Analysis) it can easily be compromised. If it is home-grown, well see my point about expense and feasibility for the average data-center.
The woman DELETES criticisms from her blog and dismisses other attacks as "theoretical" (Anthony Liguori is a Xen contributor). Odd ... her rootkit is far more theoretical than the attacks against it, since solid rootkit-detectors exist and her rootkit is a self-admitted prototype that ignores the need to hide itself.
You are doing exactly the same thing you accuse her of - arguments based on misdirection, not arguing the facts. For one thing, the whole hullabaloo about Liguori's mention of timing attacks being dismissed as "theoretical" has been overcome by events in the 9 months or so since then with more substantive dismissals (I didn't make up these points about not being able to trust any timing analysis done on a compromised machine, they came out of the discussions of said "theoretical" attacks).
Because it doesn't have to be the OS reading them - it could be SMM code, or even a device snooping northbridge bus accesses to detect oddly-mapped memory accesses.
So, now you are saying that, "we need specialized hardware interfaces to scan memory for rootkits"?

--
When information is power, privacy is freedom.
Re:Trying to have her cake and eat it too? by kscguru · 2007-03-04 20:56 · Score: 1
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, you want a quasi-mathematical argument?
- The problem: whether a rootkit-VM can hide itself from a "guest" without serious performance degredation or lack of functionality.
- Given: the "guest" can run any arbitrary code it wants. This follows from the requirement of not lacking functionality.
- Lemma: the rootkit-VM cannot detect "guest" code trying to detect a rootkit. Why? Solving the general case is akin to the halting problem (trivially: the guest code halts if it detects a rootkit), and is thus undecidable. The best we can do is heuristics: guest code looks like a rootkit detector and should be modified to give wrong answers. Problem is, any heuristic has false positives and/or false negatives (else it would solve the halting problem); false negatives would allow detection of the rootkit directly and false negatives would allow detection indirectly (trivially: my program said "safe", a real computer would have said "unsafe" for this code). Antivirus vendors have the same problem: every new heuristic causes virus writers to change viruses to escape the heuristics, in a never-ending arms race. For the rootkit-VM, the advantage of innovation lies with the detector. By the way, this is the fallacy of the naive "my hypervisor has a rootkit-detector-detector" game.
- (I'm ignoring the far easier argument: the complexity of a rookit-detector-detector is large, both in hypervisor size and in runtime speed; hypervisor size limits the possible attack vectors for loading the rootkit and runtime speed makes timing attacks even easier.)
- From this, we conclude that the "guest" can trust its own code enough. Not "nobody can see me" trust, but "result is correct" trust. That is, the "guest" only has to detect that it is within a rootkit, or equivalently, that the "guest" is running in an environment that is not expected (i.e. an environment that doesn't match real hardware).
- Now for the other side: the rootkit detector is really looking for hardware that doesn't act like the real hardware should. PCI-based memory scans and external time sources are just examples of the general category.
- To prevent hardware-functionality attacks, a hypervisor must either trap all inputs to hardware (i.e. virtualize all devices) or allow only inputs that cause outputs with known effects (i.e. pass through safe devices). The former is impossible because you won't know a priori what the hardware on the system does; the latter is impossible because the VM can't force arbitrary hardware to be safe. (At least, not without VT-d and an IO MMU, but that doesn't exist yet except as an unimplemented spec.)
- If you dispute the last point, I challenge you to come up with a way to virtualize arbitrary hardware devices. If you do, VMware, Xen, Microsoft, KVM, Parallels, and everybody else in the business would like to talk to you.
--
A witty [sig] proves nothing. --Voltaire
Re:Trying to have her cake and eat it too? by Jah-Wren+Ryel · 2007-03-04 22:47 · Score: 1

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 like you've just got an axe to grind and not any sort of coherent argument.

--
When information is power, privacy is freedom.
Re:Trying to have her cake and eat it too? by Anonymous Coward · 2007-03-04 23:56 · Score: 0

A 128MB video card with own CPU and DMA/ bus mastering capability is also up for grabs, and virus scanners thankfully are not scanning your video card, or a full 4mb of shadow DVD flash memory.
Not news at all. There are even trojans that boot out of printer tcp/ip cards.

She's a girl by LS · 2007-03-04 05:09 · Score: 4, Funny

and reasonably cute, blah blah basement blah blah over 30 blah blah imaginary blah blah

--
There is a fine line between being a cultivated citizen and being someone else's crop. - A. J. Patrick Liszkie

Re:She's a girl by wamatt · 2007-03-04 10:53 · Score: 1

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

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... by sholden · 2007-03-04 05:20 · Score: 2, Insightful

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.

There's already one solution available by btarval · 2007-03-04 05:33 · Score: 4, Interesting

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

--
The best way to predict the future is to create it. - Peter Drucker.

Re:There's already one solution available by Anonymous Coward · 2007-03-04 06:43 · Score: 0

Believe it or not, I've met CPU designers who have never heard of JTAG.

You never met real cpu designers.
Re:There's already one solution available by Wanderer1 · 2007-03-04 08:34 · Score: 1

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
Re:There's already one solution available by btarval · 2007-03-04 09:24 · Score: 1

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. What I understand from talking to the people who make this box is that they have to do quite a bit of reverse engineering in order for it to fully work - and that's after being under a tight NDA and having access to Intel's internal docs.
Intel is one of the worst (if not THE worst) chip company to do business with. They just don't care about you unless you are buying lots and lots of CPUs. It's truly horrible trying to get any information out of them even when you're on good terms with them. So much so, that they drive people into using their competitors products.
If Intel would open up a little, and actually allow easier access to the JTAG command chain, yes, I'd love to do this. So would all of the companies which make JTAG ICEs. But I don't expect this to happen in this millinium.

--
The best way to predict the future is to create it. - Peter Drucker.
Re:There's already one solution available by speculatrix · 2007-03-04 11:10 · Score: 1

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 our mistake and used NEC's V25 and V35 x86 microcontrollers and got their emulators for well under GBP1000; they weren't as full featured but instead of four people competing to use two debug stations, they were able to buy or rent enough for each developer.
If I were still in embedded development, I'd put a couple of people onto the job of full-time tool evaluation before we picked a microcontroller to ensure the kit worked reliably AND we had prices negotiated before adopting any one CPU.
Re:There's already one solution available by Anonymous Coward · 2007-03-04 11:42 · Score: 0

I would imagine that having access to the JTAG chain is not enough. You will have to know what the sequence of bits coming out of it are mapped to. But to even figure that out, you would need the RTL source, which the chip company will not release to just anyone. That's why ICE companies exist -- they deal with the peculiarities of the scan chain because you can't without access to the source or really good help from the CPU designer.

You don't think there's just one register that contains ax, do you? Maybe up until 80486 it did (I think that was the last one that did not do OoO).

Not only that, but JTAG can't get everything; not every register is in the scan chain, and not every register contains something that you can figure out without the source.

JTAG won't solve the article's problem. Having attached hardware scan bits through JTAG could also be considered too risky for that 'legal' reason the researcher's presentation talks about. Heck, it'll probably make it worse -- now you REALLY have no idea if your *CPU* is compromised at all. I'm reminded of that cartoon image of a computer gleefully typing away at its own keyboard. Only this would be worse because you wouldn't be able to give any prediction of the behavior of the machine.

I think the solution here is to disable MTRR and IORR for machines that must be monitored using these devices that DMA from system memory. This should be done using a jumper or hardwiring some configuration pin of the chips so that the feature is disabled. Ideally a register that the PCI master can read from the NB can contain a status bit indicating whether or not the features have been disabled through that configuration pin. Either that or fix the architecture of MTRR/IORR so that you don't have this problem.
Re:There's already one solution available by btarval · 2007-03-04 13:33 · Score: 1

"Not only that, but JTAG can't get everything; not every register is in the scan chain, and not every register contains something that you can figure out without the source."
I completely disagree. What JTAG can, or can't, get is explicitly up to the CPU manufacturer. It's a fairly flexible architecture. I think you've forgotten the original purpose of JTAG.
And your suggestions still don't cover the issue of discrepancy between what's in the caches and what's in RAM. You'd have to come up with some new mechanism (and circuitry) to get that, whereas current JTAG implementations are usually all set to do this.
"Having attached hardware scan bits through JTAG could also be considered too risky for that 'legal' reason the researcher's presentation talks about."
Any approach can be considered too risky when it involves attached hardware. Honestly, if an attacker has physical access to your box, all bets are off.
Personally, I'd like to see the entire PCI architecture redesigned. This time, with what has been learned kept in mind (and which should've been obvious from the start).

--
The best way to predict the future is to create it. - Peter Drucker.

dude, Joanna is quite hot by Anonymous Coward · 2007-03-04 05:40 · Score: 0

seriously

That's still no guarantee... by AJWM · 2007-03-04 05:54 · Score: 1

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.

--
-- Alastair

Re:That's still no guarantee... by SpaceLifeForm · 2007-03-04 08:14 · Score: 1

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.

--
You are being MICROattacked, from various angles, in a SOFT manner.

FireWire access can also be redirected by Animats · 2007-03-04 05:54 · Score: 1

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 it should be straightforward to make a FireWire port return whatever contents of memory the attacker wants to display. Especially since, on PCs, that function isn't otherwise used for much.

In fact, for security, a PC shouldn't accept FireWire memory read and write packets at the hardware level. (Does Windows? I know that QNX does not, having written a FireWire driver for it, and I don't think Linux does, but I'm not sure.) There's nothing that talks to a PC that needs that feature. It's used mostly for talking to "device registers" in peripherals (where, typically, the "device register" is implemented as a switch statement in firmware.) For example, you turn on and set up a FireWire camera by sending packets that write to "device registers". But the images from the camera come back as FireWire data packets, processed by software. They are not "external DMA transfers." You can only read or write one 32-bit word per "memory access" packet anyway, so it's a very inefficient way to move data. All sizable FireWire data is sent in longer packets processed by software.

(FireWire is really a LAN, not a bus. FireWire controllers work a lot like Ethernet controllers, with buffer rings for input and output, although Ethernet uses collision detection and FireWire uses an arbitrarily-chosen master node to schedule the wire. It's not at all like the PCI bus.)

Re:FireWire access can also be redirected by Anonymous Coward · 2007-03-04 06:56 · Score: 0

Rumor has it that the answer to your question is no, Windows does not set the registers too protect from a firewire device owning the system. I haven't tried this myself, so I don't know for sure, but as of windows XP that's the word on the street.
Re:FireWire access can also be redirected by Beryllium+Sphere(tm) · 2007-03-04 09:53 · Score: 1

It was possible, dunno if it still is, to use a Firewire device for kernel debugging in FreeBSD.

Macs a few years ago didn't restrict Firewire access, and there was a demo of vandalizing the video display by plugging in an iPod.

Ref. Dornseif, CanSecWest 2005. His results about writing were
OS X: works
FreeBSD: works
Linux: works
Windows 2000: crashes
Windows XP: doesn't work

Except that Adam Boileau demonstrated write access to RAM under Windows from Firewire by having the device lie about its configuration.

This sort of thing is why security people sometimes act so devoid of hope.

Seems like some useful service being provided... by Monkius · 2007-03-04 05:59 · Score: 1

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.

--
Matt

MOD UP PARENT by Anonymous Coward · 2007-03-04 06:23 · Score: 0

Every DRM system relies on the user not knowing what is happening on their system. If you had full knowledge of what was going on on your system, you could bypass any DRM system. Some parties lobby for hardware making it even harder to know what is happening on your system in order to make DRM possible. Of course they are also going to make rootkits even easier to do. It is in everybodys best interest to have a more transparent system, where you actually have a possibility to see what is happening on your own hardware. Otherwise we'll probably end up with widespread rootkits going undetected for very long time. Even those advocating DRM is going to lose big time, when that happens.

Quite the opposite by Opportunist · 2007-03-04 06:29 · Score: 2, Insightful

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.

--
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.

security must be designed into hardware by hormiga · 2007-03-04 06:29 · Score: 1

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 if the total amount of memory is unknown? An attacker need merely relocate himself dynamically to avoid detection.

The two most common attempts at better security involve two approaches: additional hardware which requires special keys for access (such as is used in some DRM systems), and secondary or even tertiary computers to monitor the primary system. There are even systems with back-to-back PCI bridges, where the second PCI bridge on a completely separate computer audits the behaviour of the first PCI bridge. All software is considered "hostile" in systems which are serious about security.

Even the available security features often are not enabled or used, because of poor design. For example, some video decoding chips have read only register to store keys for DRM purposes, but many STBs don't use them because the designs are flawed, or because the use of the features incurs unacceptable manufacturing and deployment costs. Similarly, JTAG access often is not locked, because the manufacturers prefer the ability to field diagnosis easily, and assume that most attackers won't be able to figure out how to break into the unlocked systems. Even worse, these advanced features are not used because the most egregious holes are even easier to exploit, so why bother to harden the front door when the windows and back door remain open?

Unfortunately, most of the "secure" systems are lame, done without adequate design review. Much common hardware from cable boxes to military equipment is full of holes. The failures remain latent only because of NDAs, government security classification, and other factors impeding review.

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

Re:security must be designed into hardware by lgw · 2007-03-04 07:20 · Score: 1

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 volume is low. If the need for them became commonplace they wouldn't make the price of a server unreasonable.

As the price of servers becomes less about the hardware cost and more about the admin cost, the prospect of a seperate complete auditing system on the same board as the production system becomes practical.

--
Socialism: a lie told by totalitarians and believed by fools.
Re:security must be designed into hardware by Anonymous Coward · 2007-03-04 17:06 · Score: 0

Haven't you n00bs ever played "Core Wars?"

xkcd reference? by Bazman · 2007-03-04 06:48 · Score: 1

Are you talking about this:

http://www.xkcd.com/c174.html

Nah. by antdude · 2007-03-04 07:11 · Score: 0, Offtopic

I diasagree on the cute part. She doesn't look cute and that attractive to me even after doing a Google image search.

--
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).

Re:Nah. by Jugalator · 2007-03-04 07:18 · Score: 1

Lucky for her perhaps -- just imagine all geeks stalking her if she was both a skilled rootkit researcher *and* looked like Natalie Portman!

--
Beware: In C++, your friends can see your privates!
Re:Nah. by antdude · 2007-03-04 07:37 · Score: 1

Would that be the bald Natalie or the one with hair? [grin]

--
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
Re:Nah. by Anonymous Coward · 2007-03-04 17:36 · Score: 0

She looks pretty nice to me:
http://www.spiz.ae.krakow.pl/uploaded_images/11231 65482_64981000.jpg
http://common.ziffdavisinternet.com/util_get_image /13/0,1425,sz=1&i=135407,00.jpg
http://www.artsandartists.org/images/staff/joanna. jpg

Call me confused .... by HW_Hack · 2007-03-04 07:13 · Score: 1

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 parts of the operating system or install themselves as drivers or kernel modules.

The best and most reliable method for rootkit detection is to shut down the computer suspected of infection and check its storage by booting from an alternative media (e.g. rescue CD-ROM or USB flash drive). A non-running rootkit cannot hide its presence and most established antivirus programs will identify rootkits armed via standard OS calls (which are supposedly doctored by the rootkit) and lower level queries, which ought to remain reliable. If there is a difference the presence of a rootkit infection can be assumed. Rootkits attempt to protect themselves by monitoring running processes and suspending their activity until the scanning has finished.

So .... with disk space becoming trivial couldn't your OS make a copy of itself to a locked partition during OS install - these become master reference files. Then a second security CPU (Xscale etc.) is embedded on the MB with access to system memory (dual-port) ---- during idle periods the security CPU runs random OS calls on system memory and compares those to results of system call from the locked partition.

As I ejected from Intel R+D in '04 we were already doing early work on embeddng Xscale on MBs for other purposes ........ beats me I'm just a ex-hw-hack

--
Its not the years, its the mileage .....

Your Philosophies by not_hylas(+) · 2007-03-04 07:21 · Score: 1

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&mode=threaded

After reading this, if you don't have experience in these matters please refrain from commenting.
Rather, go read more of what Ms. Rutkowska has so expertly revealed:

http://invisiblethings.org/papers.html

"There are more things in heaven and earth , Haratio, than are dreamt of in your philosophies."

--
~hylas

Re:Your Philosophies by Teun · 2007-03-04 08:43 · Score: 1

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?

--
"The likes of Facebook and WhatsApp are free to those whose privacy is of zero value."
Re:Your Philosophies by Beryllium+Sphere(tm) · 2007-03-04 09:59 · Score: 1

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.
Re:Your Philosophies by not_hylas(+) · 2007-03-04 10:50 · Score: 1

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

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

Here, check this out, it's pretty fascinating stuff (PC-wise):

The quest for ring 0

http://www.securityfocus.com/columnists/402

--
~hylas
Re:Your Philosophies by Teun · 2007-03-04 11:50 · Score: 1

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!

--
"The likes of Facebook and WhatsApp are free to those whose privacy is of zero value."

JTAG for my honeypot by JohnnyOpcode · 2007-03-04 07:56 · Score: 0

Has anyone encountered a modern-day PC motherboard with a well identified JTAG port? Many of the high end servers have these readily available, but I have not found one recently on motherboards (clearly identified).

Heasman, ROM by Anonymous Coward · 2007-03-04 08:58 · Score: 0

Does anyone know link to John Heasman's BH presentation? I've recently worked on nVidia rootkit and from googling seems that John did the same. However, problem was that on modern VGA bioses only few kB or none space left. I found solution to this problem (obvious one), but it's not very stable and main Bios version dependant. So I'm very curious about that presentation.

It's a man baby! It's a man! by letchhausen · 2007-03-04 09:02 · Score: 1

http://www.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 techniques (Concepts for the Stealth Windows Rootkit, first paper by Joanna Rutkowska) that were very closely related to earlier contributions by Jan and extended some of his ideas, referencing previous work (e.g., Detecting Windows Server Compromises with Patchfinder 2).

--
Hey, you think your house is cool?

Re:It's a man baby! It's a man! by Anonymous Coward · 2007-03-04 10:01 · Score: 0

Stop bizzaroing my mind.

Please mod conspiratorial parent up.
Re:It's a man baby! It's a man! by Anonymous Coward · 2007-03-05 03:57 · Score: 0

Maybe not. Transgendered people usually have a "trail" under their old names unless they transition very young. I know that I do. If you transition and stay working in your field there will always be people that know about your past or will find out about it.

Probably the most insulting thing to a TG person is for people to say that they are now phony. If she is TG, she was always a woman, but forced to live a lie.

Not "anyone" by Beryllium+Sphere(tm) · 2007-03-04 09:20 · Score: 1

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

It's broken in Linux, too. Clear security hole. by Animats · 2007-03-04 10:47 · Score: 2, Informative

This sort of thing is why security people sometimes act so devoid of hope.

Yes. The ability to directly access memory space by address from a FireWire connection is a totally inappropriate "feature" on a machine with an operating system. It's intended for embedded system debugging and remote device control. The FireWire interface hardware has it off by default. Windows has to explicitly turn it on. Despite the fact that, as far as I know, that feature is never used for anything legitimate.

And yes, it's broken in Linux. I just looked at the hardware spec (see figure 5-28) and the source code for "fw-ohci.c", and there it is:

reg_write(ohci, OHCI1394_PhyUpperBound, 0x00010000);

That line says "external FireWire packets can access any physical address below (0x10000 << 16)", or, in other words, the first 4GB of memory. Apparently this security hole hasn't been upgraded for 64 bits yet, although the hardware supports a 48-bit memory address. Note the lack of any comments in that area. That one bit opens up a huge security hole, one known for three years, and nobody has fixed it.

I'd suggest changing that value to 0, which turns this "feature" off.

I love articles like this, they crush wannabes by Gothmolly · 2007-03-04 15:04 · Score: 1

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.

--
I want to delete my account but Slashdot doesn't allow it.

Deja vu... by advocate_one · 2007-03-04 20:17 · Score: 1

[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éjà vu is usually a glitch in the Matrix. It happens when they change something.

--
Donald 'Duck' Dunn: We had a band powerful enough to turn goat piss into gasoline.

O.K your confused... by Anonymous Coward · 2007-03-04 23:26 · Score: 0

I'm going to assume that your vaguely sane and not suggesting the second CPU run system calls on a hard drive image but that it should actually be running the second copy of the OS.
I'm also going to assume that your proposing some sort of private bus over which the second system can make remote system calls although even that seems like it could introduce all kinds of new security holes.
Finally I'll assume that by duel-port memory access you mean that there are two separate paths to access memory, the first presumably the standard method employed by the primary CPU and the second a more reliable method.

So the last part of that seems like pretty much what the author is suggesting anyway... Just have two paths to access memory, then you just compare them and any unexpected differences would be a root kit.

I don't think random system calls would be a reliable detector... Maybe some system calls you expect to be different but that may not help with previously unknown root kits, if it's messing with memory like this it may not even need to alter system calls to stay hidden.
Additionally system calls may yield different results just because the two copies of the OS your comparing are in different states.

Also what part of your suggestion actually required the second CPU to access the main memory anyway?

Re:she shatters THREE myths really ... by Anonymous Coward · 2007-03-05 02:45 · Score: 0

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

3) Ears aren't meant to be hidden underneath hair.

reality check by IT+073571 · 2007-03-05 05:16 · Score: 1

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

Who need Rootkits by Anonymous Coward · 2007-03-05 07:56 · Score: 0

Who needs rootkits when we have Vista?

Slashdot Mirror

Hacker Defeats Hardware-based Rootkit Detection

126 comments