Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 12 Dec 2018 10:08:41 -0800
From: Hacker Fantastic <>
To: Tavis Ormandy <>
Subject: Re: Multiple telnet.c overflows

Hi Tavis, thanks for the input - I referenced Mikrotik as a vendor using a
vulnerable implementation that can be used to escape restricted shells.
This is just one example of a instance where a restricted shell could be
escaped when using inetutils, or when the vulnerable code path reached
unexpected systems (like NetBSD). As Mikrotik case is not an oss security
issue I did not post the advisory here, but as I shared to you already on
social media:

(The overflows are present in those devices as well, several million of
them, in case this isn't clear in our advisory)

The heap overflow occurs in ANY environment variables (an example instead
of DISPLAY, use USER which maybe reachable via telnet://user@ip), yes the
stack sprintf might not be remotely reachable which is why the advisory
states "multiple overflows". If instances of telnet being called with a
username via a URI handler the this would reach the heap overflow code path
as described in the advisory. Thankfully, most modern browsers no longer
implement telnet URI handlers anymore.

I cannot account for every system configuration or use case of telnet
clients. I lack those relevant clairevoyancy skills.

You are welcome to dismiss client side environment handling vulnerabilities
as none-security issues or feel free to patch the referenced
vulnerabilities as stated in the advisory. Thanks for your input I hope the
comments above with the referenced advisory are clear enough and that the
issue can be addressed by projects still using inetutils.

Kind Regards,
Hacker Fantastic

On Wed, Dec 12, 2018, 9:06 AM Tavis Ormandy < wrote:

> On Tue, Dec 11, 2018 at 1:12 PM Alan Coopersmith <
>> wrote:
>> On 12/11/18 10:39 AM, Hacker Fantastic wrote:
>> > When a telnet server requests environment options the sprintf on line
>> 1002 will
>> > not perform bounds checking and causes an overflow of stack buffer
>> > temp[50] defined
>> > at line 990. This issue can be trivially fixed using a patch to add
>> > bounds checking
>> > to sprintf such as with a call to snprintf();
>> GNU inetutils telnet is a fork of the original BSD telnet code, but most
>> of
>> the BSD's seem to have already switched to snprintf a while ago:
> To be clear, this is a bug in the (little used) GNU inetutils telnet
> *client*, not server. It's hard to imagine a real usage of this in a
> context that would be exploitable.
> If you can set DISPLAY, then you can probably also set LD_PRELOAD, and if
> you can interact with the command then you can use shell escapes.
> I asked on twitter, and was told that maybe someone is using untrusted
> telnet:// URIs with GNU inetutils, but there are no known examples. I was
> also told that "plenty" of embedded devices GNU inetutils in restricted
> shells. I'm told Mikrotik RouterOS is an example, but it's not clear to me
> if it's using it in a context that would make this a security issue, and if
> they did how they locked down the command to prevent trivial escapes.
> Tavis.

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.