GNU inetutils <= 1.9.4 (& BSD based) telnet.c multiple overflows 
================================================================
GNU inetutils contains a trivial stack overflow vulnerability in the client-side environment 
variable handling which can be exploited to escape restricted shells on embedded devices. 
A stack-based overflow is present in the handling of environment variables when connecting 
telnet.c to remote telnet servers through oversized DISPLAY arguments. 

heap-overflows are also present which can be triggered in different core code path due to 
supplying oversized environment variables during client connection code. Browsers or network
clients that support telnet:// URI handlers may reach this vulnerable code when connecting
to a malicious telnetd implementation or handling USER= environment variables supplied to
telnet via "-l" parameter. As the issues occur in packet handling routines for the telnet
protocol, the telnet client must be able to connect to a remote service for the issues to
be triggered.

The stack-based overflow can be seen in the following code snippet from the latest inetutils 
release dated 2015. This issue is limited to local exploitation from restricted shells.

inetutils-telnet/inetutils-1.9.4/telnet/telnet.c

983-    case TELOPT_XDISPLOC:
984-      if (my_want_state_is_wont (TELOPT_XDISPLOC))
985-	return;
986-      if (SB_EOF ())
987-	return;
988-      if (SB_GET () == TELQUAL_SEND)
989-	{
990-	  unsigned char temp[50], *dp;
991-	  int len;
992-
993-	  if ((dp = env_getvalue ("DISPLAY")) == NULL)
994-	    {
995-	      /*
996-	       * Something happened, we no longer have a DISPLAY
997-	       * variable.  So, turn off the option.
998-	       */
999-	      send_wont (TELOPT_XDISPLOC, 1);
1000-	      break;
1001-	    }
1002:	  sprintf ((char *) temp, "%c%c%c%c%s%c%c", IAC, SB, TELOPT_XDISPLOC,
1003-		   TELQUAL_IS, dp, IAC, SE);
1004-	  len = strlen ((char *) temp + 4) + 4;	/* temp[3] is 0 ... */
1005-
1006-	  if (len < NETROOM ())

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();  

An example of the heap overflow can be seen when handling large environment
variables within the telnet client, causing heap buffer memory corruption
through long string supplied in environment variables passed to IAC packet handling
routines for example USER, DISPLAY or TERM.

An example of triggering this issue on inetutils in Arch Linux can be seen below:

DISPLAY=`perl -e 'print Ax"50000"'` telnet -l`perl -e 'print "A"x5000'` 192.168.69.1
Trying 192.168.69.1...
Connected to 192.168.69.1.
Escape character is '^]'.
realloc(): invalid next size
Aborted (core dumped)

These issues maybe present anywhere that a BSD based telnet client  is used as a base 
such as in common embedded home routers or networking equipment. These issues
relate to shared BSD code and are present in variety of forms in clients. An attacker
can potentially exploit these vulnerabilities to gain arbitrary code execution
on platforms where telnet commands are available. An example crash caused by a
heap overflow can be found below:

(gdb) run -l`perl -e 'print "A"x5000'` 192.168.69.1
Starting program: /usr/bin/telnet -l`perl -e 'print "A"x5000'` 192.168.69.1
Trying 192.168.69.1...
Connected to 192.168.69.1.
Escape character is '^]'.
realloc(): invalid next size

Program received signal SIGABRT, Aborted.
0x00007ffff7d87d7f in raise () from /usr/lib/libc.so.6
(gdb) 

Due to the various devices embedding BSD based telnet, Linux distributions
such as Arch Linux using inetutils telnet with xorg, it is unclear the full impact 
and all scenarios where this issue could be leveraged. An attacker may seek to exploit
these vulnerabilities to escape restricted shells or potentially execute arbitrary
code. 

heap corruption is remotely triggerable in clients by sending large IAC SB TELQUAL_IS 
environment variable assignments from a telnetd implementation repeatedly. A 
sample proof-of-concept has been provided alongside this advisory for triggering 
on impacted clients - telnet_term_0day.py - further investigation has identified
that these issues (or varients of them) impact a wide range of different telnet 
clients. It is possible to trigger these conditions using the PoC or examples in:

* Apple Sierra telnet client
* netkit-telnet 0.17 
* inetutils telnet
* NetBSD telnet
* Mikrotik telnet
* bsd-telnet 1.2

Other clients maybe impacted and it is advised vendors check their telnet clients
implementations for the described flaws. 

URI handlers used in client programs not just limited to web browsers maybe able
to reach the vulnerable functions when connecting with telnet:// and a vulnerable
client. The Safarai web browser supports "telnet://" URI handlers, however many
modern browsers and OS's (Apple included) have depreceated telnet clients and for
a system to be vulnerable, a user must have installed a telnet client manually.

A common scenario for the use of telnet often relates to network engineers checking
open service ports, such as mail services, through the use of telnet commands. It is
advised that such behaviour and commands are removed and depreceated in favor of 
raw socket handling code such as ncat/netcat or nmap. As the telnet protocol brings 
additional overhead to the purpose of checking open-services and these vulnerabilities
are shared across numerous BSD clients, telnet clients should not be used to connect to 
untrusted 3rd party systems. It is advised that where possible telnet is depreceated
as a management protocol in favor of SSH particularly in embedded systems where its 
use is common.

-- Hacker Fantastic (11/12/2018)
-- Added telnet_term_0day.py proof-of-concept 12/12/2018
-- Clarification that this is a BSD telnet issue 14/12/2018

https://hacker.house