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.

SANS

Also covering this one: SANS ICS [sans.org]

The very definition of irony

Something designed to make your network secure turning out to be a security risk...

Re:The very definition of irony

Something designed to make your network secure turning out to be a security risk...

Unfortunately, Snort seems to a history of such vulnerabilities. [google.com]

Remote, what about stealth installations

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.

Re:Remote, what about stealth installations

I did a network security project [luc.edu] for a class at Loyola University Chicago not too long ago. As part of that project, I built a passive ethernet tap [luc.edu].

There are a few problems with passive taps...

1. They *don't* work with gigabit ethernet. If I remember the spec for gigabit ethernet correctly, this has something to do with the fact all of the wire pairs are used for XMIT and RECV.

2. The passive tap in the link you provided isn't exactly good for your network. This tap will still draw current as well as introduce some interference. In the worst case, you can blow a NIC with one of these. Of course, the easiest way around these problems is to use a hub (do not use a network switch as that won't work... you need a HUB).

3. You will need to run 2 NICs (1 for XMIT, 1 for RECV) in order to examine full duplex traffic. This may be an issue if you are trying to run snort on an embedded device.

If I had the option, I would rather run a spare computer as a Linux (or BSD based for that matter) firewall box and use port mirroring to mirror ethernet traffic over IEEE1394 (firewire) to another box running snort. The only downside is that ethernet over firewire is at best a 400 megabit connection.

Somehow, this must be...

...Microsoft's fault.

Silly Hackers

People who run linux don't have any money to steal.

Re:Silly Hackers

People who run linux don't have any money to steal.

Every company large enough to need a Security team (you know, the companies with the most money) is going to be running Linux. Nearly all the best infosec tools are Linux apps. I know you are likely going for Colbert-esque humor here, but the fact is that companies that run Snort on Linux probably have much MORE money to steal, on average, than companies that do not.

Why this vulnerability?

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.

So

What's the Snort signature for this?

Would be somewhat helpful saying "Hey look somebody is rooting me!"

What I'd like to know is...

when will the signatures to detect this attack become available?

Disable the dce/rpc preprocessor

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 [sans.org]

Darn...

this made me snort my Coke and now I need a new keyboard, cause the keys are stuck...

Shouldn't be running as "root".

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.

snort shouldn't be running as root

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).

Completely unnecessary

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.
(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 [coverity.com].


int CheckRule(char *str)
{
        int len;
        int got_paren = 0;
        int got_semi = 0;
        char *index;

        len = strlen(str);

        index = str + len - 1; /* go to the end of the string */

        while((isspace((int)*index)))
        {
                if(index > str)
                        index--;
                else
                        return 0;
        } /* the last non-whitspace character should be a ')' */
        if(*index == ')')
        {
                got_paren = 1;
                index--;
        }

        while((isspace((int)*index)))
        {
                if(index > str)
                        index--;
                else
                        return 0;
        } /* the next to last char should be a semicolon */
        if(*index == ';') ...

Now can we stop using C, please?

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? [slashdot.org]

Privilege separation?

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?

But wait!

I thought only evil M$ released code that has security problems. Didn't they patent it for Vista? :-p

Re:Year of the ..

Year of the ... Pig!

Boaring!

Re:You FAI:L it (goatse)

We're talking pigs here, not goats. Dumbass.

Re:Year of the ..

Quit hogging the first post

Re:Buffer overflow is the price to pay...

And please don't start talking about performances

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.

single-threaded apps running dog slow on all these newer multi-core CPUs.

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.