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

-- 
http://fam-tille.de