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.'"
In case anybody was wondering... (Score:5, Informative)
Re:At least one byte (Score:5, Informative)
Assume now that we have a detection algorithm that runs in kernel mode, and that swaps out everything in RAM. Everything except itself. Well, malware may interfere, of course, as it often does, and remain in RAM. But if we know how big RAM is, we know how much space should be free. Assume we write pseudo-random bits over all this supposedly free space. Again, a malware agent could refuse to be overwritten. It could store those random bits somewhere else instead... like in secondary storage.
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. Or there could be malware in RAM, and the checksum will be wrong. The external verifier would notice and conclude that the device must be infected. Or malware could divert the read requests directed at the place it is stored to the place in secondary storage where it stored the random bits meant for the space it occupies. That would result in the right checksum... but a delay. This delay would be detected by the external verifier, which would conclude that the device is infected.
Why a delay, you ask? Because secondary storage is slower than RAM. Especially if the order of the reads and writes are done in a manner that intentionally causes huge delays if diverted to flash, hard drives, etc.
There's more details in RTFA.
Does it have to be in RAM? (Score:3, Informative)
It could be in ROM.
It could be in processor cache.
It could be in the video card's memory.
Could it be in pipelined instructions waiting to be executed?
Malware detection is Bogus. (Score:5, Informative)
How about we change things in Windows so it actually prevents infection in the first place?
1. Educate users. Microsoft does a piss-poor job of this.
2. STOP DEPENDING ON 3 MAGIC LETTERS TO DETERMINE IF SOMETHING IS CODE OR DATA. COME ON, SERIOUSLY. THIS SHOULD HAVE DIED WITH CP/M.
3. Kill ActiveX - I know of no legitimate website besides Microsoft.com that requires ActiveX.
4. If a file comes in from the outside world - STRIP ITS PERMISSION TO EXECUTE. MAKE THE USER UNPACK IT FROM AN ARCHIVE OR SET ITS PERMISSION.
Really. Seriously.
No, the above won't cover every situation, but it's a pretty good start.
--
BMO
Refuting the imaginary article in your head (Score:5, Informative)
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.
Re:At least one byte (Score:3, Informative)
He pushes the hard work off onto an "external verifier" without making it clear how that would itself remain rootkit free.
If you have a guaranteed-safe external verifier, malware detection and removal isn't rocket science. Oddly, we have the technololgy in place to create a safe verifier: Trusted Coomputing. All we really need to solve the malware problem for good is something like Trusted Computing that we actually trust! An open standard, untainted by DRM, the provides hardware-level cryptographic isolation between the running system and the verifier.
I'd rather just secure my systems, thanks.
Re:At least one byte (Score:3, Informative)
You've been modded funny, but this is exactly what this "article" is all about.
If there is no malware in RAM, the results will be the expected result. [...] Or there could be malware in RAM, and the checksum will be wrong. [...] Or malware could divert the read requests [...] . That would result in the right checksum... but a delay.
Or, there could be malware in RAM, not diverting read requests, and the checksum will be the expected result, and without a delay.
The only problem with Markus Jakobsson grand theory is that all malware are of that last kind.
Well, all malware since the memory protection era. I suppose his "product" could work for DOSes (but there is no multitasking there) Windows 3, MacOS9, AmigaOS and some embedded OSes.
And if the malware does virtualization, he is located in a memory area that his product won't be able to scan anyway.
So, simply put, it is a scam.
Re:Refuting the imaginary article in your head (Score:3, Informative)
If the malware let's itself get swapped out, then it can't hide it's memory footprint. Assuming we have started from a known clean machine, it is then trivial to figure out what the memory footprint should be. If it is larger than it should be, there is swapped out malware.
The point is, the malware will be detected whatever it chooses to do.
Re:Refuting the imaginary article in your head (Score:2, Informative)
Plenty of empty space in the code segments? How so? There are not 'empty blocks' that malware can put itself into, it will either need to delete things (and break things in the program) or enlarge the program.
And with this comment we can conclude you don't know how PE files are mapped in to memory in Windows.
There's plenty of unused space between functions for example, usually INT3 opcodes which never get run as they're outside the program execution path. PE code sections usually also contain a lot of zero-byte 00 memory mapped, which again isn't in use, but is still allocated. Read more here [codeproject.com], it's also used when making cheats to games. And that's only way to inject your code in to existing program, and doesn't change it's memory allocation at all.
Re:Refuting the imaginary article in your head (Score:3, Informative)
The article never mentioned scanning for signatures
Read the damn article. I already quoted the part in question:
I.e., scan for its signature. That is how conventional antivirus works, and it is how his idea falls back to working if it doesn’t detect anything that’s trying to hide. So if it doesn’t detect anything trying to hide, it has to scan for it conventionally.
This is just an elaborate scheme to ensure that the RAM isn’t infected. Maybe I need to explain.
A known clean system is used for scanning other systems because you know its RAM isn’t infected. The infected system can’t reliably be used to scan itself, because if has a rootkit, an active virus could be residing in RAM, either feeding your scanner false results or simply hiding there until the scan completes.
So, his idea is this:
Flush everything out of RAM, and fill it with garbage. The RAM *should* now be clean. Generate a checksum of this “clean” RAM.
Read the entire contents of the RAM again, generating a second checksum. This second checksum should match the first one.
If the checksums do not match, you wrote a value and read something different which means one of two things: Bad RAM, or a virus is hiding itself.
If the checksums match but weird timing anomalies were detected, a virus is hiding itself.
If the checksums match and no weird timing anomalies were detected, the RAM is now clean.
If the RAM is clean, you can then scan the secondary storage just as if you were using a clean system to do the scan, with the same reliability in your results.
However you would be subject to exactly the same limitations as you normally are in using a clean system to scan the secondary storage of an infected system: you have to use your signature database to detect viruses in the bytes on the disk.
Re:Refuting the imaginary article in your head (Score:5, Informative)
But it does seem to be foolproof if you start from a known clean machine.
That’s the whole point of his system: to scan from a machine that isn’t known to be clean.
The standard way to scan from a “known clean machine” is one of the following:
1) Use a known-clean boot CD. This ensures that the system RAM is clean. Once booted into the clean system, scan the possibly-infected secondary storage devices.
2) Use a separate known-clean computer. Its system RAM is clean. Attach the possibly-infected secondary storage devices from the first computer to the known-clean computer and scan them.
The 3rd way, which is not foolproof, is to attempt to avoid a boot CD or second computer by scanning the system RAM. Once the system RAM is known to be clean, you can proceed from there as in either 1 or 2 above. However, there is no foolproof way to ensure that the RAM of a running system is clean.
He proposed a “foolproof” way to ensure that the RAM of a system is clean (without shutting it down and booting it from a clean boot device). That’s the only thing that makes his suggestion useful.
However, it isn’t foolproof, and even you see that.
FWIW, RootkitRevealer [microsoft.com] uses exactly the same method, so it’s not like this guy came up with anything novel. In fact, RootkitRevealer even has the disclaimer:
It only finds things that are trying to hide. If they aren’t trying to hide, you have to scan them conventionally.