[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 03 Jul 2024 19:58:25 -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
Jeffrey Walton wrote:
> On Wed, Jul 3, 2024 at 2:39 AM Jacob Bachmeyer <jcb62281@...il.com> wrote:
>
>> Qualys Security Advisory wrote:
>>
>>> [...]
>>>
>> 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
> ...
>
I see. So there is a declared system limit (apparently 256 bytes on GNU
systems, but allowed to be as low as 9 bytes in POSIX) on the length of
a valid user name. Why does sshd not, as a defense-in-depth measure,
immediately drop the connection if a user name longer than that limit is
received? ("We had not thought of that." is a perfectly good answer
here, of course.)
Solar Designer mentioned a previous patch that avoided sending
excessively long user names to PAM in response to a PAM implementation
that apparently has exploitable overflows. I would suggest adding
another check using LOGIN_NAME_MAX as the limit to the code where the
user name is first received. If a user name that cannot possibly be
valid on the system is received, drop the connection immediately without
further parsing. This would potentially add a risk for fingerprinting
based on LOGIN_NAME_MAX, but that is probably minor compared to other
ways to identify a remote OS and this check would have prevented the
presented Ubuntu 6.06.1 exploit of this issue. It might make other,
yet-to-be-found issues infeasible to exploit.
I argue for it as a defense-in-depth measure.
-- 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.
