On Tue, 2026-03-24 at 17:17:22 +0100, Simon Josefsson via Bug reports for the GNU Internet utilities wrote: > Collin Funk <[email protected]> writes: > >> I don't think the proposal to dump the entire protocol into syslog > >> seem like a great idea either, which would require substantial > >> sanitization. Instead for Debian I went with a relatively simple > >> change from using «/tmp/telnet-debug» to «/run/telnet/debug.<PID>», > >> and made telnetd print the pathname used on the telnet session. > >> > >> I suppose an alternative could be to let the telnetd user specify a > >> filename to use. But the /run switch seems good enough to me. > > > > I don't like the syslog idea either. > > > > I kind of feel like the option should just be removed. I can't find any > > users of 'telnetd --debug' or 'telnetd -D' on GitHub or Debian code > > search. If someone needs to debug telnet Wireshark is available pretty > > much everywhere.
Ah, good point about wireshark! I've not compared both outputs to see whether the current telnetd output might be "better" though (and I don't think I'll have the time)? But otherwise, I think if that was to be the case, then it would be best to improve wireshark which would benefit all other telnet implementations. > I think it would be fine to just remove this (anti-)feature. I guess that might be the best option, and it should also reduce attack surface. > However, ftpd supports --debug to send things to syslog. Is it is > similarily vulnerable? I don't think they are comparable though. The telnetd option seems like a full protocol dumper including session payload, while for ftpd it is more common debugging output (developer controlled), plus the FTP commands being used. But I'm not sure now if ftpd fully sanitizes the protocol commands for syslog logging. :/ > Assuming that attackers can add '--debug' to telnetd invocation, and > also be able to read syslog content, doesn't seem all that reasonable to > me. I think the problems might be more that if an admin enables that option, on a server exposed to users, then it can either end up sending sensitive information over the network in case of remote snoopable syslog (for encrypted telnet connections), or unless telnetd is doing some heavy sanitization, it might be opening more attack surface from the system logger side (I'm reminded of the log4j recent vulnerabilities). Thanks, Guillem
