I have not seen this peculiarity pass through here so here goes:
I have come across a bug in in.ftpd under Sun Solaris.
The bug manifests itself in in.ftpd process instance 'spinning'
i.e. consuming a lot of CPU resource.
Here's how to reproduce:
On your favourite *nix box.
$ telnet some.solaris.box.org 21
220 some FTP server (SunOS 5.6) ready.
Now get another term and look for the telnet process.
$ ps -ef | grep telnet
($ ps -aux | grep telnet for all you BSD guys :> )
Say PID was 12345
Now send it a SIGINT or SIGQUIT followed by SIGTERM.
$ kill -2 12345
$ kill 12345
At this stage in.ftpd on some.solaris.box.org starts chomping
on the CPU.
I have tested this to be the case on following Solaris variants
2.5.1 SPARC sun4u & sun4m (fully patched with latest patches in Nov/Dec 97)
2.6 SPARC sun4u & sun4m ('virgin' i.e. unpatched system)
2.6 x86 (also unpatched)
I have also had second hand reports that this happens on 2.5 SPARC as well.
Notes:
- The victim can be local or remote as long as its a Solaris box
- The originator can be pretty much any UNIX variant
(tried Solaris, FreeBSD, BSDI, IRIX, SCO, have NOT tried Linux.. anyone?)
- in.ftpd must be Sun's native. If the machine runs say wuftp
then it will not exhibit this.
I have tested that the sample FreeBSD, BSDI, IRIX & SCO system which I used
for testing were themselves not affected, so i'm assuming its only Sun's ftp server.
- The bug only seems to work at the server greet so no need to log in.
In fact it probably will not work if you do log in.
- The server implements a timeout for all connection logged in or not.
It will thereafter "clean up" its beserk in.ftpd process
- The effect is cummulative... connect 20 times like this and watch the load
skyrocket.
- I'm assuming that telnet client sends some particular sequence to the ftpd
server causing this problem or terminates the connection in some funny way.
On the victim machine the connection socket remains in CLOSE_WAIT state
while the ftpd process is spinning.
On the machine which connected the socket is in FIN_WAIT_2 state.
- To clean up the process before the server itself does it (I think timeout is
300 or 900 secs su to root and kill the in.ftpd process.
After the process is dead the socket on the victim goes to the more usual
TIME_WAIT state.
The client socket on the connecting machine disappears from netstat.
I can't think of any other use for this than a DOS attack of some sort.
Sun have been notified about this around September 97 and I havent heard back
since.
I know of no new patches that can fix this. I have been mindful of any
new kernel, streams, tcp, inetd, pam or ftpd patches since September but
there was nothing that fixed it up so far.
I guess one could always run wuftpd :]
-ldw