Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 03 Jul 2024 19:58:25 -0500
From: Jacob Bachmeyer <>
Subject: Re: CVE-2024-6387: RCE in OpenSSH's server, on glibc-based
 Linux systems

Jeffrey Walton wrote:
> On Wed, Jul 3, 2024 at 2:39 AM Jacob Bachmeyer <> 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

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.