[6020] in bugtraq
Re: Solaris ftpd D.O.S.
daemon@ATHENA.MIT.EDU (Casper Dik)
Tue Jan 20 17:08:46 1998
Date: Tue, 20 Jan 1998 22:15:06 +0100
Reply-To: Casper Dik <casper@HOLLAND.SUN.COM>
From: Casper Dik <casper@HOLLAND.SUN.COM>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: Your message of "Tue, 20 Jan 1998 12:31:22 +0200."
<199801201031.MAA02028@cc.ece.ntua.gr>
>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.
The simple truth is that the Solaris FTP server tries to be clever about
handlign telnet options in the FTP command channel; unfortunately, the
code has a bad bug, as you have noticed.
Casper
