Bugzilla Bug 135112

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.