[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAG-OiePvtSA1Wu03T76iXfYhER0Qr7fCBZ6n+mSfVpbjJ-UnQQ@mail.gmail.com>
Date: Thu, 13 Dec 2018 07:53:54 -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, I do not believe this is either CVE-2005-0469 or CVE-2005-0468. The
issue is the same problem I described in handling environment variables
originally, the TERM environment being a remotely reachable way of trigger
the issue in inetutils and other clients. The issue appears to behave
differently on netkit-telnet instances, and mirrors that of the Mikrotik
client - causing a ring.cc assertion error to be printed, however the
application still causes a SIGABRT when the connection is then terminated
with the large buffers having caused a failure in ring.cc.
Here is an example of the latest netkit-telnet behaviour with what I
believe is heap corruption caused by the same PoC trigger -
telnet_term_0day.py (the SIGABRT happens after the connection is killed to
cause the ring.cc assertion):
telnet: buffer overflow, losing data, sorry
telnet: ring.cc:143: int ringbuf::flush(): Assertion `top-bot > 0 &&
top-bot <= count' failed.
Aborted (core dumped)
Program received signal SIGABRT, Aborted.
0x00007ffff7a59d7f in raise () from /usr/lib/libc.so.6
(gdb) bt
#0 0x00007ffff7a59d7f in raise () from /usr/lib/libc.so.6
#1 0x00007ffff7a44672 in abort () from /usr/lib/libc.so.6
#2 0x00007ffff7a44548 in __assert_fail_base.cold.0 () from
/usr/lib/libc.so.6
#3 0x00007ffff7a52396 in __assert_fail () from /usr/lib/libc.so.6
#4 0x000055555555f417 in ringbuf::flush() ()
#5 0x000055555555f01f in netflush() ()
#6 0x000055555555fcbe in process_rings(int, int, int, int, int, int) ()
#7 0x00005555555639cf in Scheduler(int) ()
#8 0x0000555555563acf in telnet(char const*) ()
#9 0x000055555555ea9b in tn(int, char const**) ()
#10 0x0000555555559acd in main ()
I couldn't account for all clients in my original advisory as I stated, the
telnet client code is quite messy and there are buffers that are referenced
in loops using functions such as sprintf() / free() and realloc() -
supplied environment arguments DISPLAY, USER, TERM and things like
LOGNAME,LINEMODE which have a corresponding IAC handler all seem to be ways
of reaching the root vulnerable code paths. It also appears that this issue
maybe much deeper rooted in the BSD code base that is shared amongst many
telnet clients - inetutils and Mikrotik included. I have provided a PoC for
testing purposes of the issue through a supplied IAC handler to set the
TERM protocol in a connecting client.
I have also learned that Safari still supports "telnet://" URI handlers
however telnet command is deprecated on OS-X, a user would need to have a
vulnerable telnet client installed such as the one in "homebrew" - however
the USER= overflow is not reached in that client due to some additional
argument length checking code by Apple. For a remote telnet client to
trigger this issue in a URI handler an attacker would need to supply the
"USER=" environment variable through telnet://user@ip which is a correct
way of supplying a username in a uniform resource identifier - thus giving
these vulnerabilities a potential way of being called remotely when a user
supports telnet URI handlers and is using a vulnerable telnet
implementation. Alternatively if USER= cannot be reached or overflown (as
in the Apple client) then the overflows could be caused by a connecting
telnetd service such as the telnet_term_0day.py example proof-of-concept.
That could be reached simply by accessing telnet:// - URI handlers are not
just limited to web browsers and are a means to identify network resources,
there could be other clients not just web browsers out there using them
(rfc3986)
Unfortunately it is really busy for me this time of year and I do not have
the time to investigate further beyond what I have provided to the list.
They are present in at least a dozen BSD based telnet clients so far,
Apple's telnet client from Sierra, NetKIT BSD (stack overflow confirmed,
heap unsure), inetutils-1.9.4 & also netkit-telnet. It is hard for me to
determine exploitation risk of all such instances that are out there but I
hope now this list can see that this is a widespread problem not just
limited to a single telnet client and has security implications from a
remote perspective and also locally - when a user is in a restricted shell
and calls the "telnet" command they could breakout of the shell using one
of these overflows. Hackers out there might now cry out "ah-hah but what
about !sh" - in some restricted shells in embedded devices (Mikrotik) such
functionality is often removed and thus this offers a way to overwrite /
corrupt memory and potentially breakout of such shells. I will agree that
the use of the stack-overflow and its restricted shell breakout is minimal
but it should still not be dismissed as "not a vulnerability" because
security implications aren't immediately apparent.
With that my original advisory needs amending to take into account that the
core problem being demonstrated here is more wide-spread than I initially
realised. I would argue telnet should be deprecated entirely in systems
where it has not yet been disabled in favour of more regularly audited &
peer reviewed OpenSSH. I believe the reasons these flaws have persisted for
some 20 years in various forms is that no-one takes telnet client security
as an issue yet I have shown two ways it could be triggered remotely and
also used in a local context.
Happy Hacking to all and to all a Merry Haxmas!
Kind Regards,
Hacker Fantastic
On Wed, Dec 12, 2018 at 10:13 PM Tavis Ormandy <taviso@...gle.com> wrote:
> On Wed, Dec 12, 2018 at 5:21 PM Hacker Fantastic
> <hackerfantastic@...glemail.com> wrote:
> >
> > Please see the below proof of concept in triggering the heap overflow
> using the IAC SB TELQUAL_IS environment option variable assignment. As per
> my original advisory, which did not fully indicate the details but gave the
> overview of how to trigger the condition.
>
> Cool, but I think this is a different bug (AFAICT, it's CVE-2005-0469,
> it was fixed in netkit, but far fewer distros use inetutils). I agree
> this was a real vulnerability, It's a pretty good sign inetutils
> should be deprecated imho.
>
> Tavis.
>
--
Matthew Hickey
Tel: +44 7543 661237
Web: http://blog.hackerfantastic.com
Please visit my website for blog postings, status updates and project
information.
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.
