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

[azakem (924479)]

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

The very definition of irony

[by Anonymous Coward]

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

Re:The very definition of irony

[whoever57 (658626)]

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]

Ironic? Hardly.

[Dolda2000 (759023)]

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.

Re:

[Jessta (666101)]

Good security is assuming that all you software is a security risk and acting accordingly.

Re:

[pilkul (667659)]

Ack! Thanks to that annoying song, not only do people frequently misuse the word "irony", any genuinely correct use (such as the GP's) is immediately attacked by idiots who claim it's incorrect. Curse you, Alanis! Curse you!

Remote, what about stealth installations

[Gothmolly (148874)]

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:

[by Anonymous Coward]

Good point. This is also another reason to implement a passive only tap [snort.org] for your snort box. In that situation the worse case scenario is your sensor sniffs some traffic that causes it to get compromised and it stops working or at least not correctly. Even if somehow a worm gets injected into the system from this passive sniffing it can't go anywhere. Unless your dumb enough to have your IDS machines hooked up to your internal network via another NIC. Keep your IDS sensors passive and isolated!!!

Re:Remote, what about stealth installations

[gbobeck (926553)]

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.

Re:

[by Anonymous Coward]

To reply to myself:
From snort 2.6:

-g Run Snort as group ID after initialization.
This switch allows Snort to drop root privileges after
it's initialization phase has completed as a security
measure.

That could be very helpful if the group is no

Re:

[JensenDied (1009293)]

Isn't this why we use chroot for things like this?

Re:

[TheSkyIsPurple (901118)]

Just getting root even without the FS is bad enough though... gets you by lots of firewally fun, and alot of folks thinkg a firewall is good enough security. You also have access to the memory space and processes and such, so you can really direct probes and such.

Oh such fun to be had =-)

Somehow, this must be...

[by Anonymous Coward]

...Microsoft's fault.

Silly Hackers

[tyrax (907001)]

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

Re:Silly Hackers

[Lord Ender (156273)]

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.

Re:

[tsalaroth (798327)]

Not to mention it increases the truthiness of your statement.

Why this vulnerability?

[madsheep (984404)]

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.

Re:

[tiny69 (34486)]

Previous story submitters didn't allude to a conspiracy that the government is getting 0wn3d.

So

[OverlordQ (264228)]

What's the Snort signature for this?

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

Disable the dce/rpc preprocessor

[caller9 (764851)]

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

[flyingfsck (986395)]

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

Shouldn't be running as "root".

[Animats (122034)]

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

[TheLink (130905)]

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

[Vintermann (400722)]

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 == ';') ...

Re:Year of the ..

[gbobeck (926553)]

Year of the ... Pig!

Boaring!