Slashdot Mirror
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.'"
It's stopped me from running Vista in a VM...
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?
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...
They recently unveiled a unique new program called the "Korset" to stop malware on Linux...and once it reaches its full potential it could put anti-virus software companies out of business.
Doesn't our economy have enough problems? Do we really need to put Linux anti-virus vendors out of business? Next we'll probably drive the ice vendors in Alaska to bankruptcy!
I'm a big tall mofo.
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.
ttuttle is a rankmaniac
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.
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.
OK, what this is doing is watching for code injection attacks (buffer overflows, stack smashing, etcetera) by building a model of how each specific application is going to operate, and blocking system calls that the model of the application would never make. It seems like an interesting approach, though it may not be as useful on Windows where there's not such a formal distinction between system calls and other kinds of calls.
It won't do anything about interpreter code injection (eg, SQL injection or shell code injection) or script privilege escalation attacks (eg, ActiveX and other "cross zone" attacks in Internet Explorer), or attacks that involve complete executable code drops.
Still, this is useful and not nearly as dodgy as the article made it sound.
....I thought that was the philosophy behind AppArmor (http://en.opensuse.org/Apparmor).
It's been deployed in SuSE products for years.
Apparmor seems to be a relatively sophisticated least-privilege system, i.e. the idea that if a BIND DNS server should never need to (for example) modify the routing table, then it also should not be able to modify the routing table. That way, if an attacker compromises said DNS server, he won't be able to do very much with it that isn't directly related to serving DNS requests (this is why I would personally refer to such a system as damage control, useful for containing/limiting an attacker who has already compromised something). The system discussed in the article is different in that it seems to be less concerned with what specific tasks a program should or should not be doing and more concerned with whether the code that is executed and the way that it is executed is what you would expect from the program's source. That way, if someone exploits i.e. a buffer overflow and inserts their own shellcode, it would deviate from the pattern that you would have expected from the exploited program and this deviation would be detected.
Both can be compared to systems like PaX (kernel) and SSP (userspace) which are intended to make sure that an attacker will fail to exploit an existing vulnerability, such as an unpatched buffer overflow, in the first place.
It is a miracle that curiosity survives formal education. - Einstein
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.
It creates (at compile time) an automaton representing the system call activity of the program
At compile time of the program? So in addition to a modified kernel you need a modified gcc and to compile everything from source or have a specialised distro? It doesn't surprise me that the summary should be lacking such details, but it would be nice if for once it gave a decent overview.
I agree that this was a poor summary but instead of complaining about the summary you could always do something crazy like read the article.
It is a miracle that curiosity survives formal education. - Einstein
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.
I wonder if a fix for the buffer overflow (besides languages that make it harder) would be to separate the stacks used for local variables and return addresses.
The problem is that when a call is made to a function the compiler pushes the return address onto the stack. Then the function allocates space for its own variables on top of the same stack. If one of those variables overflows it can hit the return address. That essentially is a mixing of code and data. If you had two stacks then the processor could trigger an exception if anything writes to one of them except via a call or return. You could probably accomplish this via changes to the compiler without a processor change - the processor will always use the regular stack but a compiler could be designed to maintain a separate stack for local variables. You wouldn't have that read-only protection on the regular stack, but the two would be in different segments making an overflow impossible.
Other tricks that are used are things like canarys - values written onto the stack and then checked before a return - if there was an overflow the canary would not be intact. GCC has an option to do this which works most of the time.
How does this thing deal with plug-in/add-on based systems like Firefox or Eclipse, where new capabilities get added to the executable through dlls (or java classes, I guess, in the case of Eclipse? - Although, with regards to Java, I wonder if this system would work at all, since I think the kernel never exactly 'sees' Java programs or classes as executables, but only the JRE, which already has all the system calls built into it?)
It's about servers here, I personally think one should really think thrice before installing plug-ins and add-ons on a server, and rather go browsing on a desktop machine. Regarding Java, I can see your point.
All those moments will be lost in time, like tears in rain. Time to die.