[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20180826120058.GA7071@openwall.com>
Date: Sun, 26 Aug 2018 14:00:58 +0200
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: About OpenSSH "user enumeration" / CVE-2018-15473
On Sun, Aug 26, 2018 at 06:04:50PM +1000, Damien Miller wrote:
> On Sat, 25 Aug 2018, Solar Designer wrote:
>
> > This could mean an extra getpwnam(3) call, which is a slightly greater
> > timing leak than what's present in one call. That may be further
> > mitigated by always doing two calls. Of course, this won't be anywhere
> > near timing-safe anyway.
> >
> > Now, it can be tricky to pick a specific fallback username in
> > OpenSSH-portable that we'd be OK with all non-existent usernames to
> > behave similarly to. "root" may somewhat likely have unusual password
> > hash (like it historically did on OpenBSD); "nobody" likely has its
> > password locked (but maybe that's OK - it is in fact common for SSH
> > users to have only public keys setup, and no passwords). Maybe there
> > should be a way to override this dummy username in sshd_config.
>
> That sounds like a fair amount of complexity in return for scant
> benefit:
Thank you for sharing your opinion.
To me, it sounds like greater complexity of the resulting code, but it's
also a simpler change (higher level, easier to reason about) than your
previously discussed commit. (And it avoids the need for further
reviews/changes dealing with maybe remaining worse-than-timing behavior
differences for existing vs. non-existent usernames, except for users
with non-default authentication settings - e.g., with authorized_keys
files or on DenyUsers.)
> at best you dodge a few (IMO uninteresting) bugs, but now you
> are guaranteed to have all your authz code exposed to a the attacker.
This sounds like a misunderstanding. With the approach I suggested,
no extra pre-existing code would be exposed to any attacker (only very
few newly added lines of code would be), because all of that code would
have been reachable under the fallback username anyway.
> Moreover, using a "real fake" account gives a timing / system behaviour
> baseline too.
I'm not sure if that's what you meant, but yes it could be possible to
see that the response time for non-existent users is nearly the same,
whereas for other usernames it would vary slightly. This is similar to
other (currently possible) attacks on getpwnam(3) not being timing-safe.
Your recent "global 5ms minimum plus an additional per-user 0-4ms delay
derived from a host secret" time for failed authentication should help
mitigate this. [A further (yet still imperfect) mitigation would be to
replace the nanosleep() with a busy wait (which would be a closer match
to a system function taking longer to do its work, but still not exactly
the same in terms of effect e.g. on concurrent authentication attempts).
I am not sure if this further imperfect improvement is a good trade-off.
With nanosleep(), we conserve server resources and energy.]
> It might be harder to discern, but techniques for making
> remote observations of subtle system side-channels are scarily well-
> developed, and I'm sure that it would be pretty easy to spot if people
> applied them.
Right. It's unrealistic to fully prevent such attacks given the
existing non-timing-safe system interfaces.
Anyway, I don't insist on any specific approach (nor would my preference
matter all that much), especially now that you've already made relevant
changes in the way you did. I merely wanted to point out that the
attack surface increase was not certain (maybe that code was already
exposed under other usernames, also pre-authentication) and could have
been avoided with greater confidence using that other approach.
Alexander
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.
