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
> 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
[ reply ]