bisonware.ftp.txt

1999-08-17T00:00:00
ID PACKETSTORM:11860
Type packetstorm
Reporter Packet Storm
Modified 1999-08-17T00:00:00

Description

                                        
                                            `Date: Mon, 17 May 1999 12:52:02 -0400  
From: Russ <Russ.Cooper@RC.ON.CA>  
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM  
Subject: Vulnerabilities in BisonWare FTP Server 3.5  
  
Arne Vidstrom submitted the following observations regarding BisonWare  
FTP Server 3.5. I contacted the authors of BisonWare and gave them a  
copy of Arne's message. After each of Arne's observations I include the  
response from BisonWare's Nick Barnes sent back to me.  
  
If you respond to this message, please ensure you're responding to Arne,  
Nick, and/or the NTBugtraq list (as opposed to responding to me).  
  
Cheers,  
Russ - NTBugtraq Editor  
  
AV=Arne Vidstrom (winnt@BAHNHOF.SE - May 8th, 1999)  
NB=Nick Barnes (nick_barnes@compuserve.com - May 16th, 1999)  
  
AV  
>Hi everybody,  
>  
>I've found a few vulnerabilities in BisonWare FTP Server 3.5 (latest  
>version). Perhaps they are already know, but here they are:  
>  
>1) The server doesn't close the old socket from the last PASV command  
>when given a new PASV command. Thus, it runs out of buffer space if you  
>give lots of PASV commands in a row. Finally, you can't use the server,  
>and it consumes lot's of memory that isn't released when the client  
>disconnects.  
  
NB  
>1. Fixed in release 4.1 due out in the next 10 days.  
  
AV  
>2) If you log in and give the command "PORT a", and then press Enter  
>a few thousand times in a row, the server will crash because it can't  
>handle a non-numeric character after PORT and somehow adds all the  
>CRLF's to the PORT command in a buffer that seems to overflow.  
  
NB  
>2. Fixed in release 4.1  
  
AV  
>3) There are buffer overflows for commands that take arguments, for  
>example LIST xxxx (1500 characters) and CWD xxx (1500 characters) will  
>crash it. This works for the USER command too, so an attacker won't  
>need a valid account to crash the server.  
  
NB  
>3. Fixed in release 4.1  
  
AV  
>4) The account passwords are stored in plaintext in the registry, at  
>HKEY_CURRENT_USER\Software\BisonWare\BisonFTP3\Users and are also  
>shown when you manage users in the server. They are also added to the  
>logs when users log in, depending on how you configure logging. So  
>don't put your logs in a directory that can be viewed by FTP users. ;)  
  
NB  
>4. Fixed in release 4.1. Passwords will still be stored plain within  
>the registry. The registry should only ever be available to the  
>administrator, and some large corporate clients use there own software  
>to build user lists.  
  
AV  
>5) Another point is that after default installation, an anonymous user  
>can access everything in your computer because you have to set the  
>limitations after installation. You can't really count that as a bug I  
>guess, but it's really dangerous anyway... so if you run this server,  
>make sure you reconfigure it if you haven't already!!!  
  
NB  
>5. This isn't really a bug from our point of view. The whole point is  
>to allow FTP operation immediately after install. This is a selling  
>advantage over competitive products which require lots of set up before  
>you can use them with a client such as your browser.  
  
`