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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
