Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20141019142607.GG1712@dojo.mi.org>
Date: Sun, 19 Oct 2014 10:26:07 -0400
From: "Mike O'Connor" <mjo@...o.mi.org>
To: oss-security@...ts.openwall.com
Subject: Re: CVE request: Cyanogenmod MITM

If an opensource project explicitly designates a "stable" release
train, is the reasonable expectation that the stable release gets
minimally-invasive pertinent backported security fixes from its
development tree?  I think most of the users would say yes and
most of the developers would rather work on the latest code.  :)

In the Cyanogenmod case, as of today, 10.2 is labelled as "stable".
Judging from the updates I've seen on my Cyanogenmod tablet, CM 11
"releases" are pre-beta snapshots.  Would you, as a Cyanogenmod user,
expect that 10.2 get security fixes?  FWIW, late last year, that's
what Cyanogenmod said they'd do:

http://www.cyanogenmod.org/blog/cyanogenmod-10-2-0-release

but if I were to judge from this, that's fallen by the wayside.  

This certainly isn't an issue limited to Cyanogenmod.  As just another
example, release of ntpd deemed "stable"/"production" is 3 years old,
and missing the fix for the monlist amplication vulnerability (though
granted that has workarounds).  

It mught behoove us to call out opensource projects whose "stable"
releases are way out-of-date with respect to their security exposure.

-Mike

: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. 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.
:Regards
:
:Lord Tuskington
:Chief Financial Pinniped
:TuskCorp

-- 
 Michael J. O'Connor                                          mjo@...o.mi.org
 =--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--=
"If death is not the end, I'd like to know what is."         -Robyn Hitchcock

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.