[tcpdump-workers] Bug in print_unknown_data() + fuzz testing script
We recently added fuzz testing to Ethereal's automated build system. I
tried out the script we're using on tcpdump and it turned up a bug in
util.c. Attached are:
- A patch for util.c:print_unknown_data() that makes sure a negative
length isn't passed to hex_print().
- A capture file that triggers the bug in the current daily build.
- The fuzz testing script that created the capture. It is based on
"fuzz-test.sh" from the Ethereal distribution and requires a recent
version of editcap.
--- ../tcpdump-2005.06.09.orig/util.c 2005-05-06 03:26:45.0 -0500
+++ util.c 2005-06-12 14:04:13.520867529 -0500
@@ -244,6 +244,8 @@
{
if (snapend - cp < len)
len = snapend - cp;
+ if (len < 0)
+ return(0); /* XXX - Should we print an error here? */
hex_print(ident,cp,len);
return(1); /* everything is ok */
}
#!/bin/bash
#
# $Id$
# Fuzz testing script for tcpdump
#
# By Gerald Combs <[EMAIL PROTECTED]> and Ulf Lamping <[EMAIL PROTECTED]>
#
# This script uses Ethereal's Editcap utility to add random errors
# ("fuzz") to a set of capture files specified on the command line.
# It runs tcpdump on each fuzzed file and checks for errors. The
# files are processed repeatedly until an error is found.
# Tweak the following to your liking. Editcap must support "-E".
# This feature is present in Ethereal 0.10.11 and later.
TCPDUMP=./tcpdump
EDITCAP=editcap
CAPINFOS=capinfos
# This needs to point to a 'date' that supports %s.
DATE=/bin/date
# Where our temp files are saved (editcap.out and stderr.out)
# Cygwin user may wish to use "TMP_DIR=./".
TMP_DIR=/tmp
# These may be set to your liking
# Stop the child process, if it's running longer than x seconds
MAX_CPU_TIME=900
# Stop the child process, if it's using more than y * 1024 bytes
MAX_VMEM=50
# Insert z times an error into the capture file (0.02 seems to be a
# good value to find errors)
ERR_PROB=0.02
# set some limits to the child processes, e.g. stop it if it's running
# longer then MAX_CPU_TIME seconds
# (ulimit is not supported well on cygwin and probably other platforms,
# e.g. cygwin shows some warnings)
ulimit -S -t $MAX_CPU_TIME -v $MAX_VMEM
### usually you won't have to change anything below this line ###
# Tcpdump arguments (you won't have to change these)
# vvv Maximum verbosity
# n Disable network object name resolution
# r Read packet data from the following infile
TCPDUMP_ARGS="-vvv -nr"
# Make sure we have a valid test set
FOUND=0
for CF in "$@" ; do
"$CAPINFOS" "$CF" > /dev/null 2>&1 && FOUND=1
if [ $FOUND -eq 1 ] ; then break ; fi
done
if [ $FOUND -eq 0 ] ; then
cat < /dev/null 2>&1
if [ $? -ne 0 ] ; then
echo "Not a valid capture file"
continue
fi
DISSECTOR_BUG=0
"$EDITCAP" -E $ERR_PROB "$CF" $TMP_DIR/editcap.out > /dev/null 2>&1
if [ $? -ne 0 ] ; then
"$EDITCAP" -E $ERR_PROB -T ether "$CF" $TMP_DIR/editcap.out >
/dev/null 2>&1
if [ $? -ne 0 ] ; then
echo "Invalid format for editcap"
continue
fi
fi
"$TCPDUMP" $TCPDUMP_ARGS $TMP_DIR/editcap.out \
> /dev/null 2> $TMP_DIR/stderr.out
RETVAL=$?
grep -i "dissector bug" $TMP_DIR/stderr.out \
> /dev/null 2>&1 && DISSECTOR_BUG=1
# XXX - Tcpdump had trouble reading some files that editcap generated.
# We need to handle this better than checking for a return value > 1.
if [ $RETVAL -gt 1 -o $DISSECTOR_BUG -ne 0 ] ; then
SECS=`$DATE +%s`
echo " ERROR"
echo -e "Processing failed. Capture info follows:\n"
mv $TMP_DIR/editcap.out $TMP_DIR/editcap.$SECS.pcap
echo " Output file: $TMP_DIR/editcap.$SECS.pcap"
if [ $DISSECTOR_BUG -ne 0 ] ; then
echo -e "stderr follows:\n"
cat $TMP_DIR/stderr.out
fi
exit 1
fi
echo " OK"
done
done
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Bug in print_unknown_data() + fuzz testing
Guy Harris wrote: > Gerald Combs wrote: >> - A capture file that triggers the bug in the current daily build. > > > That wasn't attached. Do you either have the capture, or a stack trace? > I'm curious whether the problem is that it's being handed a negative > length, or being handed a pointer past the end of the snapshot length. Weird. The message in my "Sent" mailbox says it was attached, but it didn't show up at http://marc.theaimsgroup.com/?l=tcpdump-workers&m=111863605903207&w=2 either. It's attached to this message and is also available at http://www.ethereal.com/~gerald/lcp-crash.pcap . - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Bug in print_unknown_data() + fuzz testing
Guy Harris wrote: > It doesn't appear to have gotten attached. Weird. It works fine when I send it to my gmail account. Do attachments get stripped at the lists.tcpdump.org end? > OK, got it. I've checked in a fix for the underlying problem, and > audited the calls to "print_unknown_data()" and checked in other fixes. > > Along the lines of the "dissector bug" stuff in Ethereal, I've also > checked in a change to util.c to add checks for a negative "len" value, > where they print a noisy "Dissector bug" message (so that a bad packet > won't crash tcpdump). Thanks. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap files with file header snaplen < packet
Harley Stenzel wrote: > Looking forward, however, it would be helpful if the libpcap file > format provided a way to tag the source of the captured packet, so > that merged files do not loose information. NTAR supports this: http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html#sectionpb - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Capturing without having superuser rights
Under Linux you can use POSIX capabilities to capture as non-root. CAP_NET_RAW lets you capture, and CAP_NET_ADMIN lets you use promiscuous mode. Damien ANCELIN wrote: > To give you more informations : > - "metrology platform" will be a computer that can be used by many users > to capture packets (coming from a mirroring port of a switch). > - It's currently running on an linux debian. > > It seems there is no common manner to do this in a simple way (I will > have a look on that kernel patch). > > Thanks for your help > Damien > > [EMAIL PROTECTED] a écrit : As I'm developping on libpcap to provide a metrology plateform, I was wondering if there is a manner to enable a specific user (or a specific group) to capture from a network interfaces (even in promiscuous mode), without using sudo. I'm trying to do this with udev, but I'm not shure it can works. Does anybody have an idea ? >>> Depends on the platform you are on. On FreeBSD all you need is read >>> write permission to the /dev/bpf* devices. >>> >> >> And for *capturing* you really only need read permission. >> >> Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] >> - >> This is the tcpdump-workers list. >> Visit https://cod.sandelman.ca/ to unsubscribe. >> > - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] MIME type for libpcap-format capture files
Phil Vandry wrote: > Hello tcpdump-workers, > > I noticed that there does not seem to be any MIME type defined for > libpcap-format packet capture files according to the list of types > maintained by IANA: > > http://www.iana.org/assignments/media-types/ > > I couldn't find any well-known but unofficial MIME type either. It > seems there is no concensus on what the MIME type of these files > should be. Debian and Ubuntu have the following entry in /etc/mime.types: application/cap cap pcap I prefer "application/x-libpcap-capture" since it's more descriptive. Would it make sense to have an "application/x-libpcap-ng-capture" type for Pcap-NG/NTAR as well? - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] tcpdump.org mirrors
Michael Richardson wrote: >> "Michael" == Michael Richardson writes: > Michael> The data transfer of the bpf.tcpdump.org is still underway, > Michael> and should complete by morning EST. > > cvs.tcpdump.org, bpf.tcpdump.org and www.tcpdump.org are online again. > > It seems that the only mirror that works is www.at.tcpdump.org, but > alas, he isn't configured to also be www.tcpdump.org. > > Stable mirrors would be appreciated. If you still need a mirror you're welcome to use this one: Canonical URL: http://tcpdump.mirror.cacetech.com Server alias: *.tcpdump.org Location: Washington, D.C., US IPv4 address: 69.4.231.52 IPv6 address: 2607:f0d0:3001:62:1::52 Update frequency: 6 hours We're pulling from bpf.tcpdump.org using wget. Let me know if there's a more preferred method. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] nightly build package
Guy Harris wrote: > On Jan 10, 2010, at 12:06 PM, Michael Richardson wrote: > >> I was supposed to setup a master/manager program (it was in python, I >> think), that will farm out builds for various platforms to a volunteer >> pool. I've forgotten the name of this system, but it was the same one >> that wireshark uses... > > Buildbot: > > http://buildbot.net/ I created a minimal libpcap+tcpdump Buildbot configuration a few months ago: http://buildbot.wireshark.org/tcpdump/waterfall Michael, I can send you the configuration files offline if you'd like. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] non-root pcap capture under Linux
amnon cohen wrote: > Hi, > Is there anyway to capture packets without being root on Linux. > The docs imply that we running with CAP_NET_RAW will do the trick. > Has anyone managed to get this to work? > I got stuck when trying to add CAP_NET_RAW to the executable > > > # setcap cap_net_raw my_sniffer_program > fatal error: Invalid argument > usage: setcap [-q] [-v] (-r|-|) [ ... (-r|-|) > ] Try "setcap cap_net_raw,cap_net_admin=eip my_sniffer_program": http://packetlife.net/blog/2010/mar/19/sniffing-wireshark-non-root-user/ If you generate traffic you might need cap_net_broadcast as well. -- Join us for Sharkfest ’10! · Wireshark® Developer and User Conference Stanford University, June 14-17 · http://www.cacetech.com/sharkfest.10/ - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] bandwidth by user or process id
Phil Vandry wrote:
> On Mon, 4 Oct 2010 09:51:39 -0400 Rob Hasselbaum wrote:
>> Yes, it is possible (on Linux, anyway), but not extremely easy. You can
>> correlate packet data to the kernel's network connection table and network
>> connections to inode values by reading "/proc/net/tcp*" and
>
> Isn't that unreliable? The connection might be short-lived and disappear
> from /proc/net/{tc,ud}p* before you have a chance to find it.
>
> Since you are assuming Linux anyway, have you considered using iptables?
>
> If you don't have a huge number of users, you can create a rule like this
> for each uid:
>
> iptables -I OUTPUT -m owner --uid-owner -j ACCEPT
>
> and then just monitor the packet & byte counters on these rules.
You can also catch events using SystemTap's netdev.transmit and
netdev.receive probes.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] only outbound traffic
On 4/28/11 6:51 AM, Andrej van der Zee wrote: > Is there any documentation on how libpcap/tcpdump/BPF deal with VLAN > tags? Its still a bit of a mystery to me... Does this help? https://blog.wireshark.org/2009/10/capture-filters-and-offsets/ -- Join us for Sharkfest ’11! · Wireshark® Developer and User Conference Stanford University, June 13-16 · http://sharkfest.wireshark.org - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [libpcap][patch] appending to a capture
On 6/1/11 8:10 AM, Mark Johnston wrote: > Hi Darren, > > On Tue, May 31, 2011 at 03:53:22PM -0700, Darren Reed wrote: > >> You might be better off spending some time working >> on additions to editcap that include concatenating >> two or more pcap files. > > Shouldn't a function that manipulates capture files go into libpcap? I'm > not trying to solve a problem I'm having at the moment; rather, this > function has been in our tree for a long time, and I'd like to > contribute it upstream based on some interest that I saw. I'm happy to > modify it if that's what I need to do, but I think this functionality > should be in a library, not in a program. N.B. this functionality shouldn't be added to editcap either. It's already present in mergecap. -- Join us for Sharkfest ’11! · Wireshark® Developer and User Conference Stanford University, June 13-16 · http://sharkfest.wireshark.org - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] Sharkfest '11 keynote on libpcap now online
Steve McCanne spoke about the origins and architecture of libpcap and BPF at Sharkfest this year. The presentation and video are now online at http://sharkfest.wireshark.org/sharkfest.11/ under the "Keynote Video and Presentation" section. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] buildbot failure in tcpdump+libpcap on Solaris-10-SPARC
On 3/15/14 2:56 PM, François-Xavier Le Bail wrote: >> From: Guy Harris > >> On Mar 15, 2014, at 12:02 PM, Michael Richardson wrote: >> >>> I guess that this means that we also now have testing against bigendian >>> systems. thank you wireshark guys! >> >> As long as it's doing "make check" for tcpdump. >> >> Gerald, is it doing that? > > It does. see: > http://buildbot.wireshark.org/tcpdump/builders/Solaris-10-SPARC/builds/16/steps/check%20tcpdump/logs/stdio That's correct. If there are any other tests that should be run let me know. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Wireshark mirror address change
Hi, The Wireshark tcpdump mirror (http://tcpdump.mirror.wireshark.org) is moving to a new host. The new addresses are: 198.199.88.104 2604:a880:400:d0::2221:3001 I'll keep the old host up and running for the next week or so. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Re: Returned mail: Data format error
On 11/18/24 9:08 AM, Michael Richardson wrote: The message about the spam was in fact spam. But, it forged a valid From: so it got through. I'd like to fix the SPF/DKIM/spam-filter such that it more aggressively kills this kind of forgery, assuming that wireshark.org has the right policies set. This kind of thing is fraught with false-positives, but there are some reasonable howtos. wireshark.org should have valid SPF and DKIM records. If the problem is limited to my address, I can subscribe from another one and you can just block my wireshark.org address if that's easier. ___ tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
