This was the only sign of this vulnerability that I could find (i didn't look very hard). Solution says to upgrade to Snort 2.3.0-RC1 or later (RC2 is out now). Netmon, please verify and bump if necessary. See URL for more information.
http://secunia.com/advisories/13664/
Confirmed in 2.3.0RC1 Changelog : * src/decode.c: Fix TCP/IP options print bug that was found by Marcin Zgorecki. However, << Successful exploitation requires that snort is configured with "FAST" output or verbose mode. >> I am not sure we should consider this is a vulnerability, it looks rather like a bug. The SNORT team for sure doesn't consider this is a vulnerability and doesn't talk about this bug in Changelog summaries...
a bug that causes DoS == a vulnerability, imho. Are the fast output and verbose modes enabled by default? Backporting the patch is probably not an option, and bumping to a release candidate isn't always the best idea (i'm not sure what the policy is on this). netmon, please verify/advise.
If a specific packet crashes long-running SNORT sensors, yes it's a DoS and yes it's a vulnerability. But if it only crashes SNORT if you run in verbose mode (primarily used on a given trace, not on long-running sensors), then you don't really "deny service". You just crash a trace-reading tool. It's a bug... that you solve by updating the tool. So it all depends on whether FAST/verbose output modes are used in a "server" context or not.
From SNORT team : =========================== First off... If you are using 2.3.0 RC1 or RC2? You are not vulnerable. Get back to work! Yes, Snort is vulnerable to a denial of service. The bug was reported by Marcin Zgorecki, and fixed by Dan on 2004-10-04. You are only vulnerable if you are running snort with "FAST" output (which isn't very fast) or in verbose mode. Neither of these methods are recommended for production, so this bug should not be a problem for most people. Using barnyard? Using snortdb? You are not vulnerable. Using FAST output? Use this as an opportunity to switch to a faster output plugin (unified, and barnyard) or upgrade to 2.3.0RC2. ============================= netmon, please bump to 2.3.0 RC2
I'm looking into this now
./snort-2.3.0_rc2.ebuild commited. Needs further testing in combinations of use flags (little bit) and functionality of snort itself. Would be good if someone could write a src_test function for this ebuild ;-). Happy testing and good night.
jaervosz and I vote NO to a GLSA for that one. DoSsing a probe running in non-recommended-in-production modes may be considered a vulnerability, but it's certainly not a serious one. This will be ready for closing once all KEYWORDS are set.
Test plan: emerge snort-2.3.0_rc2.ebuild cp /etc/snort/snort.conf.dist /etc/snort/snort.conf check a network interface exists in /etc/conf.d/short (eth0 by default) /etc/init.d/snort start nmap {serverip} look in /var/log/snort/alerts for errors. Known issues: have some -fPIC problems with dev-db/unixODBC that prevent snort starting on ppc with USE=odbc. Still investigating.
ppc (me), sparc and amd64 keywords desired. Test plan as per comment 9. I'm attempting to resolve odbc PIC issues that may/may not affect you (ppc affected). Don't worry about it too much. Its a very minor additional extra for snort that will hardly be used.
Only sparc needs to test and mark stable, this was never stable on amd64.
ppc stable. libodbc -fpic troubles will be another bug.
Seems to be broken the same way as before for sparc (bug #29661). BTW, libodbc doesn't seem to affect us.
Masked across the board on sparc with regard to bug #75395. Basically this could only work correctly when compiled in 64 bits on sparc64, and since that's not fully supported atm, it gets the old maskaroo.
Then we're done, since it will not trigger a GLSA
Shawty fire burnin fire burnin on the dance floor
