Bugzilla Bug 100423

net-ftp/ftp .17r3 uses getpass() from pwd.h which is obsolete and should not be
used according to man pages (man 3 getpass). When entering a password after
supplying the PASS command, it prompts for "Password:". After entering,
2000-4000 bytes of letters or any data the buffer is overflowed. Since this is
just an ftp client the buffer overflow doesn't really matter since no privilege
can be gained.

Reproducible: Always
Steps to Reproduce:
1. Run /usr/bin/ftp. 
2. Connect to any server.
3. Input any username.
4. Input large password. (2000-4000+ bytes)

Actual Results:  
The ftp client crashes: "Segmentation fault" since the EIP register is
overwritten  by any characters I submitted. So if EIP was overwritten with AAAA,
it would try to read 0x41414141 which it cannot read.

Expected Results:  
It should have submitted the password to the ftp server instead of crashing.

can i get a 2nd set of eyes to look this over ?  the error isnt in the password
handling, it's in the generic command handling

when ftp is built with ssl support, the command() function in ftp.c is modified
to include a static stack buffer of 2048 bytes and then writes to it with
vsprintf() ... so if the user does something like:
PASS <3000 characters>
ftp poops all over itself

the part that i'd like double checked is that the recvrequest() function also
calls the command() function ... i want to make sure that a remote server cannot
send a really long buffer and have it processed by the command() function

and along those same lines, command() should never be passed a string buffer
from a remote server since command() processes it with vsprintf() so we wouldnt
want the server to be able to shove a %n in our mouth

(In reply to comment #1)
> can i get a 2nd set of eyes to look this over ?  the error isnt in the password
> handling, it's in the generic command handling
> 
> when ftp is built with ssl support, the command() function in ftp.c is modified
> to include a static stack buffer of 2048 bytes and then writes to it with
> vsprintf() ... so if the user does something like:
> PASS <3000 characters>
> ftp poops all over itself
> 
> the part that i'd like double checked is that the recvrequest() function also
> calls the command() function ... i want to make sure that a remote server cannot
> send a really long buffer and have it processed by the command() function

Indeed, it is bad; I ran emerge --fetchonly ftp, got the source package to
.17r3, but I didn't find where the buffer is initialized to 2048 bytes in ftp.c.
Have you tried contacting the Netkit developers? They would probably have more
insight to this.

netkit-* packages are dead upstream pretty much

this buffer comes from a ssl patch we use in Gentoo, it isnt in the original
netkit-ftp package

initializing the buffer is not a problem ... it's written to in command()
everytime ... the problem is that there arent any bounds checking done on the
input that is written to it

This should be a little more audited before we release a patch. Setting to
Auditing.

I checked every call to command(), I dont think it's possible for a server to 
overflow that buffer, or initiate a format string attack. I guess this is just a 
regular non-security bug.

thanks Tavis, i'll just revbump it as such

0.17-r5 now in portage with buffer len checks