Slashdot Mirror
Remote Code Execution Hole Found In Snort
Palljon1123 writes "A stack-based buffer overflow in the Snort intrusion detection system could leave government and enterprise installations vulnerable to remote unauthenticated code execution attacks. The flaw, found by researchers at IBM's ISS X-Force, affects the Snort DCE/RPC preprocessor and could be used to execute code with the same privileges (usually root or SYSTEM) as the Snort binary. No user action is required." Sourcefire has an update to fix the vulnerability in versions 2.6.1, 2.6.1.1, and 2.6.1.2; Heise Security spells out the workaround for the 2.7.0 beta version.
Boaring!
Navicula hydraulica plena anguilarum est. Omnes castelli tuus nostri sunt. Ed elli avea del cul fatto trombetta.
Also covering this one: SANS ICS
Something designed to make your network secure turning out to be a security risk...
Its a remote overflow, does it work if the sensor doesn't have an IP address? If it merely sees the right pattern of 1s and 0s on the wire, it roots itself? Article sadly lacking detail.
I want to delete my account but Slashdot doesn't allow it.
...Microsoft's fault.
People who run linux don't have any money to steal.
It is interesting this vulnerability makes it into Slashdot where other [past Snort/Sourcefire] vulnerabilities of the same magnitude have not. It would definitely be time to upgrade but the number of people running 2.6.1, 2.6.1.1, 2.6.1.2 and 2.7.0 beta 1 are probably not as wide spread as 2.4.x, 2.6.0, and probably earlier versions. Luckily this vulnerability has been identified by a bunch of good researchers and the potential exploit probably hasn't been developed by anyone malicious. The real fear here of course is not just that *a box* might get rooted.. it's that a box running Snort/Sourcefire might get rooted. Generally this box will of course sit inline on the network or have sort of span/mirror port running to it. Whenever an IDS, switch, or router compromise is possible it can truly spell bad news. However, I'd say in this case it's not likely that a whole lot would happen even if an exploit should be developed.
What's the Snort signature for this?
Would be somewhat helpful saying "Hey look somebody is rooting me!"
Your hair look like poop, Bob! - Wanker.
when will the signatures to detect this attack become available?
Irony? I would tend to disagree -- rather, I think it is to be expected. Snort is a perfect example of the kind of "solution" that, instead of fixing the real problems, just adds another layer on top of everything to cover them, increasing the overall complexity of the system, and the more complex a system gets, the more likely it is to show unexpected behavior. That kind of reasoning also perfectly well explains why Windows will never be as secure as any Unix flavor.
You shouldn't have the DCE/RPC preprocessor running, you shouldn't be exposing RPC to the internet anyway. FC6 default install of 2.1.1.2 has it disabled in snort.conf.
There are some instances where this should be running such as internal traffic monitoring, but I don't see how this can hit people from the internet with fragmented RPC traffic unless they're allowing it at the firewall.
Also, don't run any network service as root. FC6 install of snort does run as root by default, kinda lame.
-u username -g groupname arguments in the init script when starting the daemon will make it run as username:groupname credentials. nobody:nogroup maybe. Consider also chroot jail.
Old tips http://isc.sans.org/diary.html?date=2005-10-18
this made me snort my Coke and now I need a new keyboard, cause the keys are stuck...
Excuse me, but please get off my Pennisetum Clandestinum, eh!
If an intrusion detection system has to run as root, it's part of the problem, not the solution.
Biggest single security problem with UNIX and Linux is that way too much stuff runs as "root". Too much trusted code.
Not that Windows is much better, although, in Vista, they're finally trying.
We're talking pigs here, not goats. Dumbass.
This is not your signature.
Quit hogging the first post
Or at least it should be splitting itself up so that the module that grabs all traffic is separate from the module that does significant processing of the traffic (which hopefully then gets locked down),
Snort has had a pretty poor track record for this (for that matter tcpdump has also had similar problems).
Why oh why are we in 2007 seeing code like this in security apps? input verification in the classical C way with pointer arithmetic on strings.
/* go to the end of the string */
/* the last non-whitspace character should be a ')' */
/* the next to last char should be a semicolon */ ...
(and no, the error isn't there, it's just the first thing I came across in the snort source)
Why are they even using C? Suprise, they make exploitable buffer overflow attacks! And they still have one verified, non-fixed issue detected by coverity, plus 33 "uninspected and pending" according to coverity's scan.
int CheckRule(char *str)
{
int len;
int got_paren = 0;
int got_semi = 0;
char *index;
len = strlen(str);
index = str + len - 1;
while((isspace((int)*index)))
{
if(index > str)
index--;
else
return 0;
}
if(*index == ')')
{
got_paren = 1;
index--;
}
while((isspace((int)*index)))
{
if(index > str)
index--;
else
return 0;
}
if(*index == ';')
xkcd is not in the sudoers file. This incident will be reported.
Can we stop now using C, please? pretty please?
how many more buffer overflows do we need to get persuaded that C does not cut it any more? working at 95% of the cases is not good enough in this day and age.
How many times does it have to be said?
It's been a long time since I've used Snort, so maybe things have changed, but why the heck doesn't it use a privilege separation scheme to prevent things like this? It seems a lot of the packet decoders (Ethereal/Wireshark, Snort, etc) have a continuous trickle of buffer issues which lead to security exposures. Since we know that parsing is hard, why not do it across a well defined interface to a non-root process?
First, yes, there is way too much stuff running as root. Would you kindly point me to a system that doesn't have this problem?
But I would hardly call this the "biggest security problem", especially considering the vast majority of stuff does NOT run as root, and even daemons which must be started as root drop privileges later on.
It seems equally likely you'd find some bitwise monstrosity to an actual mention of 1024/1023, but in any case, there is a good reason for this. Think NFS, or basically any other service which doesn't have crypto layered on top of crypto -- even if I tunnel NFS through a VPN (which had its own problems, last I tried), that doesn't stop some local, non-root process of attempting to respond. In fact, suppose it's a fileserver that everyone boots from, and the NFS service has crashed. If we allow non-root to bind privileged ports, that also means non-root can then impersonate that NFS server and gain access to everything out there that relies on that NFS.
Now, NFS is arguably bad design here, but you get the idea. Connecting to a privileged port at least means you know what you are connecting to is owned by root, and thus sanctioned by the machine as a whole. If you're connecting to an unprivileged port, you really don't know if you're connecting to a service that the admin has actually set up, or something run by some user account.
I agree about iptables -- forwarding low ports to high ports is half-assed and stupid. Please at least try to understand the rationale behind a security measure before you willfully disable it.
Also, chroot can be complicated -- but it can also be very easy. However, it's not a replacement for the simplest rule here: Drop privileges. Once you bind to the port, you can drop root and become nobody, bound to that privileged port -- and the code that does that can be very simple. Simple enough that you can even throw it into a separate solution -- think inetd/xinetd, where the inetd itself must at least in part remain root, but your actual daemon (webserver or whatever) can be run as any user you like.
You may think this isn't always feasable, and to an extent, you're right. There may be parts to your program that must remain root. However, traditional *nix style would be breaking your program into small, cooperating programs and having only a few of those remain privileged. A good example here would be postfix -- it is split into five or ten processes, only one of which remains root, all others staying low-privileged and often chrooted. It may look strange and complicated at first glance, but it's actually a remarkably clean architecture.
Personally, I think Unix security is not really fine-grained enough. It provides the primitives that could be used to create a truly secure system, but at the moment, root is irrelevant on 99% of people's desktops. I have my su not even ask for a password if I'm in the "wheel" group, and I don't encrypt my SSH keys, because if someone 0wns my normal, everyday account, they've got me in every way that matters. What we want is a Postfix-like approach to per-user code. However, this is more on the desktop, "Let's get UAC right" side of things -- on the server side, it's actually pretty elegant as-is.
Don't thank God, thank a doctor!
Buffer overflows are the result of bad C programming, not of the C language in itself. You can, actually, do OO in C, and it's actually a nice lightweight language when compared to, say, C++ and Java.
Personally, I wish we saw more "scripting" languages around, but those don't cut it either as soon as you start to care about performance. Getting there, but nowhere close to C... yet.
Don't thank God, thank a doctor!
Ok, I'll talk about performance. Performance in this context is never, ever plural, unless you were talking about, say, dance performances.
But seriously, look at your Java VM. Look for all the benchmarks and justifications you like, but the fact is, I still have to wait on my machine in order to try Hello.java. It feels slow, and I can actually go find some benchmarks to prove it is slow.
Which becomes irrelevant when you run more than one of them.
Now, I actually agree with you -- in theory, a VM should be as fast or faster than C. In theory, multithreaded apps should be easy to write. And yes, in practice, there are ways to protect yourself from buffer overflows, although it won't save you from other stupid mistakes.
However, the first two have a theory which hasn't caught up with practice yet (I'm working on that), and in practice, buffer overflows are really secondary to sheer programmer stupidity -- see the Tetris/plane exploit? The buffer overflow was what brought the whole system down, but there is no language that automatically saves you from allowing a user to put the system into an invalid state. With a phone.
Don't thank God, thank a doctor!
"But seriously, look at your Java VM. Look for all the benchmarks and justifications you like, but the fact is, I still have to wait on my machine in order to try Hello.java. It feels slow, and I can actually go find some benchmarks to prove it is slow."
You have to wait because you have to wait for the jvm to load.
Or the program was really poorly written.
Java isn't slow when the jvm is in memory. Imagine if you bench-marked helloworld.exe from the time windows started to boot until the program opened the window.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
Hello, world? How, exactly, would I write that poorly?
At a second glance, however, you're right -- it's actually reasonably fast now. I distinctly remember having to wait quite awhile for just about any program -- and it was not disk thrashing, hard disk light was off.
Still, it will be awhile before you can convince me that Java is fast enough, and awhile more before you can convince me that the syntax is even tolerable. Yes, you can run other languages on the JVM, but it's not really designed for them.
Don't thank God, thank a doctor!
I thought only evil M$ released code that has security problems. Didn't they patent it for Vista? :-p
It's OK Bender, there's no such thing as 2.
It is hard to write a really bad hello world. However it is real easy to write very slow Swing code.
I like Java because it has a base object unlike c++ which is c with objects tacked on.
The support staff where I work calls back customers that request a support call so they don't have to wait on hold. I wrote the program that manages the support calls, RMAs, and issue tracking in Java using Postgresql as the back end. It has handled 300,000 support calls and I don't know how many RMAs over the years with no problems.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
...are condemned to reinvent it, poorly.
/home/sanity/bin/smtp, and run it as me.
/home/sanity/bin/smtp" as the command to run.
Ok, let's assume your admin is root, or is able to run commands as root (through sudo). Let's also assume we have setuid bits, as I've never run into a Unix that doesn't.
Right now, we have the very inflexible approach, where the first 1024 ports are considered "privileged", and only root may bind to them. We also have a bunch of users with daemons designed to bind to some of those ports.
There are actually several really easy ways for root to handle this. The first, and most obvious, is to simply run xinetd, which is an internet superserver. It allows you to define services -- each service is a configuration of a port for xinetd to listen on and a program to execute when a connection is found. That program's standard input and output is connected to the connection.
So, only root can configure xinetd, but root can certainly configure it to run daemons as users -- supposing I wanted to be the one in charge of SMTP, I could simply ask root to forward port 25 connections to
Actually, I don't remember whether xinetd allows you to change the user under which a command is run, but that doesn't matter. The admin could easily customize that command to point to my user -- just put "su sanity -c
This may not provide as much control as you want, of course -- users can't control whether a port is open or closed. It's certainly less efficient; a new process must be spawned for every connection -- although that is more efficient if you have a lot of services that are connected to almost never, so you won't actually need any daemons running most of the time except xinetd.
But if you wanted to make it better, it seems like it would be much easier to write something like xinetd, or even just a small program runnable under sudo. It is possible (though tricky) to pass open sockets through to exec()'d programs, and even if it weren't, one could always write a server which bound to a socket, dropped privileges, and then called a user-defined library.
The downside to this is, of course, you have to write daemons to expect one of the above approaches. If you want to work with existing programs -- for instance, if you want to be able to start Apache unprivileged -- that is when you would start to implement something more complex. At this point, SELinux probably provides what you want, but it also requires kernel patches and introduces a LOT more complexity for the admin to manage than simple xinetd rules. However, properly configured, SELinux should allow you to run most existing stuff unmodified -- if I understand it right, you could probably configure apache to be allowed to open port 80 (even when not run as root), or even configure it to run as root, but not be allowed to do anything other than open a port and drop privileges.
I still like the root-only approach, though, as it's very simple and very clean, especially in terms of kernel code. The kernel only has to check whether it's a privileged port, and whether the user is root -- all the complexity is pushed out to userspace.
Don't thank God, thank a doctor!
Great! Now explain to me why this is a good thing.
Alright, I'll give you this one.
I'm still looking for a language that is powerful, flexible, bytecode-portable, and at least close to as fast as C. Java may have the last two -- maybe -- but it's sadly lacking in the first two.
Don't thank God, thank a doctor!
" I like Java because it has a base object unlike c++ which is c with objects tacked on.
Great! Now explain to me why this is a good thing."
Well I learned structured programing when I first started programing in the early 80s. I am a proud owner of Data Structures + Algorithms = Programs by Wirth. After banging my head on objects for a while I finally got it and found it to be a great way to program. It is extremely useful when dealing with threads. You may not like OOP but I find it very comfortable way to write stable multi-threaded code. BTW I am also writing multi-threaded code using c under Linux for an embedded project and yes it is stable but you really have to be extremely careful and debugging threads in c under Linux isn't a lot of fun.
Java's main limitations are ones that you will have with any bytecode environment. It isn't easy to access platform specific features but that is part of that price you pay for portable bytecode. Flexible, I have never found that Java gets into my way any more than c or c++ does. I will also admit that I really like Netbeans as an IDE but that is also a personal choice.
I still haven't found a prefect language but if you find one let me know. Of course I have heard a lot of great things about Smalltalk but I haven't learned it yet.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
Erm... no, I know why OOP is a good thing. I don't know why Java OOP is any better than C++ "tacked on" OOP.
Explain to me why it is a good thing that the class "Object" exists? It seems to me that the only time you actually need to use it is when forceably typecasting stuff in a very un-OO-like manner.
Except C# and .NET make this ridiculously easy, and are still somewhat cross-platform, thanks to Mono. What's Java's excuse?
There actually is someone I was talking to about a language he was creating, which sounds perfect. But therein lies the problem -- creating. Still nothing actually finished yet.
Don't thank God, thank a doctor!