bug-inetutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: telnetd security vulnerability CVE-2020-10188


From: Guillem Jover
Subject: Re: telnetd security vulnerability CVE-2020-10188
Date: Sat, 11 Apr 2020 03:14:45 +0200

[ For some reason, I've not received the message from the list, and
  just happened to notice it from the web archive, so reconstructing
  the reply from there… ]

On Fri, 2020-04-10 at 15:04:20 -0400, Alfred M. Szmidt wrote:
> On Wed, 2020-04-08 at 13:41:58 +0200, Guillem Jover wrote:
> > I've been notified of a security vulnerability in inetutils telnetd,
> > which was reported initially against netkit-telnet, but that one has
> > been fixed in Debian for a very long time (around two decades ago [N]).

> Thank you for your bug report, please specify which inetutils versions
> you are refering to in pristine condition without any patches.  You
> mention an assert, which assert exactly?

The inetutils version in Debian is based off upstream's 1.9.4 with
30 patches from upstream git master, plus 7 local patches (only 3
of which are pending and relevant to be sent upstream) and all of
these local patches are completely irrelevant to the issue at hand.

The assert is from the python PoC itself. I also mentioned that I've
not done any proper analysis on anything, not even properly read the
full advisory, and while my guess is that upstream pristine inetutils
is pretty much affected, I cannot confirm it. But provided enough
information, links and context to go from here, which apparently has
gone unread.

> And since Debian supposedly fixed this two decades ago, why have they
> not sent this to upstream? The nonchalance from Debian by refusing to
> report bugs to upstream is getting quite tiresome.

*Sigh*, really, I'm aware of your animosity towards Debian, but
this is not very conductive nor helpful… this style of interaction
is one of the reasons I find it a drain to send things upstream TBH.

Why the Debian maintainer (Herbert Xu) at the time did not notify all
the BSDs the code had inherited from, or any sibling projects that
might have also forked from BSDs at different times, well, I don't
know. For inetutils perhaps he was maybe not even aware it existed?
Also all code bases had diverged quite a bit already back then anyway,
so notifying of any such fixes could take quite some time in case of
having to verify whether the other implementations were affected to
avoid wasting upstream time, and then be submitted to every single
one of them. But all these are just guesses in good faith, you'd have
to ask Herbert… (which seems rather pointless and a distraction from
the actual problem here).

Also, I'm not sure whether you are aware, but Mats maintains the
netkit-telnet packages in Debian, and in the same way, I think it would
be completely inappropriate to blame him for any patch being carried
fixing things that have not yet been fixed in inetutils…

> > But the code inherited from the BSDs seems to still be around in
> > inetutils. I've not yet read the disclosure in detail (it's rather
> > long), and only checked the code superficially. But run the PoC
> > exploit on a VM, and while I think the memory layout is different
> > which makes it trigger the assert, it looks like inetutils telnetd
> > implementation is still vulnerable?
> > 
> >   [N] https://bugs.debian.org/953478
> > 
> > I don't think I'll have time to dig into this quickly so I'd
> > appreciate if someone else could have a peek?
> > 
> > The relevant information is:
> > 
> >   Debian inetutils report <https://bugs.debian.org/956084>
> >   <https://security-tracker.debian.org/tracker/CVE-2020-10188>
> >   
> > <https://appgateresearch.blogspot.com/2020/02/bravestarr-fedora-31-netkit-telnetd_28.html>
> > 
> > PoC exploit:
> > 
> >   
> > <https://raw.githubusercontent.com/immunityinc/bravestarr/master/bravestarr.py>

So please, someone, take a proper look at the aforementioned information,
and go from there.

Drained,
Guillem



reply via email to

[Prev in Thread] Current Thread [Next in Thread]