bugtraq - Re: iDEFENSE Security Advisory 03.28.05: Multiple Telnet Client slc_add

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20050329023524.00915930.gael.delalleau+moz@m4x.org>
Date: Tue, 29 Mar 2005 02:35:24 +0200
From: =?ISO-8859-1?Q? "Ga=EBl?= Delalleau" <gael.delalleau+moz@....org>
To: bugtraq@...urityfocus.com
Cc: Solar Designer <solar@...nwall.com>
Subject: Re: iDEFENSE Security Advisory 03.28.05: Multiple Telnet Client
 slc_add_reply() Buffer Overflow Vulnerability


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@...nwall.com> 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