Re: Telnetd Vulnerability Report

Simon Josefsson via Bug reports for the GNU Internet utilities <[email protected]> Fri, 06 Feb 2026 19:42:08 +0100
Newsgroups gmane.comp.gnu.inetutils.bugs
Message-ID <[email protected]>
Erik Auerswald <[email protected]> writes:

> the method seems to be plausible, because a Telnet client can send any
> environment variable to a Telnet server, and GNU Inetutils' Telnet
> server does not restrict this.

Indeed.  Is there any cross-telnet adopted way to resolve this?

Comparing to the SSH world, then OpenSSH has this:

     AcceptEnv
             Specifies what environment variables sent by the client will be
             copied into the session's environ(7).  See SendEnv and SetEnv in
             ssh_config(5) for how to configure the client.  The TERM environ‐
             ment variable is always accepted whenever the client requests a
             pseudo-terminal as it is required by the protocol.  Variables are
             specified by name, which may contain the wildcard characters ‘*’
             and ‘?’.  Multiple environment variables may be separated by
             whitespace or spread across multiple AcceptEnv directives.  Be
             warned that some environment variables could be used to bypass
             restricted user environments.  For this reason, care should be
             taken in the use of this directive.  The default is not to accept
             any environment variables.

Is there any reason we shouldn't adopt something similar?  Especially
the last sentence.  Allowing clients to set environment variables seems
like a never ending source of concerns.

/Simon
signature.asc (application/pgp-signature, 1.2 KB)
-----BEGIN PGP SIGNATURE-----

iQNoBAEWCAMQFiEEo8ychwudMQq61M8vUXIrCP5HRaIFAmmGNgAUHHNpbW9uQGpv
c2Vmc3Nvbi5vcmfCHCYAmDMEXJLOtBYJKwYBBAHaRw8BAQdACIcrZIvhrxDBkK9f
V+QlTmXxo2naObDuGtw58YaxlOu0JVNpbW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9z
ZWZzc29uLm9yZz6IlgQTFggAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYh
BLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XQkBQkNZGbwAAoJENc89jjFPAa+BtIA
/iR73CfBurG9y8pASh3cbGOMHpDZfMAtosu6jbpO69GHAP4p7l57d+iVty2VQMsx
+3TCSAvZkpr4P/FuTzZ8JZe8BrgzBFySz4EWCSsGAQQB2kcPAQEHQOxTCIOaeXAx
I2hIX4HK9bQTpNVei708oNr1Klm8qCGKiPUEGBYIACYCGwIWIQSx0r0Tdb7LeEz0
+MTXPPY4xTwGvgUCZ9F0SgUJDWRmSQCBdiAEGRYIAB0WIQSjzJyHC50xCrrUzy9R
cisI/kdFogUCXJLPgQAKCRBRcisI/kdFoqdMAQCgH45aseZgIrwKOvUOA9QfsmeE
8GZHYNuFHmM9FEQS6AD6A4x5aYvoY6lo98pgtw2HPDhmcCXFItjXCrV4A0GmJA4J
ENc89jjFPAa+wUUBAO64fbZek6FPlRK0DrlWsrjCXuLi6PUxyzCAY6lG2nhUAQC6
qobB9mkZlZ0qihy1x4JRtflqFcqqT9n7iUZkCDIiDbg4BFySz2oSCisGAQQBl1UB
BQEBB0AxlRumDW6nZY7A+VCfek9VpEx6PJmdJyYPt3lNHMd6HAMBCAeIfgQYFggA
JgIbDBYhBLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XTSBQkNZGboAAoJENc89jjF
PAa+0M0BAPPRq73kLnHYNDMniVBOzUdi2XeF32idjEWWfjvyIJUOAP4wZ+ALxIeh
is3Uw2BzGZE6ttXQ2Q+DeCJO3TPpIqaXDAAKCRBRcisI/kdFotiMAP9pDlDUwcdk
DERCVrPMDFvHtCPHbyCc2mSkuE4uz3e7gAD+M9WAzC+d4FLpKIZ0ndryeeYdzxeX
duG2Mhm0z0L1JAY=
=nfYu
-----END PGP SIGNATURE-----