Re: CVE-2024-6387: RCE in OpenSSH's server, on glibc-based Linux systems

[Jacob Bachmeyer <jcb62281 () gmail com>]

Jeffrey Walton wrote:
> On Wed, Jul 3, 2024 at 2:39 AM Jacob Bachmeyer <jcb62281 () gmail com> wrote:
>   
> > Qualys Security Advisory wrote:
> >     
> > > [...]
> > >       
> > A thought occurred to me late last night:  this exploit required the use
> > of a very long fake user name (~128KB).  No legitimate account will have
> > such a name; should defense-in-depth motivate limiting maximum user name
> > length to some (un)reasonable value?  (The actual longest user name on
> > the system cannot be used to set the limit because doing that would leak
> > the length of the longest valid user name.)  I doubt any real system has
> > even 256-byte-long user names, so a 1KiB limit (perhaps by default, with
> > a configuration option (I propose "MaxLoginNameLen" to start a
> > discussion) to raise or lower it?) would be far beyond any reasonable
> > need, but would (or so it seems to me) have made at least this exploit
> > much harder, if not impossible.
> >     
>
> $ grep -IR LOGIN_NAME_MAX /usr/include
> /usr/include/bits/confname.h:    _SC_LOGIN_NAME_MAX,
> /usr/include/bits/confname.h:#define    _SC_LOGIN_NAME_MAX    _SC_LOGIN_NAME_MAX
> /usr/include/bits/local_lim.h:#define LOGIN_NAME_MAX            256
> /usr/include/bits/posix1_lim.h:#define  _POSIX_LOGIN_NAME_MAX   9
> ...
>   

I see.  So there is a declared system limit (apparently 256 bytes on GNU 
systems, but allowed to be as low as 9 bytes in POSIX) on the length of 
a valid user name.  Why does sshd not, as a defense-in-depth measure, 
immediately drop the connection if a user name longer than that limit is 
received?  ("We had not thought of that." is a perfectly good answer 
here, of course.)

Solar Designer mentioned a previous patch that avoided sending 
excessively long user names to PAM in response to a PAM implementation 
that apparently has exploitable overflows.  I would suggest adding 
another check using LOGIN_NAME_MAX as the limit to the code where the 
user name is first received.  If a user name that cannot possibly be 
valid on the system is received, drop the connection immediately without 
further parsing.  This would potentially add a risk for fingerprinting 
based on LOGIN_NAME_MAX, but that is probably minor compared to other 
ways to identify a remote OS and this check would have prevented the 
presented Ubuntu 6.06.1 exploit of this issue.  It might make other, 
yet-to-be-found issues infeasible to exploit.

I argue for it as a defense-in-depth measure.


-- Jacob