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...
I could be wrong but 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.
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.
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.
If I stop surfing pr0n will it detect that anomaly and halt my browser?
Will that crash my gnome desktop too?
Oh NO!
....I thought that was the philosophy behind AppArmor (http://en.opensuse.org/Apparmor).
It's been deployed in SuSE products for years.
Regards;
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.
I really don't think Linux has problems with malware. I think there is an other operating system having more trouble.
As far as I know virus scanners are used on servers mostly to check data that goes through it (example: email server); this data will however not be executed on the server.
So they are comparing the program behavior and match it with a stripped version of the source code or the object file. Great! But what are they protecting themselve against exactly? If some virus tampered with the content of a binary or a shared object, whouldn't be more effective to implement a (trivial) checksum-based integrity mechanism? And if a black hat managed to feed a shell code through a buffer overflow, how will this tool distinguish between a legitimate fwrite in the software logfile against an fwrite to some other part of the disk?
Also, their fwrite example already yields a highly complex graph. I would like to see what snprintf gives, not to speak about any real-life software (say, a Java Application Server). You can't automatically predict what path a program will follow by just looking at the code (otherwise you would solve the halting problem), so I guess a non-trival program would give something like "any system call will occur anytime".
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.
This was about 10+ years ago.
The guy was from the IBM Zurich Lab, and was pushing to get it implemented in the AIX kernel.
It's probably patented, but IBM does allow a bunch of patents to be used for Linux. Or maybe he lost his funding and his project died.
If I'm bored tonight, I'll try to google it out.
Schroedinger's Brexit: The UK is both in and out of the EU at the same time!
This is drivel - it assumes that a static binary analysis can be used to predict the dynamic behavior of a non-trivial application, with zero false positives. Unless of course, "benign intent" equates to "trivial". As a concrete counter-example, witness the (rather old) Solaris telnet bug wherein a specific input string coupled with a particular environment variable could result in the skipping of requiring a password. A simple model based upon the CFG would indicate that this is a legitimate possibility. My qualifications in this area: multiple product-grade binary translators and binary optimizers; former developer (Okena/Cisco) of a HIPS (Host Intrusion Prevention) system where we actually had to worry about this kind of problem.
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.
Not sure how this is better than what grsec and selinux does... They might be better suited to writing selinux modules than trying to reinvent the wheel here with what basically sounds like role based access control (RBAC) found in selinux
I'll try to run famous :(){ :|:& };:
shell example
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...
Politics is Treachery, Religion is Brainwashing
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.
You link to some random asshat (probably yourself) who links to a dead link. Nice try.
Sorry to blow your illusion, but that's just pathetic.
1. Linux has no viruses. Why would we need something like this?
Because Linux has vulnerabilities which can be (and have been in the past) used to take control of a system, and this is an attempt to fight that. All viruses are malware but not all malware are viruses.
2. If they're going to make a list of the behaviour of _every_ program, then that list would be HUGE, and take petabytes. A blacklist is a lot easier to make and keep up.
Unless I'm mistaken, this only needs a whitelist for the software installed on the system, so itwon't be that big and a whitelist is safer from a security point of view (uptime may be problematic, though, depending on the number of false positives).
3. This still wouldn't protect the weakest link: the user. If a virus asks the user :" Add IAmATrojan.exe to the whitelist ", a lot of people wouldn't do it. Heck, if you need even need a normal anti-virus, you're to stupid to work with computers.
Because this is primarily aimed at servers, and if someone with access to your server's whitelist is clueless enough to fall for that, you have *MUCH* bigger problems than a piece of malware, believe me.
No problem is insoluble in all conceivable circumstances.
Uhhh... no. A monolithic kernel still uses a user space/kernel space separation. They're monitoring stuff that's happening in the user space by what system calls those userland applications make (to the kernel).
If you considered a Linux kernel to be an entire operating system, you wouldn't be able to get a whole lot done on your computer. Think system libraries etc.
"Malware" is an unfortunate choice of words here.
While desktop Linux doesn't have the same malware problems as Windows, we still have problems with random server programs being compromised. This approach is actually, I think, more effective on the server than the desktop.
Firefox, say, has a much larger variety of behavior than bind. Firefox can do anything; bind does the same thing over and over and over.
Since Firefox does more varied stuff, this system call profiling approach would see more of its behavior as "normal". But because bind does the same thing over and over, almost every behavior is outside that norm, and would be caught.
If they modified Linux kernel, they modified then the Linux operating system and not just kernel, because Linux is monolith kernel and not microkernel...
So is it still Linux?
I think the difference is that CyberSecure's model is generated from usage, while this package's model is generated with static analysis.
I'm leery about usage-based profiling. What if there's a perfectly legitimate code path that the program just doesn't take while you're generating the profile? The program could be killed for something innocuous. I don't want that danger.
The nice thing about static analysis is that it's always correct!
while you are true that there are viruses for Linux and it is a smaller target, they are not JUST as vulnerable, the entire UNIX base (small programs that do little and user privilege restrictions) make UNIX systems much more secure from the start. Its also pretty much impossible to infect a well secured system (SELINUX + PAX + hardened toolchain) and this seams like an extra layer to provide automated selinux-like functionality.
IranAir Flight 655 never forget!
So what can you say about programs using glibc? What if innocent functions like fopen(3) call setuid(2)? What if they do it only after an update of glibc?
Post tenebras lux. Post fenestras tux.
WTF?
Why doesn't the gene pool have a life guard?
This actually isn't new. Systrace has been doing this for years. And it runs on more than just Linux.
Please correct me if I got my facts wrong.
you could always do something crazy like read the article.
Just stay by your computer and the men in white coats will be with you shortly.
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.
this isn't anything specifically to do with malware.
As far as I can see, this verifies that the binary currently running is the same binary that was compiled from a (trusted) source.
When you compile it, it knows (from the source) what the program will and won't do. If the program deviates from that, it dies (as it's been replaced by malware, presumably)
If I'm wrong, please correct me...
I have developed a truly marvelous proof of this comment, which this signature is too narrow to contain.
All the gibberish about "viruses for linux" and such self-same security matters...
Excuse me, I don't quite get it. A Linux system is as secure as the admin wanted or cared it to fasten. Period.
If/once bad guys have managed to meddle with it in whatever way, there is no use killing this or that seemingly misbehaving app; there is only one way to rectify matters, and that is, pull the power cord and call the admin in and have him inspect the matter. A particular, named human is in charge here, not a "vendor" nor a contracted third party.
At this point I wonder, if the very subject matter of the article and the research at large it underlies, is just a marketing push of AV companies to plant a foot where there's no foothold for them? They all belong and flourish in "Windows ecosystem", where they enjoy the same rights as malware proper. Why introduce them both in Linux?
Their method is to automagically profile the software when it's compiled. That's obviously something antivirus software doesn't do.
Antivirus software generally doesn't know how a particular piece of legitimate software is supposed to behave. The idea here is that the approach these guys are taking is exactly to try to build a profile for the normal behaviour of the application (or some parts of it, namely the pattern of syscalls). The analysis would be done at compile time, and when the application is being run its pattern of making syscalls would be matched against the known profile. That way the system could supposedly notice a compromised application or service because its pattern would be different than expected.
Also, the method would be powerless against trojans, for example, because they don't work by exploiting vulnerabilities in legitimate software and changing the way it's executed. To me the suggested system seems more like just a potentially boosted intrusion detection system, not general malware-pattern detection, which is what antivirus software does.
How well their profiling would actually work, that I don't know. Theoretically you can't make a complete analysis of all paths the execution of a program could possibly take (for an arbitrary program anyway). Multithreading and inter-process communication might make that even more difficult. But then, maybe it would be just possible to do it for some cases that practically occur with some decent probability.
if you need even need a normal anti-virus, you're to stupid to work with computers.
What if you want to download a freeware program to perform a task, but want to know if it's infected? What if your system has a zero day exploit and has been infected without you knowing? Anti-virus scanners are unfortunately a necessity when it comes to using pre-compiled binaries.
If you are never going to connect to the net or removable storage, and only use software that you have written yourself, then yes - anti-virus is unecessary
which is totally what she said
Maybe this sounds stupid, but in a weird way this reminds me of this little project here, and I think it is the wrong approach, no matter the subject. It might work better on a computer system because a lot can be predicted, complexity is simpler but i can see the same kind of false positives occuring with this system as well.
The consequences of course have a different quality of impact, this isn't dealing with human lives, but there still might be a lot at stake.
Power corrupts the few, while weakness corrupts the many.
Run it under a dummy user account.
Anti-virus doesn't protect you from zero-days either. If you want to check for infections, your best bet is to use some kind of tripwire software (with signed hashes stored and checked offline).
Then don't use pre-compiled binaries. Or like I mentioned above, use dummy accounts. Or try out the different tools for limiting system access (selinux, etc).
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?)
the article continues to say that those 40 have never been seen in the wild because they were research projects. it then links to a webpage called WildList, claiming that some viruses for Linux (sic) are mentioned there. the article is from 2003. i've been browsing WildList for the last 15 minutes, working my way back through 2008 and 2007 and have yet to find a virus for Linux (sic).
face it, there aren't any gnu/linux viruses in the wild, despite the fact that gnu/linux has a majority share of webservers---exactly those computers you would most like to infect.
The users who trains the model has to be knowledgeable. That is the same requirement as selinux. I should be possible to make SElinux trainable too(maybe there is software that already does that, I never checked), but you still need experts users who understand what an application does on OS level.
This kernel plugin is a kind of tripwire on steroids.
Very true. Good point. I didn't come to think that they'd want to allow impossible paths, but then, why not...
That is the second time I see someone complaining that it won't work on scripts, and the parent is a very well constructed answer to that.
Rethinking email
Hmm... you call me as idiot because I did not mention that I know the monolith kernel has the kernel space and user space (kernel mode, userland) separation.
But at least these speaks against your own comment.
http://tinyurl.com/532kb8
http://tinyurl.com/mum9x
http://tinyurl.com/qhuhg
http://tinyurl.com/3uaq48
I am not sure but if few computer science professors speaks about against your "OS = kernel + userland, with no distinction between a microkernel and a monolithic kernel" I say SOMEONE is wrong. And I would bet my money for professors and not for you.
Operating System is not there to do lots of things for you. It is there to allow you to run all other applications and libraries etc in your computer hardware. And if you even try to mention that there is no difference about monolith kernel and microkernel structure, I say you should first say what is wrong with all these links.
"This is a crucial, but subtle, point. The operating system is that portion of the software that runs in kernel mode or supervisor mode. It is protected from user tampering by the hardware (ignoring for the moment some of the older microprocessors that do not have hardware protections at all). Compilers and editors run in user mode."
(first link, others follows even this same)
http://tinyurl.com/532kb8
http://tinyurl.com/mum9x
http://tinyurl.com/qhuhg
http://tinyurl.com/3uaq48
After you have readed all those, tell me what is wrong on them with reasons and correct me! Because I want to know what is wrong on those if so!
I was wrong. Your original comment marked you as being ignorant.
It's your reply that reveals your abject stupidity. Even if your links supported your ridiculous assertion, you'd be arguing by appeals to authority. Since they don't, you're arguing by appeals to a lack of reading comprehension.
Thanks for your comment. :-)