Hi All

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


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:


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.

Reply via email to