Re: OpenSSH J-PAKE vulnerability (no cause for panic! remain calm!)

[mancha <mancha1 () hush com>]

Kurt Seifried <kseifried@...> writes:
> On 01/29/2014 06:50 AM, cve-assign@... wrote:
> > Use CVE-2014-1692. The CVE description will indicate that the
> > issue requires an unusual installation.
> >
> > > As I understand it this can be enabled via code edit/gcc command
> > > line options, so not sure if this qualified for a CVE or not
> > > (vuln in code, yes, is code reachable? not under any default
> > > setup, and even on non-default you have to go pretty far off to
> > > enable it).
> >
> > An impact on the default installation isn't necessary.
> > Vulnerabilities that occur only after the user modifies code aren't
> > eligible for a CVE. However, if there's some type of "installation
> > option" mentioned by the vendor, someone may have chosen that
> > option, and it may be worthwhile to track the issue with a CVE. The
> > nature of an "installation option" obviously varies widely across
> > both open-source and closed-source products.
> >
> > In this case, there's:
> >
> > > http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/Makefile.inc
> >
> > >  Add support for an experimental zero-knowledge password
> > > authentication method using the J-PAKE protocol ...
> >
> > > This is experimental, work-in-progress code and is presently 
> > > compiled-time disabled (turn on -DJPAKE in Makefile.inc).
> >
> > >
http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr.bin/ssh/Makefile.inc?rev=1.41;content-type=text%2Fplain
> > >  #CFLAGS+= -DJPAKE
> >
> > This is close to the edge of what "installation option" means, but
> > our feeling is that the vendor wouldn't have provided that #CFLAGS
> > line at all unless it were expected that an end user might want to
> > make the one-character change.
>
> Just to close this email thread, Mitre assigned one:
>
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-1692

This CVE assignment puzzles me. Relevant code was: 1) never enabled,
2) never advertised in release notes, and 3) never had a
configuration option. To enable it, a user would have to pro-actively
edit code (more than merely a configure flag). Note: I *did* read
MITRE's justification on this last point.

Also, an attacker would need to make EVP_Digest* fail. Is there
a known way to achieve this?

Finally, the NVD entry
(https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-1692)
doesn't make sense. J-PAKE experimental code wasn't in the code-base
until OpenSSH 5.2 (iirc) yet versions back to 1.2 are listed as
vulnerable. Also, a CVSS score of 7.5 (High)? I know this is 
orthogonal to the actual CVE assignment. Still...weird.

I don't have a horse in this race but the entire situation strikes
me incongruent.

--mancha