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

[Jeffrey Walton <noloader () gmail com>]

On Wed, Jul 3, 2024 at 2:39 AM Jacob Bachmeyer <jcb62281 () gmail com> wrote:
> Qualys Security Advisory wrote:
> > Qualys Security Advisory
> >
> > regreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems
> > (CVE-2024-6387)
> >
> > [...]
> >
> > ========================================================================
> > SSH-2.0-OpenSSH_4.2p1 Debian-7ubuntu3 (Ubuntu 6.06.1, from 2006)
> > ========================================================================
> >
> > [...]
> >
> > ------------------------------------------------------------------------
> > Practice
> > ------------------------------------------------------------------------
> >
> >     I learned everything the hard way
> >         -- The Interrupters, "The Hard Way"
> >
> > To mount this attack against sshd, we initially faced three problems:
> >
> > - The House of Mind requires us to store the pointer to our fake arena
> >   at address 0x08100000 in the heap; but are we able to store attacker-
> >   controlled data at such a high address? Because sshd calls pam_start()
> >   at the very beginning of the user authentication, we do not control
> >   anything except the user name itself; luckily, a user name of length
> >   ~128KB (shorter than DEFAULT_MMAP_THRESHOLD) allows us to store our
> >   own data at address 0x08100000.
> >
> > [...]
> >
> > Finally, our long user name also allows us to control the potentially
> > uninitialized next field of 20 different structures (through leftovers
> > from temporary copies of our long user name), because pam_start() calls
> > _pam_add_handler() multiple times; i.e., our large race window contains
> > 20 small race windows.
> >
> > [...]
>
> 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
...

> There may actually be a case for putting the user name into a static
> buffer here:  its length should be limited anyway to prevent abuse and
> keeping it away from the heap may be helpful as a defense-in-depth measure.
>
> If there currently really is no limit at all, outrageously long fake
> usernames (limited only by bandwidth and LoginGraceTime?) could be
> directly used for a simple denial-of-service by consuming memory on the
> server, given sufficient bandwidth available to an attacker.

Jeff