How To Guarantee Malware Detection

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

Comments

In case anybody was wondering...

[fuzzyfuzzyfungus]

He is indeed selling something...

Re:At least one byte

[palegray.net]

I don't normally quote huge chunks of articles, but I'm making an exception on grounds that I don't believe you RTFA before replying:

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.

Malware detection is Bogus.

[bmo]

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

[spun]

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:Refuting the imaginary article in your head

[clone53421]

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 uses exactly the same method, so it’s not like this guy came up with anything novel. In fact, RootkitRevealer even has the disclaimer:

note: RootkitRevealer is not intended to detect rootkits like Fu that don't attempt to hide their files or registry keys

It only finds things that are trying to hide. If they aren’t trying to hide, you have to scan them conventionally.