Buffer overflow in libxslt

libxslt is an interesting attack surface; there are various places in which it is used to process untrusted stylesheets. This includes some browsers, although namespace issues seem to prevent the affected code from being reached in a browser context.

Within libxslt itself, there are some built-in functions. These are usually a fruitful place to look for vulnerabilities, particularly those that take integers etc. In this instance, I found problems in a little used cryptography related extension function. An incoming string is over-trusted in that its length is not sanitized, leading to a heap overflow.

XSLT, surprisingly, is turing-complete, even in its currently deployed incarnations (although you need to implement looping via recursion). There may be interesting DoS and further exploitation opportunities here.

Full technical details can be found here:
http://scary.beasts.org/security/CESA-2008-003.html

On FTP, SSL and broken interfaces

Oh what a fun day I just had piecing together a few SSL changes for vsftpd!

Let's start with a brief background on SSL. SSL provides not just secrecy but also integrity - an attacker cannot change your data stream in flight. This includes obviously changing data in the stream, and less obviously, truncating the stream. The interesting attack to truncate the stream is to fake a TCP packet with FIN set. Truncated data is still an integrity violation and could have interesting consequences depending on what is being transferred. Anyway, as of SSLv3 and newer, the protocol protects against this. So, we're all good right?

Well, no, not really. Let's look at how SSL_read() indicates a problem. We all know how read() behaves, of course. It returns 0 on a healthy EOF. SSL_read() does the same on a healthy, cryptographically guaranteed EOF. But what does it do it if the attacker forces the TCP stream to close with a faked FIN? It also returns 0. That's right - no indication of any problem at the API level. If you want to check what is going on, you need to either check the SSL error code, in case there is one, or call SSL_get_shutdown(). (This double option in itself leads to confusion and random variance in code, which isn't great but that's another topic).

The OpenSSL API for SSL_read() is broken. You can phrase why in various ways: it violates the principle of least surprise. Or, perhaps best said, it provides an API that is easy to abuse. Good, secure APIs are hard to abuse. Contrast strcat() with string::operator+=() for the classic example.

A quick survey of popular FTP servers reveals that they universally fail to check for this condition when accepting an SSL secured upload. vsftpd v2.0.7 now optionally checks for this condition but it is off by default! Why? The majority of FTP clients have an interoperability bug in that they don't SSL_shutdown() their uploads. It's a direct knock-on from the SSL_read() broken API. If it returned error on forced connection shutdown, then FTP servers wouldn't have ever tolerated buggy clients, and clients would have been forced to correctly shutdown their connections.

Thanks to Tim Kosse of FileZilla fame for putting me on to this area by checking for secure connection shutdown in the latest version of FileZilla, exposing an interoperability bug in vsftpd's SSL downloads.

Lame OpenOffice PCX crash

Sorry for the lame vuln. It's something I was playing with over a year ago and I just happened to notice it got fixed. I forget what the original deal was. I'm only posting because this blog serves as an RSS feed for the scary.beasts.org main vuln list.

http://scary.beasts.org/security/CESA-2008-006.html

A more interesting OpenOffice observation is in the works.

Fancy an exploitation challenge?

So you think you're 1337? Check out these just released details of a buffer overflow in bzip2:

http://scary.beasts.org/security/CESA-2008-005.html

It looks pretty harmless, and it probably is... but I'd love for it not to be... if you think you have what it takes.

iPhone Safari update fixes old libxslt version

This story is both interesting and boring at the same time.

Boring because I didn't find anything new -- I just noted the applicability of something old to Apple's Safari. I've made sure to credit the finder of the old bug that applies to Safari; unfortunately not everyone in the security industry credits the original finder of the bug when noting it applies to a new context.

The story is interesting because it illustrates the ongoing challenge of depending upon complex open source libraries. As these move forward, you need a good way of keeping on top. The public nature of their bug repositories are a challenge; frequently, some user will log a "crash" bug which in fact has serious security consequences. These consequences may not immediately be realized and called out, in the bug report, change log or release announcement.

http://scary.beasts.org/security/CESA-2008-004.html

http://lists.apple.com/archives/security-announce/2008/Jul/msg00001.html