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:

[TCM (130219)]

Have you looked at any professional switch at all?

My cheap "web-managed" switch allows me to specify a monitor port where all traffic from (an)other port(s) gets duplicated to. This port is not a member of any VLAN and has non-tagged ingress traffic blocked. So effectively it's a send-only tap from the switch's POV.

Any halfway decent switch can do that.

Re:

[gbobeck (926553)]

I know about span ports, but I totally forgot to include them in my post.

Re:

[gbobeck (926553)]

Hey, since you're back, let me ask you to expand on why gigabit ethernet won't work. I'm confused about that since there shouldn't be any problem linked up as and reading packets at 1 Gb/sec in my experience.

The best explination I can give comes from the Wikipedia entry for gigabit ethernet [wikipedia.org]. I have put in bold the exact technical reason why a passive ethernet tap cannot work with gigabit ethernet.

1000BASE-T (also known as IEEE 802.3ab) is a standard for gigabit Ethernet over copper wiring. It requires, at

Re:

[accessdeniednsp (536678)]

I agree. In all of my IDS deployments, Snort is started with snort -u snort -g snort so I don't understand how/why people are using root, and why a default install would be setup that way. Haven't we learned anything from the last 30 years of Unix?

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

Re:

[Raenex (947668)]

I take it you really like the word "such"?

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:

[Bacon Bits (926911)]

Colbert-esque humor

The word is "satire".

Re:

[Lord Ender (156273)]

I am aware of that. But "Colbert-esque" just rolls off the tongue better, don't you think?

Re:

[tsalaroth (798327)]

Not to mention it increases the truthiness of your statement.

Re:

[Lord Ender (156273)]

There are big companies which run all Windows servers. A lot of people at places may not even be aware of the fact that their security systems run on Linux. They may think "we're a Windows shop, so this doesn't apply." That is why this was important to point this out.

My intended audience was not the poster specifically, but the slashdot audience as a whole.

Based on the fact that you missed the point entirely, and your post consisted of nothing but angry insults, I'm going to guess that you bring amiable per

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

Re:

[iamacat (583406)]

Your noose bled that much? You should really cut down.

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.

Re:

[Animats (122034)]

can anyone shed light on why we have wanted this in the first place

It was a Bill Joy thing in 4.2BSD. The idea was that UNIX systems could trust each other, but not their users. The old "rcp" protocol reflected this approach. The Berkeley guys were thinking of big multi-user time-sharing systems under central administration, not single user systems.

Early BSD team thinking was that it was good enough if BSD could talk to BSD. Interoperability with other TCP/IP systems had to be pounded into that cro

You're both wrong.

[SanityInAnarchy (655584)]

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 se

Re:

[Raenex (947668)]

Instead of only allowing root to bind to critical ports tt seems that the more flexible approach is to let the admin configure who can bind to those ports. And of course the default should be something secure so that not any random user can connect to the NFS port.

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:

[Random Walk (252043)]

C is the only really portable language with decent performance. Java et al. is fine on M$ and Linux, but what if your application should be able to run just as well on some dozen of other operating systems which may not even have an implementation of your favourite managed language (and if, one that is slightly incompatible with all other implementations of that language)? Things may be improving, but at the time the snort project was started, there certainly was no alternative with respect to portability a

Re:

[Vintermann (400722)]

To lazy to have proper spelling, too. Certainly too lazy to write software I will use to protect my computers.

To this:

And even if you would erradicate Buffer Overflow you are still
exposed to logical bugs, execution path subvertion, trust
bypass and many other security nasties.

I quote Babbage:

If you speak to him of a machine for peeling a potato, he will pronounce it impossible: if you peel a potato with it before his eyes, he will declare it useless, because it will not slice a pineapple.

Re:

[raddan (519638)]

To lazy, or not too lazy: that is the question.

Re:

[Raenex (947668)]

Nice quote. I haven't seen that before. I agree with you -- it's truly sad that in 2007 people writing security software are doing it in C with pointer arithmetic.

Now can we stop using C, please?

[master_p (608214)]

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]

C is enough, much as I hate it

[SanityInAnarchy (655584)]

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.

Re:

[DimGeo (694000)]

Apart from C++ taking bloody ages to compile, you can actually end up with smaller code when writing in C++, but it's damn tough to do it - and so that's not a real argument for C++.

Anyway, even if C++ == bloat, you can still use stl's std::string, std::vector and std::map for most of the simple programming tasks. Sure, they're slow. They add like 1 meg of code bloat and stuff. But you don't get nasty errors from dealing with pointers and memory allocation stuff. And for a userland app that's perfectly reas

Re:

[master_p (608214)]

You can do anything in assembly, but that is not an excuse for using assembly. That's why no one uses it anyway.

Privilege separation?

[Halo- (175936)]

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?

Re:Year of the ..

[gbobeck (926553)]

Year of the ... Pig!

Boaring!

Re:

[SanityInAnarchy (655584)]

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 C

Re:

[LWATCDR (28044)]

"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 wi

Re:

[SanityInAnarchy (655584)]

Or the program was really poorly written.

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

Re:

[LWATCDR (28044)]

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