Sun JDK image parsing vulnerabilities

The technical details for this pair of vulnerabilities can be found here:

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

These vulnerabilities follow on from my original advisory in this area:

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

There are lots of interesting sub-stories here.

The first is that exploitation of the heap buffer overflows (in both the old and new advisories) relies on that fact that the JDK environment has a SEGV handler installed. These particular heap overflows will always try and perform massively long copies, therefore faulting as part of the copy. This would be a DoS only apart from the SEGV handler. As part of trying to dump out a good crash report, it can access trashed memory and become an exploitable condition.

The second is that this is a very dangerous class of attack. Most previous JDK attacks apply to running untrusted applets. These bugs, however, trigger also in server-side environments where JPEG parsing is performed. Direct, data-driven compromise of servers is quite unfortunate, especially in a runtime environment where memory corruptions can't usually occur.

Buffer overflow in Ghostscript

Given the huge amount of attention given to xpdf (and derivatives), it is surprising that not as much attention has been given to Ghostscript. Most Linux desktops will render both PDF and PS files directly from the web.

The attack surface of Ghostscript is huge. Not only is it a Turing Complete language[*], but it has a rich set of runtime operators and APIs. Many of these operators and APIs stray into areas of functionality that might be integer overflow prone: decompressors, image parsers, graphics rending, canvas handing, etc.

I've placed technical details of a buffer overflow at:
http://scary.beasts.org/security/CESA-2008-001.html

[*] Client-side execution of such languages has never gone particularly well from a security perspective. Think Java applets, or Javascript.

Your FTP / SSL solution is really secure, right?

Well no, not really. Almost all real-world usage of FTP over SSL has problems whereby the FTP data connection can be stolen (resulting in stolen downloads or forged uploads). The problem is mainly with FTP clients - if you require end users to generate their own SSL certs and manually enable sending them to the server, you've already lost on usability grounds.

Full technical details at http://scary.beasts.org/security/CESA-2008-002.html

Sun JDK6 XXE protection broken

Sun released JDK6u4 which fixes a possibly nasty issue where one of the XXE protection methods for the default XML parser was broken.

My advisory is at http://scary.beasts.org/security/CESA-2007-002.html

Sun's advisory is at http://sunsolve.sun.com/search/document.do?assetkey=1-66-231246-1

Secunia picked it up at http://secunia.com/advisories/28746/

Web services are obviously a key concern here. I haven't checked to see how the common web service frameworks do XXE protection. It's possible to ban DTDs outright, but I'd suspect more common would be to use the broken parser property http://xml.org/sax/features/external-general-entities.

I'd love feedback on specific affected technologies.