openssh bugs - Aug 2024 - [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.

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.

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.

https://bugzilla.mindrot.org/show_bug.cgi?id=3717

--- Comment #3 from Darren Tucker <dtucker at dtucker.net> ---
*** 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.
You are watching someone on the CC list of the bug.