Message-ID: <CAGGN9ed43efiLqPSwekdKdsVgC6d+ROfu4h271o9Cc20YV4xFQ@mail.gmail.com>
Date: Mon, 20 Oct 2014 08:25:27 +1000
From: Lord Tuskington <l.tuskington@...il.com>
To: noloader@...il.com
Cc: Full Disclosure List <fulldisclosure@...lists.org>
Subject: Re: [FD] Cyanogenmod MITM: proven,
	despite cyanogenmod's public denail

The exploit is the same as for this issue:

http://mail-archives.apache.org/mod_mbox/www-announce/201408.mbox/CVE-2014-3577

i.e.:

It parsed the entire subject distinguished name (DN)
for the occurrence of any <CN=> substring (regardles of field).

Therefore a DN of with a O field such as

                  O="foo,CN=www.apache.org”

and a CN of "www.evil.org” and ordered such that the O appears prior to
the CN field would incorrectly match match on the <www.apache.org> in
the O field as opposed to just the values in the CN and alternative
subject name(s).

The doctored field can be any field but the CN field itself; including
the <E> or emailAddress field as long as it appears before the CN (some
CAs reorder the DN).

All versions of CM prior to 11.0 M11 are vulnerable.

Lord Tuskington
Chief Financial Pinniped
TuskCorp

On Mon, Oct 20, 2014 at 1:32 AM, Jeffrey Walton <noloader@...il.com> wrote:

> > Re: [FD] Cyanogenmod MITM: proven, despite cyanogenmod's public denail
>
> Its not clear to me where its been proven. I think your post is
> missing some information, like the smoking gun. (It may exist, you
> just didn't make it clear).
>
> > If I understand correctly, the original reporter may have been referring
> to
> > a vulnerability fixed by this commit, which was merged 20 days ago:
> >
> >
> https://github.com/CyanogenMod/android_external_apache-http/commit/f925f10b1feba92868fd4e8966592ec1bf755d67
>
> If I am reading the check-in correctly, it does not look like its a
> MitM. Checking the CN to ensure a hostname match should be OK. But I
> should probably read a bit more about the DistinguishedNameParser.
>
> However, it is a policy violation of both the IETF and CA/Browser
> Forums. Both the IETF and CA/B deprecated using a DNS name in the CN.
> Rather, all DNS names should be placed in the Subject Alternate Name
> (SAN). The SAN allows for multiple DNS names (like example.com,
> www.example.com and mail.example.com), and not just one name like in
> the CN.
>
> *If* a DNS name is placed in the CN, then the same name must be
> present in the SAN. That's another policy violation, and its one of
> the reasons Chrome rejects so many certificates. I expect Firefox will
> start rejecting them too since its a CA/B requirement.
>
> You can refer to RFC 5280, RFC 6125 and the CA/Browser Baseline
> Requirements for reference, if interested.
>
> Related: CA's and Browsers follow their own rules from the CA/Browser
> Forums. They don't follow IETF policies. So its usually a mistake to
> apply IETF-based validation to a CA issued certificate on the
> internet. And its why seemingly good certificates fail to validate in
> the browsers.
>
> Jeff
>
> On Sat, Oct 18, 2014 at 8:03 PM, Lord Tuskington <l.tuskington@...il.com>
> wrote:
> > After reading el reg's article regarding a cyanogenmod MITM flaw, I
> started
> > looking through the code to see if I could find it. It didn't take long.
> > This finding was not what users are led to believe by cyanogenmod's blog
> > post:
> >
> > http://www.cyanogenmod.org/blog/in-response-to-the-register-mitm-article
> >
> > I reported the issue to cyanogenmod, but got a rather unsatisfactory
> reply.
> > They didn't seem willing to modify the blog post to more accurately
> reflect
> > the problem. Below is my email exchange with cyanogenmod's security
> address:
> >
> >  Lord Tuskington,
> >
> >  Thank your for your response. Truth is we assumed as much, but the lack
> of
> > meaningful information in the Register's sensational article didn't leave
> > us much room to interpret it besides what it presented at face value.
> >
> >  As you noted, this has already been addressed in our shipping code
> branch
> > (cm-11), prior to the article's publishing. This was the net result of
> the
> > messaging provided in the blog post, with CM 11 being 'safe' from this
> > issue.
> >
> >  We normally do not patch non-shipping code (in this case 10.2 and
> prior),
> > though we may in this case.
> >
> >  We do not expect to make a advisory on the 10.2 item at this time.
> >
> >  Thank you,
> > Abhisek Devkota
> >
> >   On Oct 17, 2014 8:50 PM, "Lord Tuskington" <l.tuskington@...il.com>
> wrote:
> >   Hello from Greenland!
> >
> > I think you may be confused about the issue discussed here:
> > http://www.cyanogenmod.org/blog/in-response-to-the-register-mitm-article
> >
> > If I understand correctly, the original reporter may have been referring
> to
> > a vulnerability fixed by this commit, which was merged 20 days ago:
> >
> >
> https://github.com/CyanogenMod/android_external_apache-http/commit/f925f10b1feba92868fd4e8966592ec1bf755d67
> >
> > The vulnerable code is still present in the cm-10.2 branch:
> >
> >
> https://github.com/CyanogenMod/android_external_apache-http/blob/cm-10.2/src/org/apache/http/conn/ssl/AbstractVerifier.java#L228-244
> > If you release an advisory, please credit "Lord Tuskington of TuskCorp"
> for
> > reporting this vulnerability responsibly.
> >
>

_______________________________________________
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists