Vulnerability

    tcpdump

Affected

    Systems running tcpdump

Description

    Hugo Breton found  following.  There  is a way  to disable tcpdump
    running on  a remote  host.   By sending  a carefully  crafted UDP
    packet  on  the  network  which  tcpdump monitors, it is possible,
    under  certain  circonstances,  to  make  tcpdump  fall  into   an
    infinite loop.  This undesired behaviour has serious  consequences
    for any intrusion detection system or any other network monitoring
    program which relies on tcpdump's output.

    tcpdump interprets UDP packet from  or to port 53 as  DNS traffic.
    Consequently, tcpdump  attempts to  retreive information  (such as
    domain names in this case) in DNS queries and replies and  display
    it.   However,  domain  names  in  DNS  packets  use a compression
    scheme to avoid multiple occurences  of a domain name in  the same
    packet.   This scheme  uses jumps  to a  particular offset  in the
    packet.

    If this jump offset  is set to its  own location and if  a program
    trying to  decompress the  domain name  does not  have any type of
    counter  or  strategy  to  avoid  infinite loops, then the program
    will jump to the  same offset in the  packet over and over  again.
    Here is an example of it:

        [bretonh@pgci.ca] # /usr/local/sbin/tcpdump
        tcpdump: listening on hme0
        --- usual traffic
        --- dnsloop.c is run somewhere with paranoia.pgci.ca as target
        18:44:50.985686 some-host-on-the-internet.port > paranoia.pgci.ca.domain: 61094 A?

    tcpdump is now disabled, and  any program requiring its output  to
    detect DoS attacks or to monitor the network in any other  fashion
    is now out of order.

    The dnsloop.c program can be obtained at

        ftp://ftp.pgci.ca/pub/tcpdump_tools/dnsloop.c

    It must be mentionned that tcpdump running in quiet mode will  not
    try to interpret DNS traffic  and is therefore unaffected by  this
    problem.  Also, if tcpdump  writes the output directly to  a file,
    the problem will  not appear while  collecting packets, but  while
    displaying them.

    As an example of this, the SHADOW IDS is composed of a sensor part
    which only collects  packets and writes  them directly in  a file.
    This bug will not affect the sensor.  However, the analyzer module
    runs  these  packets  through  tcpdump  afterwards  and just might
    experience problems if it encounters this type of DNS loop  attack
    (although correct  me if  I'm wrong  about the  inner workings  of
    SHADOW).

    There are several other methods  to take tcpdump down, two  others
    with  domain  names  (zlip*.c)  and  one  with  IP  header  length
    fiddling.

Solution

    A fix for this is in the current tcpdump CVS tree at

        http://www.tcpdump.org

    but it doesn't appear  to be in the  3.5 alpha release.   This has
    also been fixed in the latest version of Ethereal (0.8.7).