Hi Simon, On Wed, Jan 21, 2026 at 03:21:21PM +0100, Simon Josefsson wrote: > 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 should, as I wrote above. I did not test with telnet(d). > It has been suggested to pass USER value to login after a '--' > parameter, which makes sense. Yes, that could be additional hardening, at least for GNU/Linux. > >> [...] > >> ## 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. I did not test this, and but for me, it is not obvious from the code if they are applied recursively or not. > 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. Limiting sanitize() to those characters would probably break TTY substitution (%L and %t). Not tested, just from a quick glance at the code. > Thanks for looking at the code! More eyes on this helps. I think that the current fix is sufficient. Prohibiting '%' would make it obvious that template expansion cannot be abused via attacker controlled input while building the argv structure for login(1) invocation. Cheers, Erik
