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.