Date: Sat, 25 Aug 2018 12:01:49 +0200 From: Solar Designer <solar@...nwall.com> To: oss-security@...ts.openwall.com Subject: Re: About OpenSSH "user enumeration" / CVE-2018-15473 On Sat, Aug 25, 2018 at 10:32:12AM +1000, Damien Miller wrote: > On Fri, 24 Aug 2018, Solar Designer wrote: > > On Fri, Aug 24, 2018 at 10:58:20AM +1000, Damien Miller wrote: > > > Finally, and perhaps most importantly: there's a fundamental tradeoff > > > between attack surface and fixing this class of bug. As a concrete > > > example, fixing this one added about 150 lines of code to our > > > pre-authentication attack surface. In this case, we were willing to do > > > this because we had confidence in the additional parsing, mostly because > > > it's been reviewed several times and we've conducted a decent amount of > > > fuzzing on it. But, given the choice between leaving a known account > > > validity oracle or exposing something we don't trust, we'll choose the > > > former every time. > > > > Can you summarize for us all (on these mailing lists) the commits > > leading to OpenSSH 7.8 that deal with this issue and add "about 150 > > lines of code", please? > > It's this one: > > > * sshd(8): avoid observable differences in request parsing that could > > be used to determine whether a target user is valid. > > (Commit 74287f5df9) This is the same commit that Qualys referenced, but in a different tree: https://github.com/openssh/openssh-portable/commit/74287f5df9966a0648b4a68417451dd18f079ab8 > Note that there's no new code added, but delaying the checks means more > code is exposed before the authentication handler bails out. Oh, right. Thanks. However, exposing more code before one specific authentication attempt bails out isn't necessarily as bad as adding that code to the attack surface: some or all of this code might have already been exposed under different usernames. To be confident we're only reaching code that's already exposed under a different username, we may replace the tested-non-existent username with that existing username and also set a flag to force authentication to fail later. Yes, more checks would then be run when authenticating with an unknown username, but those wouldn't add to attack surface as they were reachable with that other username anyway. This doesn't have to be literally all conditions and checks - it may be sufficient to match behavior for one certain existing username. 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. 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.