Date: Sun, 19 Oct 2014 11:32:22 -0400
From: Jeffrey Walton <noloader@...il.com>
To: Lord Tuskington <l.tuskington@...il.com>
Cc: Full Disclosure List <fulldisclosure@...lists.org>
Subject: Re: [FD] Cyanogenmod MITM: proven,
	despite cyanogenmod's public denail

> 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