[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.BSO.2.21.1808241046220.67512@haru.mindrot.org>
Date: Fri, 24 Aug 2018 10:58:20 +1000 (AEST)
From: Damien Miller <djm@...drot.org>
To: openssh-unix-dev@...drot.org
cc: oss-security@...ts.openwall.com
Subject: About OpenSSH "user enumeration" / CVE-2018-15473
Hi,
Regarding CVE-2018-15473: a few people have asked why we just committed
a fix for this without any secrecy or treating it as a security
problem. The reason is that I and the other OpenSSH developers don't
consider this class of bug a significant vulnerability - it's a partial
disclosure of non-sensitive information.
We have and will continue to fix bugs like this when we are made aware
of them and when the costs of doing so aren't too high, but we aren't
going to get excited about them enough to apply for CVEs or do security
releases to fix them. The following explains our reasoning.
First, this isn't "user enumeration" because it doesn't yield the
ability to enumerate or list accounts. It's an oracle; allowing an
attacker to make brute-force guesses of account names and verify whether
they exist on the target system. Each guess is moderately expensive,
requiring 1 x TCP connection and a cryptographic key exchange, limited
in concurrency by sshd's MaxStartups limit.
Second, very little else in the Unix ecosystem tries to prevent this
style of information disclosure. Many network daemons will still happily
return "user not found" style messages, but more importantly: system
libraries are simply not designed to consider this as a threat. They
don't consider it a threat because usernames have long been considered
the non-secret part of user identity, of limited use without actual
authentication credentials.
In the absence of the underlying system stack being designed with this
in mind, the best applications like sshd can do is try to paper over
the most obvious differences by avoiding behaviour divergences in our
own code and adding some prophylactic timing delays, but it's a losing
battle.
Does getpwnam() offer invariant behaviour? How about libpam? And all the
modules PAM invokes? How about libgssapi? (etc. ad nauseam). AFAIK few,
if any of these, have been engineered to avoid behaviour differences
between existing and non-existing users. I'm not just talking about
gross timing differences, but any access patterns that can be discerned
at a distance, including CPU usage or filesystem access. If someone
brought the cryptanalyist's arsenal to bear against username validity
then all these are on the table.
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.
-d
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.
