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

At least one byte

[BadAnalogyGuy]

While it might be true that any application will take up at least a byte of memory, there is no reason malware couldn't masquerade as another binary down to the exact number of bytes.

Hell, Windows is a whole slew of malware that masquerades as the whole OS.

Re:At least one byte

[OeLeWaPpErKe]

There are several weaknesses. Note how he says something about an external verifier, which is delay-sensitive. Note how for the first 2 steps he keeps repeating "malware may of course interfere but this doesn't matter because", and then he stops considering malware interference. That's because at those points, malware interference would be fatal.

Of course, malware could simply take over the entire procedure, computing the keyed hash itself (a process which can run in a lot less memory : it doesn't actually index memory, it just generates the pseudo-random bytes directly, then it sends back the correct keyed has).

Calculating the entire hash in the processor cache will let this method outperform the checksummer by a large margin, meaning it can send the data back after any chosen interval.

(and before you say "keyed", obviously the encryptor needs to know the key)

In practice you'll also find that large amounts of ram space cannot be swapped out : BIOS, some bits of the operating system, ... There's even memory locations that aren't in the memory map, but are nevertheless backed by physical ram (in a pci card or ...), and thus won't be included in any (sane) scan. Surely one can find some place where a virus could squeeze in.

Re:At least one byte

[c 0xFF]

As near as I can tell, the article makes a HUGE assumption: the malware is actively trying to hide itself. This is not an unreasonable assumption, but it makes everything more clear. Let's go through his steps:

1) The algorithm swaps out memory.
2) The malware decides to stay active in RAM.
3) Random bits are written to memory.
4) Optional: The malware masks its presence by falsifying the memory reads.
5) A bad hash or delay reveals the presence of something trying to stay hidden.

For the special case that malware hides itself in memory that won't get swapped out, this might work. But a special case is a far cry from the claims in the article:

We can guarantee detection of malware. And that includes zero-day attacks and rootkits. We can even guarantee that we will detect malware that infected a device before we installed our detection program.

What if the malware is fine with being swapped out to disk? This algorithm detects nothing, of course, and the malware continues as normal, and can only be detected by traditional means.

I find the analogy from the paper quite revealing:

An analogy of our approach is that of an air marshal that at given time intervals demands of all travelers to take a step out on the wing, reporting to an authority on the ground who was there, providing them evidence that the plane is empty -- and first then, allows everybody to come in again. Our solution works even if the air marshal was delivered to the plane after takeoff.

So ... what happens if the marshal is clubbed over the head when entering the plane? What if the traveler carrying the bomb just leaves with everybody else? What if, what if ...

There's just too many holes to count.

Theory and Reality

[ircmaxell]

In theory, theory and reality are equivalent. In reality, they are quite different...

Seriously, how could this possibly work for ALL (including undocumented, and hereto unknown) threats? And if it does it by reading straight from RAM (through the kernel), wouldn't a rootkit be able to trivially defeat that?

Still a needle

[dmgxmichael]

A needle in a haystack wants roughly the same amount of space as a straw - doesn't make it any easier to find (indeed, that's part of the reason it's so hard to find).

Even if this technique has merits, it does nothing to correct the primary reason for computer infection - stupid users.

Re:Still a needle

[mooingyak]

I think god has a monopoly on causing death in that department. (Take that last sentence however you will. Just remember: however you take it is how I meant it.)

You're sleeping with your mother? Gross.

Which one is the detector?

[mangu]

How about a malware that masquerades as this detector and reports the RAM checksum is OK?

Re:Which one is the detector?

[evanbd]

Detecting a malware detector is just as hard as detecting malware. In general, detecting software of a specific type is halting-equivalent. In practice, the goal is to take shortcuts so that your adversary has a halting-equivalent problem and you don't. At present, the malware authors are winning. If we could force them to detect the malware detectors, that would be a huge advance.

My skepticism about this is the obvious one: what if the malware just lets itself get swapped out, and relies on stealth to survive the process?

"Guarantee"

[Reason58]

You can't guarantee anything in security. Especially when a human is involved.

Some amazingly bad assumptions

[nahdude812]

Sure, malware has to occupy memory. That doesn't mean it has to be its own memory. Buffer overflows are all about corrupting another application's memory space.

His basic argument is that if you want to scan RAM, the kernel can halt all processing except its RAM scanner, and have a go at the RAM safely. If it's particularly insidious malware, it'll try to hide itself in various ways, one of which would be to masquerade the portion of RAM it was using with something legitimate looking (maybe erase that portion of memory). But you know it did this because you can see that memory which was supposed to be free is no longer free. Except the hardware has no concept of free or occupied memory. It just has memory, and the OS keeps track of what's free and not. The OS - the same space where malware is running.

OR, the malware could simply not do this, then its behavior is no different from any legitimate program. So how do you detect it now? You still need definitions that say, "When running in memory, this virus looks like X," then look through memory for that pattern.

Besides, who's to say that the kernel space is guaranteed free of malware itself? Even if you would have successfully identified the threat in RAM, you have no guarantee that the malware hasn't corrupted the identification routine.

It's like someone came along and said, "Hey, you guys are looking for malware wrong. You have to look for it! And I mean really look for it!"

Re:Refuting the imaginary article in your head

[spun]

Protection from malware should function like the immune system, with many lines of defense and many avenues of detection and counter attack. Prevention will never be perfect by itself.

Re:Refuting the imaginary article in your head

[Romancer]

I'm not an expert and not sure if I'm missing something obvious here but what is confusing me is the part about "swap everything out except the scanner". Wouldn't you then just be moving the malware too? Into a protected space that you then have to scan and know what to look for?

If it's a zero day infection then you don't know what to look for and you swapped it out of memory for nothing really. I do get that if it tries to protect itself it will look suspicious but what if it looks like a normal program? A service or scheduled task that could be normal. What if it takes on the guise of an adobe update program in size/hash and function until it is time do act? Say a slight change to your systems dns entries. Then goes dormant again.

This may not be possible but I haven't seen why not and it leaves a pretty big hole for zero day infections that this method claims to be able to catch 100%.

Re:Refuting the imaginary article in your head

[HungryHobo]

After reading TFA I'm still not seeing how this is supposed to detect unknown malware.
As far as I can see it would decide that a new install of any kind was a virus.

Sure if you know every program which is supposed to be installed and none of them do wierd things in memory(a big if) then you might be able to spot when some kind of change has been made but if you can do that then you have a situation where you might as well just re-image the machine from ROM every now and then.

I don't see any amazing new ideas in TFA

Re:Refuting the imaginary article in your head

[TheLink]

> have to scan and know what to look for?

If Dr. Markus Jakobsson has solved that, it is strange he hasn't also announced that he has solved the halting problem ;).

Figuring out whether a bunch of bits is or isn't malware is going to be as hard (or harder[1]) to figure out whether a program given a particular input will halt or not.

[1] Especially when that bunch of bits might later on download a new bunch of bits. Yes I know in theory it is impossible to solve the halting problem (no general solution), but in practice some special cases can be solved.

In contrast it's harder to solve the malware problem when you assume they can fetch new instructions and data, and from an active hostile party.

Sandboxing is the way to go. Sandboxing is analogous to avoiding the halting problem by having a time limit on the program.

No need to figure out whether the program is malware or not. Just make sure it can't do what you don't want it to do. Let the OS sandbox it.

Re:Refuting the imaginary article in your head

[nabsltd]

Suffice it to say, you haven't understood it yet.

I think these people have all understood the article quite well, and are pointing out real flaws with this scanning method.

The #1 flaw is the assumption that an exact byte count of what is running can be known if malware is also running on the system.

If malware is actively running, then if scanning code calls any outside functions, the results must be considered tainted. Since there is no way for code that does not query the OS to even guess about what else is loaded in RAM, sufficiently intelligent malware will be able to hide itself from any scan. Hell, you can't even determine how much RAM is in a computer running in x86 protected mode without calling some OS or BIOS function, either of which can be hooked by the malware.

One of the other assumptions is that the time it takes to compute a hash of RAM on a particular machine can be known with enough precision to detect that it is being "delayed" by malware.

Last, there is one piece of code that can never be swapped out to disk, and will likely show up as malware as it refuses to be overwritten: the code that swaps and restores pages to/from disk.

Re:Interesting point

[amRadioHed]

I have a hard time believing a technique that starts with "swap out everything in RAM" could ever be used for real-time detection.