Bug#692442: 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=juliusdavies at 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, at 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