On Wed, May 29, 2002 at 08:14:18AM -0500, David Frascone wrote:
> I'm forwarding this because it mentions buffer overflows in libpcap, which
> would impact ethereal too.
Unfortunately, what it *doesn't* mention is the SRPM for libpcap; I
guess they didn't consider that Important Enough:
> Additionally to the fixed tcpdump packages we provide new libpcap
> packages. Libpcap on which most network monitoring programs rely also
> contained overflows which however are only exploitable by local attackers
> if you installed programs using libpcap setuid. This is not found in a
> default install.
However, I did find
ftp://ftp.suse.com/pub/suse/i386/update/8.0/zq1/libpcap-0.6.2-241.src.rpm
with the same modification date as the equivalent tcpdump SRPM; the
fixes consist of
1) a change to "pcap-bpf.c" that would only fix a buffer
overflow if your system had more than 2^31 "/dev/bpf" devices
and all of them were busy (the buffer's big enough to hold
2^32-1 as a decimal string, but not big enough to hold -2^31
as a decimal string, and the device name is generated with
"/dev/bpf%d" not "/dev/bpf%u");
2) a change to "pcap-linux.c" to discard unread packets when the
kernel packet filter is changed (0.7.1 does that as well);
and the "libpcap-0.6.2.tar.bz2" file in the SRPM contains the same stuff
as the "libpcap-0.6.2.tar.gz" from tcpdump.org, so I'm not sure what
real-world overflows they fixed, unless part of the "new package" was an
upgrade from some other version of libpcap, with buffer overflows, to
0.6.2.
(The tcpdump buffer-overflow fixes are largely ones that are already in
tcpdump 3.7.1; it may be that there aren't *any* buffer-overflow fixes
not in 3.7.1, and that the other changes in there are for other issues,
e.g. a change to show the RPC program as a number rather than a name if
the name would be truncated by "strlcpy()"ing it to the buffer - i.e.,
it doesn't prevent a buffer overflow, it just shows the RPC program as a
number rather than a safely-truncated name.)
