[Snort-users] Can snort suffer from buffer overflows like tcpdump did?
kris at ...1402...
Fri Mar 2 03:44:18 EST 2001
On Thu, Mar 01, 2001 at 10:27:06AM +1300, Jason Haar wrote:
> Says it all really. Such nasty events have hit several sniffers in the past
> year, so I'm wondering how susceptible snort is to them.
The tcpdump bugs I found (which also turned up in ethereal due to
shared code) were to do with packet decoding. I hope snort fares
better in this regard, but I haven't checked personally. You are
correct that the potential problem extends beyond snort itself and may
affect other snort postprocessors, etc -- but given how snort works I
think the risk is less: by this I mean that it doesn't attempt to
decode bits of the protocol stream to present to the user, it just
matches and classifies packets. The tcpdump problems were due to an
attempt to extract bits of the packet, interpret them against a model
of the protocol (with bad assumptions, in some cases, which was the
cause of the problems) and munge them into an interpreted format for
the user. Snort doesn't seem to do this (as much).
> As a safety measure, if I ran snort chroot'ed as a non-root account, what
> would a snort exploit gain the hacker? If they end up dumping opcodes
> on the snort server, running as usercode "snort", under a chrooted
> directory, they wouldn't be capable of much anyway, would they?
Depends whether your OS allows a way to break out of the chroot.
Generally speaking, if you can get root inside a chroot you can break
out, and there may be other ways (most OSes have probably fixed these
by now though). Kernel bugs may allow privilege escalation even if
there are no setuid applications inside the chroot. There have been a
number of vulnerabilities of this type over the past year on various
popular operating systems.
A more comprehensive jail environment is provided by jail(8) on
FreeBSD - it isolates processes inside their own virtual machine;
network and process visibility are compartmented from the main system,
not just filesystem visibility (which is all chroot attempts). The
kernel bug comment also applies, but it's generally much more robust
for security -- you can quite safely give out root within the jail,
and they can't break out of it or transcend the virtual machine
restrictions (modulo, of course, bugs in the implementation, which are
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 230 bytes
Desc: not available
More information about the Snort-users