oss-sec mailing list archives

[Ignore not a security flaw] Re: [oss-security] CVE Request -- jakarta-commons-httpclient: Wildcard matching in SSL hostname verifier incorrect (a different issue than CVE-2012-5783)


From: Jan Lieskovsky <jlieskov () redhat com>
Date: Tue, 12 Feb 2013 08:52:58 -0500 (EST)

Hello vendors,

  taking back. Looks like we have previously
investigated this issue with the following conclusion:

/* Should HTTPCLIENT-1255 one be also classified as (another) CVE id? */

It is my understanding that this bug will cause valid certificates to be rejected, but not for invalid certificates to 
be accepted. Therefore I do not think it qualifies for a CVE ID.

=> not a security flaw. Ignore my previous request.

Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Response Team

----- Original Message -----
Hello Kurt, Steve, vendors,

  Originally, Common Vulnerabilities and Exposures
assigned an identifier CVE-2012-5783 to the following
vulnerability:

Apache Commons HttpClient 3.x, as used in Amazon Flexible
Payments Service (FPS) merchant Java SDK and other products,
does not verify that the server hostname matches a domain
name in the subject's Common Name (CN) or subjectAltName field
of the X.509 certificate, which allows man-in-the-middle
attackers to spoof SSL servers via an arbitrary valid certificate.

Later it was found, that the SSL hostname verifier implementation
(CVE-2012-5783 fix) contained a bug in wildcard matching:
[1] https://issues.apache.org/jira/browse/HTTPCLIENT-1255

which still allowed certain type of certificates checks to pass,
even if they shouldn't.

Relevant upstream patches:
[2] https://fisheye6.atlassian.com/changelog/httpcomponents?cs=1406213
    (against 4.2.x branch)
[3] https://fisheye6.atlassian.com/changelog/httpcomponents?cs=1406217
    (against trunk)

References:
[4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700268
[5] https://bugzilla.redhat.com/show_bug.cgi?id=910358

Could you allocate a CVE id for this?

Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Response Team


Current thread: