Re: Security Vulnerabilities in inetutils telnetd

Simon Josefsson via Bug reports for the GNU Internet utilities <[email protected]> Fri, 29 May 2026 10:39:23 +0200
Newsgroups gmane.comp.gnu.inetutils.bugs
Message-ID <[email protected]>
--=-=-=
Content-Type: text/plain

Note: This is in no way meant to diminish Tal's work, and the following
is meant as a general discussion about security reporting.

Guillem Jover <[email protected]> writes:

> It does not help that there's no mention of the bug-inetutils address
> being a publicly archived mailing list in the codebase. I've mentioned
> that it would be nice to clarify this in the README, and ideally provide
> a private method for security reports (either an email address or suggest
> filing confidential ones on codeberg f.ex.), but this was dismissed and
> it was stated that sending these kind of reports to the list was good
> because more people then can help.

What do you think about this suggested policy change?

https://codeberg.org/inetutils/inetutils/pulls/26

I did not dismiss the suggestion to have a private reporting method, but
the amount of crap reports I receive to my private inbox makes me
hesitant about offering that as a default supported route.  But we can
try it to see if it leads to any improvement.

When I ask people to make their report public, they sometimes refuse
presumably because they realize it was a five minute AI slop work that
will consume hours to understand and isn't uncommon to be invalid.

I wish there were better ways to handle this asymmetric situation.

FWIW, we've received Tal's report in private and are working on patches
and allocating CVE identifiers.  This will take more time than if that
effort was done in public (e.g., both Collin and I are away over the
weekend) where you and others could help to do the analysis and review
patches.  I'm not convinced that slow-down and closed nature of
development, with reduced quality of review, is in the best interest of
our users generally.

Several of the InetUtils network servers implement inherently insecure
protocols.  Often the environment required to run these services
securely in the first place (e.g., external VPN connection to a telnetd
server) mitigate many security concerns.  Suggestions how to better
explain this aspect to users in the manual would be appreciated, but I
believe it ought to be well understood through any modern literature
about TELNET.

/Simon

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

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

iQNoBAEWCgMQFiEEo8ychwudMQq61M8vUXIrCP5HRaIFAmoZULwUHHNpbW9uQGpv
c2Vmc3Nvbi5vcmfCHCYAmDMEXJLOtBYJKwYBBAHaRw8BAQdACIcrZIvhrxDBkK9f
V+QlTmXxo2naObDuGtw58YaxlOu0JVNpbW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9z
ZWZzc29uLm9yZz6IlgQTFggAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYh
BLHSvRN1vst4TPT4xNc89jjFPAa+BQJp4fWRBQkOa+rdAAoJENc89jjFPAa+hWIA
/1lQvrJeGlQq50lP6tm99D1zDy7J1tQ3ha4x0Jx7rkFTAP9hpUKuTvm6m1fXyiZV
YZlu2+Id/Dq3CIAZvNF+XEr2BLgzBFySz4EWCSsGAQQB2kcPAQEHQOxTCIOaeXAx
I2hIX4HK9bQTpNVei708oNr1Klm8qCGKiPUEGBYIACYCGwIWIQSx0r0Tdb7LeEz0
+MTXPPY4xTwGvgUCaeCW1wUJDmqLVgCBdiAEGRYIAB0WIQSjzJyHC50xCrrUzy9R
cisI/kdFogUCXJLPgQAKCRBRcisI/kdFoqdMAQCgH45aseZgIrwKOvUOA9QfsmeE
8GZHYNuFHmM9FEQS6AD6A4x5aYvoY6lo98pgtw2HPDhmcCXFItjXCrV4A0GmJA4J
ENc89jjFPAa+s7AA+gIIHpBApDpcDj1sKhzDngmpvwQf0VkHme6s+EG7qSgpAQDe
/XMrU0c0Pa3ji85cMqZhvzJOFI/soe662lzL0QY3Bbg4BFySz2oSCisGAQQBl1UB
BQEBB0AxlRumDW6nZY7A+VCfek9VpEx6PJmdJyYPt3lNHMd6HAMBCAeIfgQYFggA
JgIbDBYhBLHSvRN1vst4TPT4xNc89jjFPAa+BQJp4JbXBQkOaottAAoJENc89jjF
PAa+RNUA/2faQO/nFT06E+MlhlQdo/0chlQXC5TZMPTVvVBFwoLOAP9xLJK0ow5E
jTzYJB4K810AL/Iv6PEOAEgA4cPTHVlbCQAKCRBRcisI/kdFoqbjAQDowmOpVPb2
tbrlXIPzMiXQCqulrzn/bDPoKUX92tncewEA5vKFYbdSKg/1aLT3Kf60u0iVt5+L
PK89n3pxfz7GwAA=
=OOYY
-----END PGP SIGNATURE-----
--=-=-=--