Adam Shostack said:
>| Candidate: CAN-1999-0248
>| Published:
>| Final-Decision:
>| Interim-Decision:
>| Modified:
>| Announced: 19990728
>| Assigned: 19990607
>| Category: SF
>|
>| sshd 1.2.17 can be compromised through the SSH protocol.
>|
>
>| VOTE: modify http://oliver.efri.hr/~crv/security/bugs/mUNIXes/ssh2.html
>looks to me to be about the correct message that came from Tatu.
>There are comments in changelog: * Improved the security of
>auth_input_request_forwarding().
>
>I'm not in favor of moving this forward without additional detail, but
>thought I'd add a confirming URL and comment. We have insufficient
>detail to accept it as a CVE.
There are a number of other candidates like this, where there is very
little detail available. But in this case, I believe it's
sufficiently verified that there is *some* sort of vulnerability, we
just don't know what. I will be proposing CAN-1999-0001 shortly,
which has a similar problem. When I get a chance, I'll try to find
some other examples.
Some software vendors are quite secretive about the nature of
vulnerabilities that they discover on their own, especially if there
isn't evidence that it's known to anyone else. But they will confirm
that there's a vulnerability.
There is a tension here between the sysadmin perspective (i.e. wanting
to know about what vulnerabilities may be on their system) versus the
perspective of having mature, publicly known information. The
sysadmin perspective argues for inclusion in the CVE, but the maturity
perspective argues for exclusion. Which should be preferred? There's
also the tension between precision and completeness. We can't be very
precise about the nature of this particular vulnerability, but on the
other hand, leaving out a confirmed vulnerability will render the CVE
incomplete.
I think that if a vulnerability is confirmed by the software vendor,
then that should be sufficient for inclusion into the CVE (at the very
least, a candidate that remains in Proposal phase). If the security
tool vendors are taken to task for not detecting that particular CVE,
then they will have a strong argument (as confirmed by Editorial Board
discussions and/or candidate annotations?) that they cannot perform
that detection because there is not sufficient information available.
In the short term, I don't think we'll be able to get away from the
fact that some information sources will not provide sufficient
vulnerability information even for a good description in the CVE. But
as long as the description is distinctive - as it is in the above
candidate, using the SSH version number - then there is some record
that a vulnerability does exist.
- Steve