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 09:06:19 -0800
From: Tavis Ormandy <>
Subject: Re: Multiple telnet.c overflows

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.


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.