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

Programs affected: libxslt-1.1.24 and some earlier versions.
Severity: Execution of evil stylesheets may result in arbitrary code execution.

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"
extension-element-prefixes="str crypto math">
<xsl:template match="/">


CESA-2008-003 - rev 1
Chris Evans