[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 02 Jul 2024 21:01:48 -0500
From: Jacob Bachmeyer <jcb62281@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: CVE-2024-6387: RCE in OpenSSH's server, on glibc-based
Linux systems
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.
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
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.
