Date: Wed, 12 Dec 2018 09:06:19 -0800 From: Tavis Ormandy <taviso@...gle.com> To: oss-security@...ts.openwall.com Cc: hackerfantastic@...glemail.com Subject: Re: Multiple telnet.c overflows On Tue, Dec 11, 2018 at 1:12 PM Alan Coopersmith < alan.coopersmith@...cle.com> 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 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.