Update: The subject for this diary entry now starts with a '*', which should make "iscalert" (aka: the little taskbar globe thing) blink. We do think that the snort vulnerability is a high priority issue that needs immediate attention. Check if and where you have snort running and for now at least disable the BO plugin.

---

ISS released an advisory regarding a vulnerability in Snort's Back-Orfice pre-processor. The vulnerability could be used to execute arbitrary code on the snort sensor. Also, see the advisory at snort.org for more details.

As an immediate step, disable the BO preprocessor, by commenting out this line:

# preprocessor bo

this should eliminate the issue, and these days, Back Orfice is not all that much of a threat compared to other trojan/bots. You should also consider upgrading to Snort 2.4.3, which will fix the issue.

This vulnerability is "nasty" for a number of reasons. First of all, it takes a single UDP packet to exploit, which isn't good. Secondly, the packet is not limited to a particular port, making detection more difficult. Its a simple buffer overflow, so the exploit should show up pretty soon.

The only saving part at this point is that it will unlikely be a "universal" exploit. But we may see some wide spread exploits for common architectures, in particular if pre-compiled binaries are used (Snort on Windows, Redhat, Suse).

How to protect Snort from this and future issues:

• Start by turning off unneeded components at compile time. Do you need all the database plugins? Sure, you can turn them off later. But if its not compiled, it can't be turned on by mistake.
  
• Review the snort.conf file. If you don't need a pre-processor or an output component, turn it off. The less "crap" you have turned on, the less likely you will get hit.
• Run snort as a non-root user. If you still get "hit", at least the damage is limited.
• Run snort in a chroot jail. This takes a couple minutes to setup, but its not terribly hard.
• Your sensor does not need an IP address. Sure, a single UDP packet will still launch an exploit. But the ability to follow up on a remote/reverse shell are restricted.
• Harden the system. On Linux, use things like grsecurity or SELinux to further harden the system.
• Use remote logging. This way, if the snort box gets 'whacked', you at least got all your logs up to that point.
• Monitor the sensor. Sounds like overkill... but for starters: If your snort box doesn't send any alerts for a day, either your network is down or your sensor is dead.