Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Security IT

Remote Code Execution Hole Found In Snort 95

Posted by kdawson from the upgrade-right-now dept.
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.
This discussion has been archived. No new comments can be posted.

Remote Code Execution Hole Found In Snort More

Remote Code Execution Hole Found In Snort

Comments Filter:

  • SANS (Score:4, Informative)

    by azakem ( 924479 ) on Tuesday February 20, 2007 @10:12PM (#18091860)
    Also covering this one: SANS ICS [sans.org]

  • The very definition of irony (Score:3, Insightful)

    by Anonymous Coward on Tuesday February 20, 2007 @10:14PM (#18091876)
    Something designed to make your network secure turning out to be a security risk...

    • Re: (Score:1, Insightful)

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

    • Well, "the most secure Windows ever" comes close.

      But what gets to me is the fact that people are attacking security applications.... successfully.

    • Re:The very definition of irony (Score:4, Informative)

      by whoever57 ( 658626 ) on Tuesday February 20, 2007 @11:10PM (#18092312) Journal

      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]
    • 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: (Score:2)

      by Jessta ( 666101 )
      Good security is assuming that all you software is a security risk and acting accordingly.

  • Remote, what about stealth installations (Score:4, Insightful)

    by Gothmolly ( 148874 ) on Tuesday February 20, 2007 @10:24PM (#18091972)
    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: (Score:1, Insightful)

      by 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 a

      • Re: (Score:3, Insightful)

        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: (Score:2, Insightful)

        by JensenDied ( 1009293 )
        Isn't this why we use chroot for things like this?

        • Re: (Score:1, Insightful)

          by 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.
          • 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 =-)
        • If you have root priviliges, chroot is pointless. You can easily break out. [bpfh.net]

    • Re: (Score:3, Insightful)

      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 (Score:4, Informative)

        by gbobeck ( 926553 ) on Wednesday February 21, 2007 @04:39AM (#18093862) Homepage Journal
        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: (Score:1, Informative)

          by Anonymous Coward
          1. Umm, yes they do. Or at least ones other than snort do.

          2. WTF? A switch will work just fine unless it's a POS.

          3. Still don't know what you're talking about. Is this just a snort thing? Why would you need to transmit from a passive sniffer? It's freakin' passive.

          • 2. WTF? A switch will work just fine unless it's a POS.
            I think he's referring to the fact that once you plug it into the switch, traffic that isn't destined for the tap simply won't be "switched" to its port. On the other hand, hubs pass all traffic to all ports. Our Network Admin here can enable a "Span" port on a switch though that will send all traffic, no matter the destination, down that port for inspection.

        • Re: (Score:2)

          by 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: (Score:1)

          by hawg2k ( 628081 )
          Re #2 above, yes. Cat [56] has a 100 meter limitation. Depending on the type of TAP, you need to factor the length of wire on both sides of the TAP, plus ~ 10 feet for the TAP itelf. So the length of wire from the switch/router/server to side A of the TAP + the length of wire from the switch/router/server on side B of the TAP + ~ 10 feet must be = 100 meeters.

          Been bitten by this one a few times. It's a real b!tch to troubleshoot, depending on how close to 100 meters you are. It works - doesn't work - w
    • 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?

  • Somehow, this must be... (Score:3, Funny)

    by Anonymous Coward on Tuesday February 20, 2007 @10:28PM (#18091994)
    ...Microsoft's fault.

  • Silly Hackers (Score:5, Funny)

    by tyrax ( 907001 ) on Tuesday February 20, 2007 @10:38PM (#18092096)
    People who run linux don't have any money to steal.

    • Re:Silly Hackers (Score:5, Insightful)

      by Lord Ender ( 156273 ) on Wednesday February 21, 2007 @12:41AM (#18092854) Homepage

      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.

      • Colbert-esque humor
        The word is "satire".

  • Why this vulnerability? (Score:4, Insightful)

    by madsheep ( 984404 ) on Tuesday February 20, 2007 @10:58PM (#18092226) Homepage
    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: (Score:3, Insightful)

      by tiny69 ( 34486 )
      Previous story submitters didn't allude to a conspiracy that the government is getting 0wn3d.

  • So (Score:4, Funny)

    by OverlordQ ( 264228 ) on Tuesday February 20, 2007 @11:16PM (#18092340) Journal
    What's the Snort signature for this?

    Would be somewhat helpful saying "Hey look somebody is rooting me!"
  • when will the signatures to detect this attack become available?

  • Disable the dce/rpc preprocessor (Score:3, Informative)

    by caller9 ( 764851 ) on Wednesday February 21, 2007 @12:09AM (#18092712)
    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]
  • this made me snort my Coke and now I need a new keyboard, cause the keys are stuck...

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

  • 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 (Score:5, Informative)

    by Vintermann ( 400722 ) on Wednesday February 21, 2007 @04:06AM (#18093716) Homepage
    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 == ';') ...
    • OpenBSD is written in C. Maybe you can show us why OpenBSD is insecure.

      The "pending and unverified" status is essential a useless metric because Coverity uses an automated scan which is inherently prone to false-positives. Even so, from their site it looks like it's results are comparable to Apache.
    • 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

  • 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]

    • Re: (Score:1, Insightful)

      by Anonymous Coward
      Nobody is stopping you from writing your own IDS in whichever language you choose. Quite whining and start coding.
    • 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: (Score:2)

        by 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
      • You can do anything in assembly, but that is not an excuse for using assembly. That's why no one uses it anyway.
        • Assembly is not portable. C is.

          Most other languages have significant drawbacks in their respective implementations, or add too much bloat in implementation or understanding. It's hard to make a good case against C, though -- most things that are possible in other languages are possible in C, yet there are plenty of things that are possible in C which are not really possible in other languages. For example, I wouldn't consider writing a kernel in Java -- yet.

          I don't use C, but I also don't think other projec

          • Assembly is not portable.

            It could have been through bytecode. But no one programs in bytecode.

            C is.

            It is not. C does not define binary layout, for example, and therefore data structures may be used differently in different architectures. There are lots of other things that make C non-portable.

            Most other languages have significant drawbacks in their respective implementations, or add too much bloat in implementation or understanding.

            There are other languages that offer very little on top of C, w

            • C does not define binary layout, for example, and therefore data structures may be used differently in different architectures.

              There are plenty of portability libraries. In C, as in Perl, most of the porting has already been done for you.

              There are other languages much better than C that offer the same or better control and much greater safety: ADA, Cyclone, Dylan, Erlang etc

              Of those, I've looked at Erlang, and as far as I can tell, it's too slow and inflexible. And yes, I know it's used in mobile phones,

  • 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?
  • I thought only evil M$ released code that has security problems. Didn't they patent it for Vista? :-p

Slashdot Top Deals

Keep up the good work! But please don't ask me to help.

Close