5060288 2000-05-03 20:06 /118 rader/ Postmaster
Mottagare: Bugtraq (import) <10720>
Ärende: Denial of service attack against tcpdump
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: bugtraq@securityfocus.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID: <Pine.SOL.4.10.10005021942380.2077-100000@paranoia.pgci.ca>
Date: Tue, 2 May 2000 19:46:33 -0400
Reply-To: bretonh@PARANOIA.PGCI.CA
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: bretonh@PARANOIA.PGCI.CA
X-To: bugtraq@securityfocus.com
To: BUGTRAQ@SECURITYFOCUS.COM
Greetings.
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).
This problem can be fixed by adding a counter in the loop of the
ns_print() function in print-domain.c to stop printing a domain name
once X loops have been done. Here is a new ns_print() function that
fixes this problem:
static const u_char *
ns_nprint(register const u_char *cp, register const u_char *bp)
{
register u_int i,j;
register const u_char *rp;
register int compress;
i = *cp++;
j = 0;
rp = cp + i;
if ((i & INDIR_MASK) == INDIR_MASK) {
rp = cp + 1;
compress = 1;
} else
compress = 0;
if (i != 0)
while ((i && cp < snapend) && (j<256)) {
j++;
if ((i & INDIR_MASK) == INDIR_MASK) {
cp = bp + (((i << 8) | *cp) & 0x3fff);
i = *cp++;
continue;
}
if (fn_printn(cp, i, snapend))
break;
cp += i;
putchar('.');
i = *cp++;
if (!compress)
rp += i + 1;
}
else
putchar('.');
return (rp);
}
Only the "j" variable was added. The 256 jump limit is discutable,
but this is only my humble suggestion of a temporary fix.
One might wonder, however, if this type of bug could also be present
in other software that also extracts domain names from UDP packets
containing DNS queries or reply. I would suggest anyone running
software that inspects contents of DNS traffic to test themselves
against this.
Cheers,
Hugo Breton
bretonh@pgci.ca
(5060288) ------------------------------------------(Ombruten)
5068375 2000-05-06 20:37 /71 rader/ Postmaster
Mottagare: Bugtraq (import) <10749>
Ärende: Re: Denial of service attack against tcpdump
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
Content-Type: text/plain
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-ID: <0005031349321B.00340@kyxbot.zorg>
Date: Wed, 3 May 2000 13:28:25 -0700
Reply-To: Dragos Ruiu <dr@DURSEC.COM>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Dragos Ruiu <dr@DURSEC.COM>
Organization: kyx.net
X-To: bretonh@PARANOIA.PGCI.CA, bretonh@PARANOIA.PGCI.CA
BUGTRAQ@SECURITYFOCUS.COM To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To:
<Pine.SOL.4.10.10005021942380.2077-100000@paranoia.pgci.ca>
On Tue, 02 May 2000, bretonh@PARANOIA.PGCI.CA wrote:
> 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.
>
> 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.
>
This all points to another reason to always run tcpdump with "tcpdump
-n" err... quiet mode as you called it.
Another serious drawback to allowing tcpdump (or any sniffer as a
matter of fact) to look up DNS addresses is that it allows evil
haxors to immediately identify the security machines/probes on the
network by either passive monitoring and detection of the lookups or
by penetrating the name daemons (or the DNS server that hosts it) and
looking at the logs. DNS logs can be fascinating sources of info....
This information will immediately highlight what should be the evil
haxor's next most important target. :-)
There are some sniff type programs (ntop and iptraf from memory) that
implement a separate thread/proc to do the DNS lookups and cache some
of the results. This can be a way to mitigate the security machine
DNS "beaconing" to a degree, but they are still vulnerable to the
following sniffer detection algorithm:
1. Inject packet to strangedest.net
2. Look for any machine doing a DNS lookup to strangedest.net
This is particulalry useful if you already control strangedest.net.
The moral of the story is that where tcpdump is concerned "-n" is
a very nice option.
cheers,
--dr
--
dursec.com / kyx.net - we're from the future http://www.dursec.com
learn kanga-foo from security experts: CanSecWest - May 10-12 Vancouver
Speakers: Ron Gula/NSW, Ken Williams/E&Y, Marty Roesch/Hiverworld,
Fyodor/insecure.org, RainForestPuppy/wiretrip.net, Theo de Raadt/OpenBSD
Lance Spitzner/Sun, Fyodor Yarochkin/KALUG, Max
Vision/whitehats.com
(5068375) ------------------------------------------(Ombruten)
5068597 2000-05-06 21:31 /54 rader/ Postmaster
Mottagare: Bugtraq (import) <10752>
Ärende: Re: Denial of service attack against tcpdump
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: bugtraq@SECURITYFOCUS.COM
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.1.12i
Message-ID: <20000503203952.D306@nagash.marmoc.net>
Date: Wed, 3 May 2000 20:39:52 +0200
Reply-To: antirez@linuxcare.com
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: antirez <antirez@linuxcare.com>
X-To: bretonh@PARANOIA.PGCI.CA
X-cc: bugtraq@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <Pine.SOL.4.10.10005021942380.2077-100000@paranoia.pgci.ca>; fro
bretonh@PARANOIA.PGCI.CA on Tue, May 02, 2000 at 07:46:33PM -0400
On Tue, May 02, 2000 at 07:46:33PM -0400, bretonh@PARANOIA.PGCI.CA wrote:
> There is a way to disable tcpdump running on a remote host. By sending a
This isn't new, check:
http://www.securityfocus.com/templates/archive.pike?list=1&date=1999-06-1&msg=Pine.LNX.4.05.9905301511370.9647-101000@nb.in-berlin.de
> 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.
Yep: since the DNS name compression does NOT allows to point to some
offset that contain pointers the fix is really simple.
> Only the "j" variable was added. The 256 jump limit is discutable, but this is
> only my humble suggestion of a temporary fix.
256 jumps are not allowed, a name can contain a pointer to some offset
with nul-terminated labels (RFC1035).
> One might wonder, however, if this type of bug could also be present in
> other software that also extracts domain names from UDP packets containing
> DNS queries or reply. I would suggest anyone running software that inspects
> contents of DNS traffic to test themselves against this.
Sebastian reported tcpdump vulnerable, Etherreal vulnerable, bind not
vulnerable, but the posting is dated "Sun May 30 1999 15:32:58".
regards,
antirez
--
Salvatore Sanfilippo, Open Source Developer, Linuxcare Italia spa
+39.049.8024648 tel, +39.049.8036484 fax
antirez@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.
(5068597) ------------------------------------------(Ombruten)
5068665 2000-05-06 21:46 /27 rader/ Postmaster
Mottagare: Bugtraq (import) <10756>
Ärende: Re: Denial of service attack against tcpdump
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID: <Pine.LNX.4.10.10005032204250.5606-100000@pow.zing.org>
Date: Wed, 3 May 2000 22:15:13 -0500
Reply-To: Gerald Combs <gerald@ZING.ORG>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Gerald Combs <gerald@ZING.ORG>
X-To: bretonh@PARANOIA.PGCI.CA
X-cc: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <Pine.SOL.4.10.10005021942380.2077-100000@paranoia.pgci.ca>
On Tue, 2 May 2000 bretonh@PARANOIA.PGCI.CA wrote:
> Greetings.
>
> 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.
A fix for this is in the current tcpdump CVS tree at 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).
(5068665) ------------------------------------------(Ombruten)
5068889 2000-05-06 23:51 /75 rader/ Postmaster
Mottagare: Bugtraq (import) <10770>
Ärende: Fwd: tcpdump workaround against dnsloop exploit.
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
Content-Type: text/plain
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-ID: <00050317325100.00442@sQa.speedbros.org>
Date: Wed, 3 May 2000 17:32:26 -0500
Reply-To: THE INFAMOUS <evil7@BELLSOUTH.NET>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: THE INFAMOUS <evil7@BELLSOUTH.NET>
X-To: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
---------- Forwarded Message ----------
Subject: tcpdump workaround against dnsloop exploit.
Date: 04 May 2000 00:32:22 +0200
From: yoann@mandrakesoft.com
Hi,
Here is my patch to tcpdump against the dnsloop exploit... I have
really no knowledge of the dns internal at all, so this is probably
not ( and this is not ) the good way of preventing this.
However, it work against this attack,
but i hope it doesn't break anything for the printing of compressed
domain name.
Please remember, this is only a workaround
and might break the printing of compressed domain name in tcpdump.
--- print-domain.orig Wed May 3 23:33:13 2000
+++ print-domain.c Thu May 4 00:22:05 2000
@@ -150,6 +150,7 @@
{
register u_int i;
register const u_char *rp;
+ register const u_char *old = NULL;
register int compress;
i = *cp++;
@@ -162,8 +163,17 @@
if (i != 0)
while (i && cp < snapend) {
if ((i & INDIR_MASK) == INDIR_MASK) {
- cp = bp + (((i << 8) | *cp) & 0x3fff);
- i = *cp++;
+ cp = bp + (((i << 8) | *cp) & 0x3fff);
+
+ /*
+ * If we got two time the same data ptr,
+ * this mean we are looping.
+ */
+ if ( cp == old)
+ return NULL;
+ old = cp;
+
+ i = *cp++;
continue;
}
if (fn_printn(cp, i, snapend))
--
-- Yoann http://www.mandrakesoft.com/~yoann/
It is well known that M$ product don't make a free() after a
malloc(), the unix community wish them good luck for their future
developement.
-------------------------------------------------------
-- Bryan Microsoft - Bringing you yesterdays technology today and
breaking it along the way...
(5068889) ------------------------------------------(Ombruten)
5071044 2000-05-07 21:46 /40 rader/ Postmaster
Mottagare: Bugtraq (import) <10776>
Ärende: Re: Denial of service attack against tcpdump
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
X-Sun-Charset: US-ASCII
Message-ID: <200005071529.LAA13489@obelix.dgrc.crc.ca>
Date: Sun, 7 May 2000 11:29:04 -0400
Reply-To: Donald McLachlan <don@MAINFRAME.DGRC.CRC.CA>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Donald McLachlan <don@MAINFRAME.DGRC.CRC.CA>
X-To: BUGTRAQ@SECURITYFOCUS.COM, dr@DURSEC.COM
To: BUGTRAQ@SECURITYFOCUS.COM
It is not the -n option which defeats dnsloop.c, but the -q option.
running:
> tcpdump -n host XXX
tcpdump: listening on hme0
and then from host XXX running dnsloop against that host:
./dnsloop YYYY
dnsloop.c by Hugo Breton (bretonh@pgci.ca)
packet sent to host YYYY
tcpdump reports:
11:23:33.553624 142.92.38.51.35520 > 142.92.38.223.53: 61094 A?
and is hung. When they say quiet mode, that means with the -q option.
when run with the -q option tcpdump reports:
11:26:16.417969 XXX.35521 > YYYY.domain: udp 18 (DF)
and does not hang. Problem is you loose most of the useful TCP
decoding. Note the lack of TCP flags, ack and window info.
11:26:15.053723 YYYY.1022 > XXX.login: tcp 1 (DF)
11:26:15.054333 XXX.login > YYYY.1022: tcp 1 (DF)
Don
(5071044) ------------------------------------------(Ombruten)
5071118 2000-05-07 22:25 /48 rader/ Postmaster
Mottagare: Bugtraq (import) <10778>
Ärende: Re: Denial of service attack against tcpdump
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: bugtraq@securityfocus.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID: <Pine.SOL.4.10.10005061516320.11232-100000@paranoia.pgci.ca>
Date: Sat, 6 May 2000 15:46:01 -0400
Reply-To: bretonh@PARANOIA.PGCI.CA
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: bretonh@PARANOIA.PGCI.CA
X-To: dr@dursec.com
X-cc: bugtraq@securityfocus.com
To: BUGTRAQ@SECURITYFOCUS.COM
On Sat, 06 May 2000, dr@dursec.com wrote:
>This all points to another reason to always run tcpdump with "tcpdump -n"
err...
>quiet mode as you called it.
...
>The moral of the story is that where tcpdump is concerned "-n" is
>a very nice option.
I agree that "-n" is a very nice option, but I must point out that it
will *not* fix this problem. The only way to make tcpdump not print
out the domain names in DNS queries and answers is to use the quiet
output mode which is the "-q" option (of course, you can modify the
sources, but then why wouldn't you fix the bug while you're at it?).
The "-n" option is only to stop tcpdump from resolving IP addresses
in the IP header.
The "-q" option, however, does not print out much information: you
don't get to see TCP flags, some protocol options, etc... It is also
worth mentionning that this should really be fixed, because even if
your tcpdump filter tries not to target UDP datagrams, someone
wanting to disable your tcpdump could make it try to display the
packet by exploiting your filter expression: let's say your on the
lookout for "smurf attacks" and are using a filter containing
"ip[19]=255", if someone sends out a DNS query containing a loop to
an address like X.X.X.255, tcpdump will try to read the domain name
and will fall into an infinite loop.
Cheers,
Hugo Breton
bretonh@pgci.ca
(5071118) ------------------------------------------(Ombruten)
5071180 2000-05-07 22:47 /32 rader/ Postmaster
Mottagare: Bugtraq (import) <10782>
Ärende: Re: tcpdump workaround against dnsloop exploit.
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4029.2901
Message-ID: <000001bfb7a8$3a0ea410$021d85d1@youwant.to>
Date: Sat, 6 May 2000 15:12:54 -0700
Reply-To: David Schwartz <davids@WEBMASTER.COM>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: David Schwartz <davids@WEBMASTER.COM>
X-To: THE INFAMOUS <evil7@BELLSOUTH.NET>, BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <00050317325100.00442@sQa.speedbros.org>
This won't work. It stops an A->A->A loop but allows an
A->B->A->B loop. What you want is something more like:
> + /*
> + * If we got two time the same data ptr,
> + * or are being referred forward,
> + * this means we may loop.
> + */
> + if ( cp >= old)
> + return NULL;
> + old = cp;
DS
(5071180) ------------------------------------------(Ombruten)
5071202 2000-05-07 22:56 /52 rader/ Postmaster
Mottagare: Bugtraq (import) <10783>
Ärende: Re: Fwd: tcpdump workaround against dnsloop exploit.
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID: <20000507120112.B24189@nb.in-berlin.de>
Date: Sun, 7 May 2000 12:01:12 +0200
Reply-To: Sebastian <scut@NB.IN-BERLIN.DE>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Sebastian <scut@NB.IN-BERLIN.DE>
X-To: THE INFAMOUS <evil7@BELLSOUTH.NET>
X-cc: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <00050317325100.00442@sQa.speedbros.org>; fro
evil7@BELLSOUTH.NET on Wed, May 03, 2000 at 05:32:26PM -0500
On Wed, May 03, 2000 at 05:32:26PM -0500, THE INFAMOUS wrote:
> Hi,
Hi.
> Here is my patch to tcpdump against the dnsloop exploit...
> I have really no knowledge of the dns internal at all,
> so this is probably not ( and this is not ) the good way of preventing this.
It prevents only the "jump-on-itself" type of attack, but it leaves
the decoder still vulnerable to other type of compression attacks
where more then one label is involved. The only secure way is to use
a label counter such as in the BIND decompression routines.
> + /*
> + * If we got two time the same data ptr,
> + * this mean we are looping.
> + */
> + if ( cp == old)
> + return NULL;
> + old = cp;
Imagine something like:
alabel<pointer-ahead-to-b-label>blabel<pointer-to-a-label>
ciao,
scut
--
- scut@nb.in-berlin.de - http://nb.in-berlin.de/scut/ --- you don't
need a --
-- lot of people to be great, you need a few great to be the best ------------
http://3261000594/scut/pgp - 5453 AC95 1E02 FDA7 50D2 A42D 427E 6DEF 745A 8E07
-- data in VK/USA Mayfly experienced, awaiting transfer location, hi
echelon -
(5071202) ------------------------------------------(Ombruten)