Hi Solar, Your interesting tests show that there is a need to provide more technical details about this overflow, to allow people to accurately evaluate the risk. You can find my initial analysis of the bug at this address: http://www.cppsecurity.com/telnet_slc_overflow.txt Main ideas: Actual exploitation depends on what (static) variables are stored just after the (static) buffer we overflow. --> Sending an overflow string is usually not enough to make the client crash or to rule out the possibility of arbitrary code execution, because the variables we corrupted may be used later only in very specific execution flows. Real-world exploitation is a _two_ stages attack. --> Thus, is your telnet client exploitable? It depends on the source code AND on the compiler. So, the only way to check it is to debug the binary, see what variables can be controlled, and try to understand how these variables can be abused by an attacker (who is able to drive the telnet client through many different, unusual, execution paths). --> I analyzed two Linux telnet clients binaries (MIT telnet and Debian Woody) and found that it is possible to overflow pointers which allows us to trigger heap corruption and other bugs later... straight road to arbitrary code execution. See the URL for details and debug outputs showing control of EIP. Hope that helps. Cheers, -- Gaël Delalleau On Tue, 29 Mar 2005 01:35:02 +0400 Solar Designer <solar@xxxxxxxxxxxx> wrote: > On Mon, Mar 28, 2005 at 01:09:38PM -0500, iDEFENSE Labs wrote: > > Multiple Telnet Client slc_add_reply() Buffer Overflow Vulnerability > > FWIW, I've been using the following one-liner to trigger this > overflow: > > perl -e 'print "\377", "\372\42\3\377\377\3\3" x 43, "\377\360"' | nc > -l 23 > > This results in 300 bytes written into the 128-byte buffer. On Owl > (telnet client derived from OpenBSD 3.0), the effect was that the > escape character ('^]') stopped working. Other than that, the client > proceeded to work as usual. Indeed, with the patch this effect is > gone. > > I've also tested this against some Red Hat Linux telnet packages > (Linux NetKit) installed on top of Owl, with the same effect. > > Gael Delalleau's more elaborate "exploit" (that's been available to > affected vendors via iDEFENSE) has the same effect on our telnet > client, but actually crashes Red Hat's telnet client builds that I've > tested. > > -- > Alexander Peslyak <solar at openwall.com> > GPG key ID: B35D3598 fp: 6429 0D7E F130 C13E C929 6447 73C3 A290 > B35D 3598 http://www.openwall.com - bringing security into open > computing environments