New Approach To Malware Modifies Linux Kernel

Hugh Pickens writes "Professor Avishai Wool has unveiled a program to watch for malware on servers with a modification to the Linux kernel. 'We modified the kernel in the system's operating system so that it monitors and tracks the behavior of the programs installed on it,' says Wool. Essentially, Wool says, his software team has built a model that predicts how software running on a server should work (pdf). If the kernel senses abnormal activity, it stops the program from working before malicious actions occur. 'When we see a deviation, we know for sure there's something bad going on,' Wool explains. Wool cites problems with costly anti-virus protection. 'Our methods are much more efficient and don't chew up the computer's resources.'"

Comments

premise to shutdown

[thatchman1]

Is this not the very premise that caused the Amazon cloud shutdown? A failure to communicate back proper activity illogically deduced that there was an improper activity?

selinux

[perlchild]

Great, sounds exactly like what people have been doing with selinux and capabilities. But selinux acknowledges we don't always do the same things with our computers as the next guy... Will this approach be as flexible?

I don't want to boohoo his research, it's probably fine, but the article summary just gets my goat. Malware is a lot more complicated than most anti-malware software authors make them sound, and false positives are the biggest/most complicated problem they have to deal with, especially in automated systems that block like this...

Re:selinux

[icsx]

If you can detect and isolate a program that doesnt do what it is supposed to be doing and attracts attention with unusual behaviour, like scanning certain ports or trying to send packets etc, then it may be something that you dont have to have on your server. Most security programs today arent looking up what software does. They look what ports are used, what traffic is routed and so on.

These malware programs today try to hide themselves into deep that you just couldnt find them if you dont know what you are looking for. This system here as i understand it tries to identify what are the normal parameters for a certain program to work. If the program doesnt do or behave like a normal software, then there must be something wrong with it and alarms go off, lights are blinking and all hell brokes lose.

Oh crap, red lights and i hear noises. Oh it's only the cops.

Re:selinux

[Anonymous Coward]

Essentially when you build it it'll make a map of what system calls can be made and in what sequence. If an application makes a system call it never calls or never can call in that order because it's been hijacked then this thing will stop it.

Or the application has been legitimately updated to do new things...

Re:Heuristic scanning v2.0?

[ThinkingInBinary]

this sounds like the heuristic scanning features that has been in Norton Antivirus and other A/V utilities for almost a decade now, where it searches for out of the norm items and reports or blocks them, such as a program deciding to write to the MBR, or a program using raw disk I/O to write to the hard disk.

Wow, those "heuristics" sound like a simple blacklist of "virus-like" activities.

No, what this does is cleverer. It creates (at compile time) an automaton representing the system call activity of the program, and if the program tries to make a syscall that does not have a matching edge in the automaton, it kills it. Basically, if there is not a code path that should lead to execution of a certain syscall, the program gets killed.

How it works

[Animats]

From the papter: "The resulting model is an automaton that represents the legitimate order of system calls that an application may issue. This automaton is then enforced by Korset's monitoring agent, which is built into the Linux kernel, by simulating every emitted system call."

This is not likely to work for scriptable applications (Apache, Java-based servers, etc.) The order of calls is determined by the script, not the underlying executable.

I'm definitely not an expert...

[fuzzyfuzzyfungus]

But this looks a lot like SElinux or AppArmor, except that the application profiles are constructed by static analysis of program code, rather than by hand, or by observing the app during a "training" period. The linked paper indicates that it is still in a rather rough state; but it looks quite promising.

Will fork bomb do work still?

[DpakoH]

I'll try to run famous :(){ :|:& };: shell example

I might give it a spin

[FudRucker]

When & if Linus Torvalds (or whoever the benevolent dictator of the kernel is nowadays) includes it in to the main kernel source tree...

Sounds like a good idea to me, I just want to see what the Linux kernel pros think of it...

Re:I might give it a spin

[ZachPruckowski]

It seems too specialized to go in the main kernel tree. Additionally, I can only imagine that it hurts performance more than some users would like. Additionally, it requires a fundamental change to the system of distributing linux apps. Maybe a distro will include it in their kernel and modify their repository to include pre-built maps, but I can't see it becoming fully mainstream.

It's kind of like Vista

[TheRealSlimShady]

Sounds from the summary at least (hey, it's slashdot, I haven't read the article) that it's similar in some ways to the service profiling in Vista. The service profiling means that the dev looked at what the service needed to do to be able to run and gave it only those permissions, restricting the damage it could do if it were compromised. This seems to extend that to give the kernel the intelligence to baseline the services itself, and then restrict activity when the baseline activity changes.

Re:It's kind of like Vista

[Delkster]

These guys make a point of avoiding the labour involved in manually building the profile. (FWIW, I don't know about anything service profiling in Vista -- in fact, I had never heard about it -- but your description also sounds somewhat reminiscent of AppArmor.)

Re:Completely incorrect basic assumptions

[QuoteMstr]

You're right. You can't exactly predict the behavior of a program without running it.

But that's not what this package is trying to do. Instead, it's trying to rule out large swaths of the behavior space of a program based on static analysis. Of course there will be false negatives -- i.e., malicious actions that remain undetected. But I don't really see how false positives would be a danger, modulo bugs in the static analyzer.

I imagine this package would be nearly useless for something like firefox, which does many varied tasks. But for programs like exim, or bind, or vsftp -- which do one task over and over again -- the degree of protection should be pretty good because there's a lot these programs don't do.

Tron

[nsayer]

Somehow, this technique reminds me of the (obviously rather simplistic) description of the functionality of the Tron program from the movie of the same name. From the script:

                    DILLINGER
  [...]
                                        What's the thing you're working on?

                                                                ALAN
                                        It's called Tron. It's a security
                                        program itself, actually. Monitors
                                        all the contacts between our system
                                        and other systems... If it finds
                                        anything going on that's not scheduled,
                                        it shuts it down. I sent you a memo
                                        on it.

                                                              DILLINGER
                                        Mmm. Part of the Master Control Program?

                                                              ALAN
                                        No, it'll run independently.
                                        It can watchdog the MCP as well.