Re: Telnetd Vulnerability Report

--000000000000f5ea96064a60e3e3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello,

Thank you for consulting with me. As a vulnerability researcher, I do not
want to take responsibility for the effectiveness of the fix.
With that being said, In my opinion the proposed fix will stop this
exploit, but the main issue stays. The issue exists as long as
unauthenticated clients can set arbitrary environment variables in the
memory of telnetd and its sub processes.
The best solution will be that the environment variables set by the client
will only apply on the shell process and only after the client has already
authenticated. No process running as root should run with any environment
variables set by the client.

Best regards,
Ron Ben Yizhak

On Mon, Feb 9, 2026 at 11:21=E2=80=AFAM Erik Auerswald <[email protected]=
i-kl.de>
wrote:

> Hi Ron Ben Yizhak,
>
> On Fri, Feb 06, 2026 at 06:27:30PM +0100, Erik Auerswald wrote:
> > On Thu, Feb 05, 2026 at 02:39:57PM +0200, Ron Ben Yizhak via Bug report=
s
> for the GNU Internet utilities wrote:
> > >
> > > My name is Ron Ben Yizhak and I am a security researcher from
> SafeBreach.
> > >
> > > I want to report a severe vulnerability that I found in telnetd from
> the
> > > repository https://codeberg.org/inetutils/inetutils
> > > [...]
> >
> > [...] a quick and dirty hack that should stop this method is contained
> > in the attached patch.  I have tested it with the above mentioned
> > method only.
>
> Can you confirm that the patch[0] from my previous message[1] stops
> the exploit?
>
> [0]
> https://lists.gnu.org/archive/html/bug-inetutils/2026-02/txt5Lp7CdbQkO.tx=
t
> [1] https://lists.gnu.org/archive/html/bug-inetutils/2026-02/msg00001.htm=
l
>
> > [...]
> > A possible workaround would be to use an older version of "login".
>
> Another possible workaround would be to wrap "login" execution with
> "env", and use "env" to unset the problematic environment variable
> "CREDENTIALS_DIRECTORY".  The inetd.conf line could look as below:
>
> telnet stream tcp nowait root /usr/local/libexec/telnetd telnetd
> --exec-login "/usr/bin/env -u CREDENTIALS_DIRECTORY /usr/bin/login -p -h =
%h
> %?u{-f -- %u}{-- %U}"
>
> Can you confirm that this stops the exploit?
>
> Thanks,
> Erik
>

--000000000000f5ea96064a60e3e3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello,<div><br></div><div>Thank you for consulting=C2=A0wi=
th me. As a vulnerability researcher, I do not want to take responsibility =
for the effectiveness of the fix.</div><div>With that being=C2=A0said, In m=
y opinion the proposed fix will stop this exploit, but the main issue stays=
. The issue exists as long as unauthenticated clients can set arbitrary env=
ironment variables in the memory of telnetd and its sub processes.</div><di=
v>The best solution will be that the environment variables set by the clien=
t will only apply on the shell process and only after the client has alread=
y authenticated. No process running as root should run with any environment=
 variables set by the client.</div><div><br></div><div>Best regards,</div><=
div>Ron Ben Yizhak</div></div><br><div class=3D"gmail_quote gmail_quote_con=
tainer"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Feb 9, 2026 at 11:21=
=E2=80=AFAM Erik Auerswald &lt;<a href=3D"mailto:[email protected]=
">[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">Hi Ron Ben Yizhak,<br>
<br>
On Fri, Feb 06, 2026 at 06:27:30PM +0100, Erik Auerswald wrote:<br>
&gt; On Thu, Feb 05, 2026 at 02:39:57PM +0200, Ron Ben Yizhak via Bug repor=
ts for the GNU Internet utilities wrote:<br>
&gt; &gt; <br>
&gt; &gt; My name is Ron Ben Yizhak and I am a security researcher from Saf=
eBreach.<br>
&gt; &gt; <br>
&gt; &gt; I want to report a severe vulnerability that I found in telnetd f=
rom the<br>
&gt; &gt; repository <a href=3D"https://codeberg.org/inetutils/inetutils" r=
el=3D"noreferrer" target=3D"_blank">https://codeberg.org/inetutils/inetutil=
s</a><br>
&gt; &gt; [...]<br>
&gt; <br>
&gt; [...] a quick and dirty hack that should stop this method is contained=
<br>
&gt; in the attached patch.=C2=A0 I have tested it with the above mentioned=
<br>
&gt; method only.<br>
<br>
Can you confirm that the patch[0] from my previous message[1] stops<br>
the exploit?<br>
<br>
[0] <a href=3D"https://lists.gnu.org/archive/html/bug-inetutils/2026-02/txt=
5Lp7CdbQkO.txt" rel=3D"noreferrer" target=3D"_blank">https://lists.gnu.org/=
archive/html/bug-inetutils/2026-02/txt5Lp7CdbQkO.txt</a><br>
[1] <a href=3D"https://lists.gnu.org/archive/html/bug-inetutils/2026-02/msg=
00001.html" rel=3D"noreferrer" target=3D"_blank">https://lists.gnu.org/arch=
ive/html/bug-inetutils/2026-02/msg00001.html</a><br>
<br>
&gt; [...]<br>
&gt; A possible workaround would be to use an older version of &quot;login&=
quot;.<br>
<br>
Another possible workaround would be to wrap &quot;login&quot; execution wi=
th<br>
&quot;env&quot;, and use &quot;env&quot; to unset the problematic environme=
nt variable<br>
&quot;CREDENTIALS_DIRECTORY&quot;.=C2=A0 The inetd.conf line could look as =
below:<br>
<br>
telnet stream tcp nowait root /usr/local/libexec/telnetd telnetd --exec-log=
in &quot;/usr/bin/env -u CREDENTIALS_DIRECTORY /usr/bin/login -p -h %h %?u{=
-f -- %u}{-- %U}&quot;<br>
<br>
Can you confirm that this stops the exploit?<br>
<br>
Thanks,<br>
Erik<br>
</blockquote></div>

--000000000000f5ea96064a60e3e3--