A large scale Snort evasion has been discovered by Blake Hartstein, a member of the Demarc Threat Research Team. The evasion technique allows an attack to bypass detection of "uricontent" rules by adding a carriage return to the end of a URL, directly before the HTTP protocol declaration. This affects thousands of rules in the standard Snort base rule sets. For example, in order to evade detection of an AwStats Vulnerability (sid:3813), using netcat: $ perl -e'print "GET /awstats.pl?configdir=|backdoor\r http/1.0\r\n\r\n"'|nc vulnerable.server 80 Due to the seriousness of this vulnerability, we have developed a patch for public review. See below. This patch addresses the carriage return bug and catches the known evasion attempts but further research should be done to determine if there are any other possible impacts of this bug. The detection for evasion is turned on by default under all profiles but can also be used as a server configuration option: -----HTTP Inspect Server Configuration----- non_std_cr <yes|no> This option generates an alert when a non standard carriage return character is detected in the URI. -----end----- The patch was generated for Snort version 2.4.4 , and a pre-patched Snort 2.4.4 tarball as well as the diff file is available below: \ http://www.demarc.com/files/patch_20060531/snort-2.4.4-demarc-patched.tar.gz http://www.demarc.com/files/patch_20060531/snort-2.4.4-demarc-patch.diff
*** Bug 135113 has been marked as a duplicate of this bug. ***
Could the netmon herd test this and provid ebuilds, if needed? thanks rgds Daxomatic
committed as 2.4.4-r1
Please test and mark stable As all were fine with 2.4.3-r1 already, this shouldn't be that big problem, right?
I'd rather wait for snort.org patch rather than include the demarc one. It's not wise to mess with snort using third-party patches and snort.org is going to release an official one on monday.
netmon is this ready for stable marking or do you want to wait for the official patch?
fix seems to be incomplete, waiting for official upstream release that is expected to come $soon
(In reply to comment #3) > committed as 2.4.4-r1 > Not sure if I should make this a new bug or not, but the new snort-2.4.4-r1 which has made it into portage now has a dependency on net-libs/libpcap instead of vitual/libpcap. Some of us use the libpcap-ringbuffer ebuilds to get the MMIO performance improvements (see bug 117898 for a libpcap-ringbuffer ebuild that actually works...not sure why it hasn't made it into portage yet). Despite the original title of bug 117898, libpcap-ringbuffer should (and does) provide virtual/libpcap.
Back to ebuild to get this regression fixed. Netmon please fix or comment.
As 2.4.5 was just released, bumped now also changed the dep to virtual back again
Arches please test and mark stable.
stable on ppc64
ppc stable
x86 done
amd64 stable. sorry for the dely.
Time for GLSA vote. I tend to vote YES.
I vote NO. The original advisory is over-hyped, this is a minor possible evasion which is not considered as a vulnerability by the vendor itself. It is a bug of course but no glsa is necessary imho.
I tend to vote NO too. For example, a worm that would exploit awstats /and/ evade detection should have its own snort sig, rather than be caught by the usual one...
OK, let's kill this one without a GLSA.
