Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Security IT

Remote Code Execution Hole Found In Snort 95

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

Comments Filter:
  • SANS (Score:4, Informative)

    by azakem ( 924479 ) on Tuesday February 20, 2007 @11:12PM (#18091860)
    Also covering this one: SANS ICS [sans.org]
  • by whoever57 ( 658626 ) on Wednesday February 21, 2007 @12:10AM (#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]
  • by caller9 ( 764851 ) on Wednesday February 21, 2007 @01: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]
  • by Vintermann ( 400722 ) on Wednesday February 21, 2007 @05: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 == ';') ...
  • by gbobeck ( 926553 ) on Wednesday February 21, 2007 @05: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.
  • by Anonymous Coward on Wednesday February 21, 2007 @09:29AM (#18094870)
    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.

Old programmers never die, they just hit account block limit.

Working...