CESA-2009-003 - rev 2


[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/]


      LCMS (Little CMS / LittleCMS) memory corruptions

------------------------------------------------------------------------

Programs affected: lcms, Firefox, OpenJDK, lcms consumers (GIMP, etc).
Fixed: lcms-1.18beta2
Severity: Arbitrarty code execution from remote.
CVE-2009-0723: integer overflows leading to buffer overflows.
CVE-2009-0581: large memory leak.
CVE-2009-0733: stack-based buffer overflow due to missing bounds check.

LittleCMS is used for colour correction and management in several
critical pieces of software. It is typical for this software to look
inside JPEG files for ICC profiles, and feed them through LittleCMS if
found. Therefore, opening or viewing a malicious JPEG can compromise
your machine via affected software.

The OpenJDK case is arguably the most critical because it can be abused
directly on the server side to take over servers. All it needs is an
application that parses untrusted JPEG files (e.g. to thumbnail them).

It is against this same threat that the memory leak is significant:
taking down server JVMs.

In addition, OpenJDK of course backs the Java appletviewer on modern
Linux desktops, so this could be abused to take over web client machines.

Furthermore, it's interesting to note that the OpenJDK package is often
built without many of the system defenses that would mitigate this bug -
e.g. the stack is often forced executable, and stack canaries /
protection are disabled for whatever reason.

The Firefox case is fortunately not as severe as it could be. Firefox
3.0 does not parse embedded ICC profiles in the default configuration.
Firefox 3.1 has changed to parse them by default, so it's nice to get
these bugs fixed before 3.1 goes production and gets widely deployed.

The code responsible for the most severe bug, CVE-2009-0733, looks like
this:

static
LCMSBOOL ReadSetOfCurves(LPLCMSICCPROFILE Icc, size_t Offset, LPLUT NewLUT, int nLocation)
{
    LPGAMMATABLE Curves[MAXCHANNELS];
    unsigned int i, nCurves;

    if (Icc -> Seek(Icc, Offset)) return FALSE;
   
    if (nLocation == 1 ||  nLocation == 3)

        nCurves = NewLUT ->InputChan;
    else
        nCurves = NewLUT ->OutputChan;

    for (i=0; i < nCurves; i++) {

        Curves[i] = ReadCurve(Icc);
...

Where |MAXCHANNELS| is |16|. However, the overflow is not as obvious /
clear cut as the above code might suggest. Some common code paths place
an upper bound on |InputChan| and |OutputChan|. However, |ReadLUT_A2B|
and |ReadLUT_B2A| do not, e.g.:

static
LCMSBOOL ReadLUT_A2B(LPLCMSICCPROFILE Icc, LPLUT NewLUT, size_t BaseOffset, icTagSignature sig)
{
    icLutAtoB LUT16;

       if (Icc ->Read(&LUT16, sizeof(icLutAtoB), 1, Icc) != 1) return FALSE;

       NewLUT -> InputChan     = LUT16.inputChan;
       NewLUT -> OutputChan    = LUT16.outputChan;
...
       if (LUT16.offsetB != 0)
                ReadSetOfCurves(Icc, BaseOffset + LUT16.offsetB, NewLUT, 2);
...


      Exploitation

I don't usually exploit bugs, but there are nice subtleties here to
exploit this, so I'll post a demo exploit to my blog, with explanation,
over the next few days.


      Credits

    * Google - found on Google's paid time.
    * oCERT (and particularly Andrea Barisani) for co-ordinating a
      tricky issue.
    * Tomas Hoger (RedHat) for fixing up serious issues with the integer
      overflow detection.
    * Josh Bressers (RedHat) for preventing div-by-zero errors making it
      into the final patch.
    * Marti Maria (lcms maintainer) for being patient with multiple
      incremental patches.
    * Jan Lieskovsky (RedHat) for help co-ordinating and expanding
      investigation to other open-source packages.
    * Julien Tinnes for interesting discussions regarding executability
      of heaps.


CESA-2009-003 - rev 2
Chris Evans
scarybeasts@gmail.com <mailto:scarybeasts@gmail.com>