Bug#692650: Patches for CVE-2012-5783 and CVE-2012-5784

[Alberto Fernández]

Hi

I've reopened the two bugs.

The first patch was incomplete, as pointed by David and by other bug
i've found reviewing the code.

The bug pointed by David can occur in  some rare cases where the CA
issues malformed certificates. It's rare, but there are may CA...
The other bug it's about  wildcard certificate validation. The first
patch incorrect validates some cases. They're also rare cases of
certificates of type *.xxx.com.

Both are very rare cases, but I think they must be fixed before release.

In outline, hosts name correctly validated:
original -> 0% (no validation at all)
first patch -> ¿99%? 
   Never fails with valid certificates, 
   block majority of invalid request.
   allow few rare cases which should be blocked
second patch -> 100%. I hope.


Thanks for your patience

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#692650: Patches for CVE-2012-5783 and CVE-2012-5784

[Alberto Fernández]

Hi

I've uploaded new packages to mentors. I'll be out until Monday, so feel
free to review the patches and sponsor the new version if all you are
confident it's all ok

I think now it's fine , but if you find some other bug or improvement,
I'll be happy to correct it.

I'll insist next week upstream to include the last fix.

El jue, 06-12-2012 a las 13:58 +0100, Andreas Tille escribió:
> Hi Alberto,
> 
> thanks for your continuous work on this.  As I said in my previous mail
> please remember to reopen the according bugs to make sure the previous
> solution will not migrate to testing.  I'll volunteer to sponsor your
> new version if you confirm that this is needed to finally fix the issue.
> 
> Kind regards
> 
>Andreas.
> 
> On Thu, Dec 06, 2012 at 01:49:07PM +0100, Alberto Fernández wrote:
> > Hi All,
> > 
> > I've prepared the patch with the problem pointed by David fixed (thanks
> > David). It also fixes a bug related to wildcard certificates.
> > 
> > The first patch is backported from httpclient 4.0 and apache synapse. 
> > 
> > This second patch backports some fixes from httpclient 4.2
> > 
> > The patch differ a lot from 4.x line for two reasons: first, the code
> > arquitecture changes, second , I want to mantain the 3.1 api unchanged,
> > so all methods are private and only apply to one class.
> > 
> > The patch for axis and commons-httpclient is the same. In the function
> > they create a SSLSocket, I've put the same routine to validate the
> > hostname against certificate valid names.
> > 
> > I'll upload the new patches in their place.
> > Please review them and when ready I can upload a new package to mentors.
> > 
> > Thanks
> > 
> > 
> > 
> > 
> > 
> 

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#692650: Patches for CVE-2012-5783 and CVE-2012-5784

[Andreas Tille]

Hi,

thanks for the additional information.  Please note that I uploaded the
NMUed packages yesterday.  In case the "just one small issue" mentioned
by David below is serious above please reopen the bug report to prevent
migration to testing (I also filed unblock request bugs).

Kind regards

   Andreas.

On Thu, Dec 06, 2012 at 01:58:11PM +1000, David Jorm wrote:
> Hi All
> 
> The upstream patch for CVE-2012-5783 referred to in Red Hat bugzilla:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=873317#c3
> 
> Is the 4.x patch. As you've noted, there is no 3.x patch available
> and upstream won't provide one because it is EOL. I think Alberto's
> patch looks sane (from a brief check) with just one small issue. In
> this section:
> 
> +private static String getCN(X509Certificate cert) {
> +  // Note:  toString() seems to do a better job than getName()
> +  //
> +  // For example, getName() gives me this:
> +  // 
> 1.2.840.113549.1.9.1=#16166a756c6975736461766965734063756362632e636f6d
> +  //
> +  // whereas toString() gives me this:
> +  // EMAILADDRESS=juliusdav...@cucbc.com
> +String subjectPrincipal =
> cert.getSubjectX500Principal().toString();
> +int x = subjectPrincipal.indexOf("CN=");
> +if (x >= 0) {
> +int y = subjectPrincipal.indexOf(',', x);
> +// If there are no more commas, then CN= is the last entry.
> +y = (y >= 0) ? y : subjectPrincipal.length();
> +return subjectPrincipal.substring(x + 3, y);
> +} else {
> +return null;
> +}
> +}
> 
> If the subject DN includes something like "OU=CN=www.example.com",
> this function will treat it as a CN field. An attacker could use
> this to spoof a valid certificate and perform a man-in-the-middle
> attack. An attacker could get a trusted CA to issue them a
> certificate for CN=www.ownedbyattacker.com but then include in the
> CSR OU=CN=www.victim.com or include a subject DN element
> emailAddress="CN=www.victim.com,@ownedbyattacker.com". The attacker
> could then use this certificate to perform a MITM attack against
> victim.com.
> 
> This would of course rely on the CA allowing such a certificate to
> be issued, but I think it is highly likely an attacker could find a
> widely trusted CA that allowed this, while they couldn't get a
> trusted CA to issue them a certificate for CN=www.victim.com. I have
> already brought this flaw in the initial 4.x patch to the attention
> of upstream, and they have addressed it via the following commit:
> 
> http://svn.apache.org/viewvc?view=revision&revision=1411705
> 
> In my view the ideal solution would be to resolve the issue I noted
> above, and then have upstream commit the patch even if there is no
> further 3.x release, so at least all distributions can consume the
> patch from the upstream tree.
> 
> Regarding CVE-2012-5784, I need some more time to review the patch
> attached to AXIS-2883. Please stay tuned for more details.
> 
> Thanks again to Alberto for providing these patches!
> --
> David Jorm / Red Hat Security Response Team
> 

-- 
http://fam-tille.de

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#692650: Patches for CVE-2012-5783 and CVE-2012-5784

[David Jorm]

Hi All

The upstream patch for CVE-2012-5783 referred to in Red Hat bugzilla:

https://bugzilla.redhat.com/show_bug.cgi?id=873317#c3

Is the 4.x patch. As you've noted, there is no 3.x patch available and 
upstream won't provide one because it is EOL. I think Alberto's patch 
looks sane (from a brief check) with just one small issue. In this section:


+private static String getCN(X509Certificate cert) {
+  // Note:  toString() seems to do a better job than getName()
+  //
+  // For example, getName() gives me this:
+  // 
1.2.840.113549.1.9.1=#16166a756c6975736461766965734063756362632e636f6d

+  //
+  // whereas toString() gives me this:
+  // EMAILADDRESS=juliusdav...@cucbc.com
+String subjectPrincipal = 
cert.getSubjectX500Principal().toString();

+int x = subjectPrincipal.indexOf("CN=");
+if (x >= 0) {
+int y = subjectPrincipal.indexOf(',', x);
+// If there are no more commas, then CN= is the last entry.
+y = (y >= 0) ? y : subjectPrincipal.length();
+return subjectPrincipal.substring(x + 3, y);
+} else {
+return null;
+}
+}

If the subject DN includes something like "OU=CN=www.example.com", this 
function will treat it as a CN field. An attacker could use this to 
spoof a valid certificate and perform a man-in-the-middle attack. An 
attacker could get a trusted CA to issue them a certificate for 
CN=www.ownedbyattacker.com but then include in the CSR 
OU=CN=www.victim.com or include a subject DN element 
emailAddress="CN=www.victim.com,@ownedbyattacker.com". The attacker 
could then use this certificate to perform a MITM attack against victim.com.


This would of course rely on the CA allowing such a certificate to be 
issued, but I think it is highly likely an attacker could find a widely 
trusted CA that allowed this, while they couldn't get a trusted CA to 
issue them a certificate for CN=www.victim.com. I have already brought 
this flaw in the initial 4.x patch to the attention of upstream, and 
they have addressed it via the following commit:


http://svn.apache.org/viewvc?view=revision&revision=1411705

In my view the ideal solution would be to resolve the issue I noted 
above, and then have upstream commit the patch even if there is no 
further 3.x release, so at least all distributions can consume the patch 
from the upstream tree.


Regarding CVE-2012-5784, I need some more time to review the patch 
attached to AXIS-2883. Please stay tuned for more details.


Thanks again to Alberto for providing these patches!
--
David Jorm / Red Hat Security Response Team

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#692650: Patches for CVE-2012-5783 and CVE-2012-5784

[Alberto Fernández]

Hi,

I've uploaded the two packages to mentors.debian.net.

We must solve the two bugs at the same time because axis uses
commons-httpclient.

Upstream seems End-of-life and rejected the patches.

El mié, 05-12-2012 a las 16:43 +0100, Andreas Tille escribió:
> Hi,
> 
> seems the package is ready for an upload.  Any reason why this is not
> done?  I could sponsor an upload or NMU if this would help.
> 
> Kind regards
> 
>   Andreas.
> 

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#692650: Patches for CVE-2012-5783 and CVE-2012-5784

[Andreas Tille]

Hi,

seems the package is ready for an upload.  Any reason why this is not
done?  I could sponsor an upload or NMU if this would help.

Kind regards

  Andreas.

-- 
http://fam-tille.de

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.