oss-security - Re: Telnetd Vulnerability Report

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260225230428.yNKndtKS@steffen%sdaoden.eu>
Date: Thu, 26 Feb 2026 00:04:28 +0100
From: Steffen Nurpmeso <steffen@...oden.eu>
To: oss-security@...ts.openwall.com
Subject: Re: Telnetd Vulnerability Report

Marco Moock wrote in
 <20260225210354.2bbf0d04@...nkedores.dorfdsl.de>:
 |Am 25.02.2026 um 20:47:09 Uhr schrieb Steffen Nurpmeso:
 |
 |> It seems to me one reason to use telnet(1) arises from the fact
 |> that there is no nc(1) around.  busybox has one, but it is not
 |> feature rich enough.  And the one of LibreSSL, which is, as it
 |> says, a swiss-army-knife, is very often not available at all.
 |
 |IIRC this issue is only about the telnetd telnet server daemon, not the
 |client. This service is only in use if enabled in inetd (or
 |replacements) by the administrator.

Already open socket aka standard descriptors.
If executables can be replaced, some specialized dropbear, or even
openssh seems better to me.
I never have used telnetd by myself, yet the telnet client i am
using pretty regulary, it comes from the same package

  $ pkginfo -o /usr/bin/telnet
  Package    File
  inetutils  usr/bin/telnet

but which the Linux distribution (mostly old-hand admins driven)
i use massively restricts

        --disable-{servers,clients} \
        --enable-{hostname,ifconfig,inetd,ftp,telnet,traceroute}

which is why i do not easily (without build overlay) can be
embarrased in a situation of necessity, to use telnetd, you know.

Since i have seen Lyndon Nerenberg's message already, yes,
plenty of possibilities there may be (i wonder how many of those
could be driven via nc, especially so with an nc which could
be sliced into some inetd (fwiw) and have an -e, or what about
introduction of a pty layer), but the security layer algorithms
(RFC 2953) seem historic -- and, generally speaking, to me it
looks like a layer abstraction error, so *if*, then maybe that
IANA registered port 992 for telnets should become used, should
become an official RFC (except in the email area less harcore
SMTP the IETF is a great thing *imho* (except for the "I" being
"not so" "I"), but anyway, no notion of telnets or port 992 in
inetutils whatsoever, so that would require an external wrapper.
Maybe nc can provide the necessary TLS wrapper for plain telnetd.
But Linux/Unix is not Plan9, and wrapper programs are expensive,
all those context-switches (surely), and data copying (likely).
(Yet Johnson of dropbear refused a patch that simply did some FD
exchange, instead he insisted on command line wrapper mode via
nc(1), a decade or more ago.)

So to reiterate that in my opinion nc is a good thing, except for
not using "network newline" aka \r\n but .. i think plain Unix \n.
Surely the OpenBSD people will not add -e, and i am afraid there
will be no pty mode either.  But i personally would always refrain
from spreading crypto to anywhere, there are too many libraries
around already *imho*, which need to share the eyes which can look
and see, so that is that.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

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.