LittleCMS vulnerabilities

Today, vendor updates should be flowing for vulnerabilities in LittleCMS, sometimes known just as "lcms" or "liblcms". LittleCMS is a very useful open-source colour profile parsing and conversion tool. Some technical details of the various vulnerabilities (stack-based buffer overflows, integer overflows, etc). are given here:

http://scary.beasts.org/security/CESA-2009-003.html

The most interesting thing about LittleCMS is how quickly it has become a very critical building block for UNIX desktops. Let's enumerate some of the pieces of software impacted by any lcms vulnerabilities:

• OpenJDK. OpenJDK uses lcms to parse colour profiles embedded in JPEG or BMP files. OpenJDK is on the default browser attack surface of a lot of Linux installations, e.g. Fedora 10.


• Firefox. Firefox 3.1beta uses lcms to parse colour profiles embedded in JPEG files -- by default. (Firefox 3.0 has this ability but not by default, so thankfully this can be addressed before 3.1 goes production).


• GIMP. GIMP uses the system liblcms library to parse colour profiles embedded in at least JPEG files.

I don't usually do this, but I took the trouble to write an exploit for one of the bugs, because it was fun and had some quirks. It's probably not a great idea to release it just yet -- look for a separate blog post soon.

Finally, some notes on the various Linux system protections that do or don't help defend against the exploit for this stack-based buffer overflow:

• My exploit targets, but is not limited to, systems with executable heaps. Interestingly 32-bit Ubuntu 8.10 on my laptop shows the heap as non-executable in /proc/<pid>/maps, but it lies because the installed kernel is non-PAE.


• For systems with non-executable heaps, such as 64-bit Ubuntu 8.10 on my desktop, an exploit is still possible because you can point registers other than rip into the heap (e.g. rbp). I've not written this exploit.


• Systems with stack smashing detection, such as Fedora 10, do make the exploit hard or impossible. However, the somewhat risky OpenJDK package on such a system is not compiled with stack smashing detection, leaving the default browsing experience vulnerable.


• I noticed that the Fedora 10 stack smashing detection does not exit cleanly, but gives a SIGSEGV. On 32-bit, the faulting instruction is cmpw $0xb858,(%eax) where %eax == 0x1. Stack frames is __stack_chk_fail __fortify_fail __libc_message backtrace _Unwind_Backtrace ??. Leave a comment if you know what's going on. Sounds dangerous to me.