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.