Qualys Security Advisory wrote:
Qualys Security AdvisoryregreSSHion: 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.
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.
-- Jacob
