Re: Telnetd Vulnerability Report

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Erik Auerswald <[email protected]> writes:

>> Comparing to the SSH world, then OpenSSH has this:
>>=20
>>      AcceptEnv
>>              Specifies what environment variables sent by the client wil=
l be
>>              copied into the session's environ(7).  See SendEnv and SetE=
nv in
>>              ssh_config(5) for how to configure the client.  The TERM en=
viron=E2=80=90
>>              ment variable is always accepted whenever the client reques=
ts a
>>              pseudo-terminal as it is required by the protocol.  Variabl=
es are
>>              specified by name, which may contain the wildcard character=
s =E2=80=98*=E2=80=99
>>              and =E2=80=98?=E2=80=99.  Multiple environment variables ma=
y be separated by
>>              whitespace or spread across multiple AcceptEnv directives. =
 Be
>>              warned that some environment variables could be used to byp=
ass
>>              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.
>>=20
>> 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.
>
> I'd say adding such a configuration option to telnetd could be useful.
> I'd also prefer not to accept environment variables by default, i.e.,
> without explicit configuration.

So add a new telnetd parameter --accept-env that accepts names of
environment variables to allow clients to set?  And default it to the
empty set?

I'm not yet sure if this will actually work, or if we are just moving
the same security problem to default /etc/inetd.conf files that
allowlist some environments.  But maybe this is consistent with
/etc/ssh/sshd_config in many distributions containing things like:

AcceptEnv LANG LC_* COLORTERM NO_COLOR

We should review BSD telnet's etc to see if this problem has been solved
before.

/Simon

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQNoBAEWCgMQFiEEo8ychwudMQq61M8vUXIrCP5HRaIFAmmHfSwUHHNpbW9uQGpv
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/kdFor37AP90GmTOXBhl
5MvnxZUFARIfngTjh+n1aqo5MKW9bJmTGgEAn+X4EpNN2r0KlgTirdO2alPEOoDk
NfSoSpAJPrGIZgI=
=N4WX
-----END PGP SIGNATURE-----
--=-=-=--