Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6684B10C.3070904@gmail.com>
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.