what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

Chris Evans Security Advisory 2009.3

Chris Evans Security Advisory 2009.3
Posted Mar 20, 2009
Authored by Chris Evans

LittleCMS versions prior to 1.18beta2 suffers from various integer and buffer overflows as well as memory leak errors.

tags | advisory, overflow, memory leak
SHA-256 | e08b60bf2eb57ab4cae3a2831d2547cb74b70029d9d52d83b1c5a3cd3d0f3ac8

Chris Evans Security Advisory 2009.3

Change Mirror Download

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>

Login or Register to add favorites

File Archive:

May 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    May 1st
    44 Files
  • 2
    May 2nd
    5 Files
  • 3
    May 3rd
    11 Files
  • 4
    May 4th
    0 Files
  • 5
    May 5th
    0 Files
  • 6
    May 6th
    28 Files
  • 7
    May 7th
    3 Files
  • 8
    May 8th
    4 Files
  • 9
    May 9th
    54 Files
  • 10
    May 10th
    12 Files
  • 11
    May 11th
    0 Files
  • 12
    May 12th
    0 Files
  • 13
    May 13th
    17 Files
  • 14
    May 14th
    11 Files
  • 15
    May 15th
    17 Files
  • 16
    May 16th
    13 Files
  • 17
    May 17th
    22 Files
  • 18
    May 18th
    0 Files
  • 19
    May 19th
    0 Files
  • 20
    May 20th
    0 Files
  • 21
    May 21st
    0 Files
  • 22
    May 22nd
    0 Files
  • 23
    May 23rd
    0 Files
  • 24
    May 24th
    0 Files
  • 25
    May 25th
    0 Files
  • 26
    May 26th
    0 Files
  • 27
    May 27th
    0 Files
  • 28
    May 28th
    0 Files
  • 29
    May 29th
    0 Files
  • 30
    May 30th
    0 Files
  • 31
    May 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close