bugzilla-daemon at mindrot.org
2024-Aug-14 14:58 UTC
[Bug 3717] New: Stricter sshd absolute path requirement breaks xinetd
https://bugzilla.mindrot.org/show_bug.cgi?id=3717 Bug ID: 3717 Summary: Stricter sshd absolute path requirement breaks xinetd Product: Portable OpenSSH Version: 9.8p1 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: sshd Assignee: unassigned-bugs at mindrot.org Reporter: cjwatson at debian.org Created attachment 3830 --> https://bugzilla.mindrot.org/attachment.cgi?id=3830&action=edit sshd: Allow exec without absolute path in inetd mode I originally saw this reported as https://bugs.debian.org/1078429, although that bug indicates that it's also been reported by users of several other distributions. I couldn't find a record of anyone reporting this upstream so far. The commit that split sshd into listener and session binaries (https://anongit.mindrot.org/openssh.git/commit/?id=03e3de416ed7c34faeb692967737be4a7bbe2eb5) had the effect of breaking use with xinetd. This is due to a combination of two things. Firstly, sshd no longer exempts inetd mode from the absolute-path check: - if (rexeced_flag || inetd_flag) - rexec_flag = 0; - if (!test_flag && !do_dump_cfg && rexec_flag && !path_absolute(av[0])) - fatal("sshd re-exec requires execution with an absolute path"); + if (!test_flag && !do_dump_cfg && !path_absolute(av[0])) + fatal("sshd requires execution with an absolute path"); Secondly, xinetd apparently explicitly only passes the basename when setting up argv[0]: https://github.com/openSUSE/xinetd/blob/master/src/confparse.c#L92 /* * Determine server name */ server_name = strrchr( SC_SERVER(scp), '/' ) ; if ( server_name == NULL ) server_name = SC_SERVER(scp) ; else server_name++ ; /* skip the '/' */ /* * Place it in argv[ 0 ] */ SC_SERVER_ARGV(scp)[ 0 ] = new_string( server_name ) ; I think what xinetd is doing here is perhaps a little silly, but it's also quite widely deployed. Would something like the attached patch make sense? Alternatively, I wonder whether this code is in the wrong place following the listener/session split. It would make a lot more sense for sshd-session to be pedantic about how it's executed, instead of sshd, especially given that the check was previously only applied in re-exec mode. -- You are receiving this mail because: You are watching the assignee of the bug.
bugzilla-daemon at mindrot.org
2024-Sep-12 00:37 UTC
[Bug 3717] Stricter sshd absolute path requirement breaks xinetd
https://bugzilla.mindrot.org/show_bug.cgi?id=3717 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |khalid.outaali at nav-timing.s | |afrangroup.com --- Comment #1 from Damien Miller <djm at mindrot.org> --- *** Bug 3729 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching the assignee of the bug.
bugzilla-daemon at mindrot.org
2024-Sep-12 00:38 UTC
[Bug 3717] Stricter sshd absolute path requirement breaks xinetd
https://bugzilla.mindrot.org/show_bug.cgi?id=3717 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Blocks| |3708 CC| |djm at mindrot.org Status|NEW |RESOLVED --- Comment #2 from Damien Miller <djm at mindrot.org> --- Applied - thanks. Referenced Bugs: https://bugzilla.mindrot.org/show_bug.cgi?id=3708 [Bug 3708] Tracking bug for OpenSSH 9.9 -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug.
Maybe Matching Threads
- [PATCH RESEND 1/2] Permit %L and %l percent escapes in Include
- sshd runs with -R flag?
- [PATCH v2] Permit %L and %l percent escapes in Include
- [PATCH RESEND 1/2] Permit %L and %l percent escapes in Include
- [PATCH v3 1/2] Permit %L and %l percent escapes in ssh Include