How To Guarantee Malware Detection 410
itwbennett writes "Dr. Markus Jakobsson, Principal Scientist at PARC, explains how it is possible to guarantee the detection of malware, including zero-day attacks and rootkits and even malware that infected a device before the detection program was installed. The solution comes down to this, says Jakobsson: 'Any program — good or bad — that wants to be active in RAM has no choice but to take up some space in RAM. At least one byte.'"
Re:At least one byte (Score:1, Interesting)
It doesn't need to do even that.
They forgot that malware code can reside inside another process and it's memory space, in which case comparing and writing random bytes to free RAM is a moot point.
Theory and hand-waving (Score:4, Interesting)
<sarcasm>Punting the problem to an "external verifier" is pretty neat. I wish I could do that with my next hard problem.</sarcasm>
That whole bit about swapping, though.... If I write malware and hide it somewhere in execution space, do I really care if it gets swapped out? So the code that steals keystrokes or sniffs for credit card numbers doesn't get executed for short while. Big deal. At some point it will get loaded again (if written properly, that is).
Or am I missing something obvious?
register (Score:5, Interesting)
Re:Refuting the imaginary article in your head (Score:2, Interesting)
Still haven't read the article, eh? The technique is to swap everything out except the scanner, then write random bits to the entire memory space, then hash the memory. I could explain it all in greater detail, but, you know, there's this article, already there. Please do try to constrain your criticisms to things that actually apply to the article that was written, you know, the one we can all read. Refuting the imaginary article in your head does nothing for the rest of us.
I'm glad you guys have managed to work out what the article says.
I have one glaring problem with this system, and all other systems designed to detect running malware: no focus on prevention. I'm glad we have a new tool to detect malware executing on a machine that's already compromised, but that's what all of the new tools I read about intend to do. I don't see much progress being made in terms of the design decisions and best practices that prevent (Windows) machines from getting compromised in the first place.
As good as this technique may or may not be, it's not security. It's damage control. It has this in common with almost every malware "solution" that is ever posted to Slashdot. Where are the researchers who want to prevent intrusion in the first place instead of having lots of clever techniques for identifying/limiting its damage after it happens?
Re:Some amazingly bad assumptions (Score:2, Interesting)
who's to say that the kernel space is guaranteed free of malware itself?
Of course. It's obvious to say that if we can guarantee the kernel, we can reliably use it to scan for malware. What this completely misses, of course, is that the kernel itself can be compromised and there is zero way to guarantee it, after the fact, without a cold boot and poking around in all the stored memory contents of the system.
This fact continually fails to deter the snake-oil salesmen from peddling on-line virus scanning as an infallible cure.
Re:Refuting the imaginary article in your head (Score:3, Interesting)
If you have that much control over what's installed on the system then you might as well just take a snapshot of the system running in a safe state, place any data which needs to change on some kind of hardened remote server(like a seperate database) and just periodically re-image the whole machine from ROM.
Probably be more effective than this proposed system as well.
Redeeculous idea. (Score:5, Interesting)
I tried reading TFA a few times. First time, utter confusion. Second, third times, no better. I can't make any sense out of these points:
>1) There are absolutely only three things malware can do when you scan for it. One: be active in RAM, maybe trying to interfere with the detection algorithm. Two: not be active in RAM, but store itself in secondary storage. It cannot interfere with the detection algorithm then, quite obviously. And option number three: erase itself.
Absolutely, not. There are many other things malware could be doing. Inactive in RAM, compressed and inactive in RAM, encoded as plausible-looking entries in the File Name Table or the Virtual Memory map.
>2) Any program -- good or bad -- that wants to be active in RAM has no choice but to take up some space in RAM. At least one byte, right?
No, it could be sleeping, existing only as an entry in the swapped-out process table. Or in unused space below a thread stack.
>Assume now that we have a detection algorithm that runs in kernel mode, and that swaps out everything in RAM. Everything except itself.
Whoah there fella. Everything? Are you going to turn off all timers and interrupt enables so their service routines don't get called?
Hard to do without mucking up all the device drivers. Are you going to swap out the kernel too, as malware is quite capable of infesting kernel space. And what about device drivers? They're constantly mucking with their internal tables and I/O buffers.
And if you turn off all device drivers, you lose, as there's nothing stopping malware from masquerading as a device driver. Many do.
>>But if we know how big RAM is, we know how much space should be free.
Whoa there again, big guy. There are plenty of machines with RAM at places not generally known to the OS, such as video RAM, graphics polygon RAM, network card RAM buffers, and kernel stacks.
>> Assume we write pseudo-random bits over all this supposedly free space. Again, a malware agent could refuse to be overwritten.
You don't need a checksum test to do this-- each page of virtual memory has R/W control bits.
And you're foiled here again, as there are plenty of system areas that are write-protected, such as pre code areas and the VM tables themselves.
>>Then, let us compute a keyed hash of the entire memory contents -- both our detection program and all the random bits. Here is what could happen: If there is no malware in RAM, the results will be the expected result. An external verifier checks this, and tells us that the scanned device is clean.
Nooo, that just tells you that either you overwrote the malware, so you'll never find it, or the malware during your two sweeps did not change any RAM contents. Quite possible as most malware just sits around most of the time.
>> Or there could be malware in RAM, and the checksum will be wrong.
Well, no, unless you disabled all interrupts and stopped all kernel tasks, there will still be system timers and interrupts and device drivers changing their state in RAM.
>> The external verifier would notice and conclude that the device must be infected.
Or some part of the system or some device driver is still running. Huge chance of false positives.
This essay seems to have been written by someone with only a glancing familiarity with hardware and system software.
Re:Refuting the imaginary article in your head (Score:3, Interesting)
Yes, and what happens when everything gets swapped back? There's the malware again.
If you assume it would be easier to find and delete the malware when it's not resident in memory anymore, then you could do that just fine on another computer and working directly with the hard drive. You would need to do that anyway, since your RAM is swapped out. AV's are already quite integrated in to the system, never can delete anything (so you would need to do it by hand) and in worst case scenario could do the deleting upon reboot. So, what's the point?
Re:At least one byte (Score:3, Interesting)
I'd rather just secure my systems, thanks.
How would you do that, then? There are so many clever rootkits these days, and no OS is "immune" (although SE Linux may be so if correctly configured, configuration is hard). Hardware-based rootkits (malware in the firmware of peripherals that attack an already kernel-mode driver process) are very dificult to defend against, you can only really hope they get enough bad press before they get you.
The only way to "just secure your system" against increasingly clever attackers is to have a safe partition, one that is simply not writable from the production OS, that can scan the production OS for rootkits. Virtualization by itself isn't enough - we're already seeing the first jailbreak exploits - you need something "below" any OS to enforce the paritioning.
Re:Refuting the imaginary article in your head (Score:3, Interesting)
It's getting kind of boring explaining the article over and over again.
You mean the part they say they don't even need to start with a clean machine?
Re:At least one byte (Score:3, Interesting)
You can't detect known malware that way if it virtualizes the computer, because you will only scan for the memory the malware is willing to show you.
Ah, there's where the bit about "knowing how much RAM you have" matters.
The virus has three choices:
1) Be overwritten, thus being eliminated (and showing you all of the RAM in your system.)
2) Swap part of what you're writing to disk.
3) Present less RAM than you actually have.
If you know how much RAM you have, you can detect choice 3.
If you can detect latency between secondary storage and RAM, you can dectect choid 2.
If the virus doesn't mind disappearing for the rest of the computer's runtime, you can mitigate damage via choice 1.
Now you may not know what kind of malware is on your computer, but you know that something is there.