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.
I looked once on their code. it's a horrible mass of undocumented, non-modular, un-resuable code.
In the end I decalred their code unusable, and the developement took other direction.
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?
For programmers refusing to use newer technologies making buffer overflow a thing of the past. And please don't start talking about performances: it's really pathetic to see all those supposedly written in a fast language single-threaded apps running dog slow on all these newer multi-core CPUs.
I'm not necessarily talking about something like a Java VM, which hasn't had a single buffer overflow since it exists (except when linking to some Linux third-party C written libs). There are solutions for good ole' C programs too.
A buffer overflow, from people pretending to write application concerned with security. FFS!
Common, security conscious people, it's 2007, wake up... We want secure multi-threaded apps.
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!
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.
...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!