Re: GNU InetUtils Security Advisory: remote authentication by-pass in telnetd
Simon Josefsson via Bug reports for the GNU Internet utilities <[email protected]> Wed, 21 Jan 2026 15:21:21 +0100
| Newsgroups | gmane.comp.gnu.inetutils.bugs |
|---|---|
| Message-ID | <[email protected]> |
Erik Auerswald <[email protected]> writes: >> On a Trisquel GNU/Linux 11 aramo laptop: >> >> root@kaka:~ sudo apt-get install inetutils-telnetd telnet >> root@kaka:~ sudo sed -i 's/#<off># telnet/telnet/' /etc/inetd.conf >> root@kaka:~ sudo /etc/init.d/inetutils-inetd start >> root@kaka:~ USER='-f root' telnet -a localhost >> ... >> root@kaka:~# > > At least on Ubuntu 22.04, "login root -f" and "login -f root" give > the same result. Using "USER='root -f' telnet -a localhost" should > have worked as an exploit as well. Since it requires a space or tab > character to separate the -f option from the user name, the patch should > also catch this variant already. The patch reject any USER value containing SPC, doesn't it catch that? It has been suggested to pass USER value to login after a '--' parameter, which makes sense. >> [...] >> ## Patch >> >> We chose to sanitize all variables for expansion. The following two >> patches are what we suggest: >> >> https://codeberg.org/inetutils/inetutils/commit/fd702c02497b2f398e739e3119bed0b23dd7aa7b >> https://codeberg.org/inetutils/inetutils/commit/ccba9f748aa8d50a38d7748e2e60362edd6a32cc > > How about also prohibiting the percent sign '%'? This is used for > variable substitution in the template expansion code for telnetd. > This would be defensive programming, i.e., I do not know a way to > usefully abuse variable substitution currently, but future changes > might allow a variable to turn into whitespace, re-opening something > like this vulnerability. Patterns aren't applied recursively, are they? I think that would be a security problem by itself. But I suspect adding '%' won't hurt. My preference is to change this into an allow-list of acceptable USER values, though, like [0-9A-Za-z._-]+, but maybe this breaks somewhere. Thanks for looking at the code! More eyes on this helps. /Simon
signature.asc
(application/pgp-signature, 1.2 KB)
-----BEGIN PGP SIGNATURE----- iQNoBAEWCgMQFiEEo8ychwudMQq61M8vUXIrCP5HRaIFAmlw4OEUHHNpbW9uQGpv 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/kdFohQmAP440PKmGlmS CnB/aAC8XSbLJZ4X62QqeF8853BZ/WOKIgEA1yQ++ZN1IqKxyFMIy1vA+4Y6oZuy fsLb5XrVg8dcOAQ= =uOp6 -----END PGP SIGNATURE-----