[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJ_zFkKWP18xP6jUh=Gax3o_R4mFB905FC9yKWTd9-VEwEZEmA@mail.gmail.com>
Date: Wed, 12 Dec 2018 12:09:53 -0800
From: Tavis Ormandy <taviso@...gle.com>
To: hackerfantastic@...glemail.com
Cc: oss-security@...ts.openwall.com
Subject: Re: Multiple telnet.c overflows
On Wed, Dec 12, 2018 at 11:35 AM Hacker Fantastic
<hackerfantastic@...glemail.com> wrote:
>
> Hi Tavis,
>
> The "little used" package you mentioned is in some distributions a dependency of "xorg-xinit" (:: removing inetutils breaks dependency 'inetutils' required by xorg-xinit in Arch Linux). The security boundary in the Mikrotik example is "escape of restricted shells" which is also in the TLDR; advisory. If you are unhappy with how I described the issue and wish to spend time and ultimately money researching remotely reachable code paths (aside from the URI handler example I already gave you) then it is worth looking into more detail the issues with the heap overflow and if it is reachable in the client via a server-side telnetd implementation for instance. The code there is a mess.
>
> As I already stated, I am unable to account for every use of telnet client-side code or how it is called in every application, particularly all the projects out there used from open-source community or co-opted by vendors into commercial offerings (like the given example, Mikrotik). Splitting hairs over security boundaries of a single issue with many use cases is not something I have time for, the vulnerability is exactly as described with security relevant impacts in my original advisory. It would be nice to see the heap overflow reached via a telnetd service just to prove a point but ultimately it is beyond the scope of this discussion, why not put the energy you spent on these emails to use exploring if the heap is also corrupted in such instances? ;-)
>
The energy I spent asking if a security boundary being crossed was
minimal. I think the answer is that you do not know of any cases of
this being a security boundary, but you feel that all bugs are
security bugs whether or not a security boundary is crossed, because
you don't know how someone might be using the software.
> It was considered a security issue for such straight-forward restricted shell escapes in 2004/2005 (when there were numerous reported instances of such occurring in telnet clients alongside other client-side overflows). One of the issues is addressed in the implementations of some BSD clients and not in others.
>
> Just because you do not know how to exploit a bug does not mean it does not have security implications, it just means they have not been discovered yet or the researcher does not have the luxury of time that others have.
>
> I hope this clarifies my points satisfactorily for you.
It certainly does, thank you. I think we disagree on what qualifies as
a vulnerability, but I'm still very grateful for you reporting this.
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.
