[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH8yC8=zAGQsdCXPRM3LJsoMJS+AhXLJ01awX4k3DpTbxoMqWg@mail.gmail.com>
Date: Wed, 3 Jul 2024 02:54:28 -0400
From: Jeffrey Walton <noloader@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: CVE-2024-6387: RCE in OpenSSH's server, on
glibc-based Linux systems
On Wed, Jul 3, 2024 at 2:39 AM Jacob Bachmeyer <jcb62281@...il.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
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.
