Re: Multiple telnet.c overflows

[Tavis Ormandy <taviso () google com>]

On Wed, Dec 12, 2018 at 11:35 AM Hacker Fantastic
<hackerfantastic () googlemail 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.