![]() |
|
Message-ID: <CAG-OieODDwrDfoci2ehVUbHg13Ehz66VB50KERZ01qCdrgCLBw@mail.gmail.com> Date: Wed, 12 Dec 2018 10:08:41 -0800 From: Hacker Fantastic <hackerfantastic@...glemail.com> To: Tavis Ormandy <taviso@...gle.com> Cc: oss-security@...ts.openwall.com 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: https://hacker.house/releasez/expl0itz/mikrotik-jailbreak.txt (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 <taviso@...gle.com wrote: > > > 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[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.