On Wed, Jul 3, 2024 at 2:39 AM Jacob Bachmeyer <jcb62...@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
