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.

The very definition of irony

[Anonymous Coward]

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

Re:The very definition of irony

[Anonymous Coward]

followed by a detection being created in the product the exploit targets....

Remote, what about stealth installations

[Gothmolly]

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.

Why this vulnerability?

[madsheep]

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:Remote, what about stealth installations

[Anonymous Coward]

If it is actually able to execute code, then part of that code could be to establish an IP address, open up a port, send out a beacon, whomp the box, etc...
Shellcode for a backdoor is the classic example but any small amount of bootstrap code could execute.

On an unrelated note: This exploit shows a weakness in the default Linux/UNIX security model: SNORT basically has to run as root in order to listen to raw traffic (and that is probably a good thing too). However when it does so, the rest of the program also runs with root privileges, including complex and bug-prone things like protocol analyzers (like the RPC analyzer).
There are some solutions for this, snort could be re-coded using privilege separation similar to openSSH, but that would probably be too slow for a program like snort (the speed is not much of an issue for SSH).
Alternatively, something like SELinux could contain the snort process to put it into a restricted domain where even having root privileges would not allow snort to execute other programs, open non-typed files (like shadow) or to make syscalls for opening sockets/getting IP addresses. Main problem with SELinux: Not always easy to use. The good news: Usually people running snort for real should know it. Issue: How many Linux based installs of snort are actually protected in any real way????

Re:Remote, what about stealth installations

[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 nobody or another group not allowed to mess with the rest of the system. Once again, it has to be used properly though.

Re:Remote, what about stealth installations

[JensenDied]

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

Re:Remote, what about stealth installations

[Anonymous Coward]

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

A chroot jail is good, but unless I'm mistaken it only cuts off access to the global file namespace. The rooted process can still make system and network calls that could do quite a bit for an attacker, although taking over the whole machine would still require the ability to effectively escape from the chroot jail.

Re:Why this vulnerability?

[tiny69]

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

Re:Silly Hackers

[Lord Ender]

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:Remote, what about stealth installations

[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:Now can we stop using C, please?

[Anonymous Coward]

Nobody is stopping you from writing your own IDS in whichever language you choose. Quite whining and start coding.