When the in.ftpd was left in this "hung" state, I did a "truss -p",
which revealed that ftpd keeps on read(2)ing zero bytes from the
network socket in a tight loop, hence the CPU time consumed. The
most plausible scenario (without any kind of access to the source
code) is that the client telnet, when receiving SIGINT/QUIT, creates
an "exception" condition in the receiving socket, which is not
examined as it should by ftpd. The next kill is bogus, you might
just as well shut down the telnet connection (^]-close - tried it
out successfully). It just creates an EOF condition on ftpd's input,
which is not handled appropriately.
The whole thing is that telnet is able to relay the INT/QUIT signals
whereas the ftp client is not. Such bugs may exist in all TELNET-
based protocol servers.
Anyway, it should be pretty easy for Sun to fix, nah?
a.varvitsiotis@iccs.ntua.gr A.Varvitsiotis
ICCS Computer Center
National Technical University of Athens
> Hi,
>
> 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