[14800] in bugtraq
Re: Denial of service attack against tcpdump
daemon@ATHENA.MIT.EDU (antirez)
Sat May 6 15:31:10 2000
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-Id: <20000503203952.D306@nagash.marmoc.net>
Date: Wed, 3 May 2000 20:39:52 +0200
Reply-To: antirez@linuxcare.com
From: antirez <antirez@LINUXCARE.COM>
X-To: bretonh@PARANOIA.PGCI.CA
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <Pine.SOL.4.10.10005021942380.2077-100000@paranoia.pgci.ca>; from
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.
