Bugzilla Bug 260269

** Please note that this issue is confidential and no information should be
disclosed until it is made public, see "Whiteboard" for a date **

LittleCMS, an open source color management engine, suffers from several
integer overflows resulting in stack based buffer overflows, various heap
errors and memory leaks. Decoding a specially crafted image file will
result in unexpected process termination, Denial Of Service conditions or
arbitrary code execution due to stack overflow.

Created an attachment (id=183152) [details]
lcms-1.18beta1.tar.gz

Created an attachment (id=183153) [details]
lcms-1.17-bug260269.patch

I'm attaching you guys as you eiter touched the package in the past or are part
of printing -- if anyone cares about this, please prepare an ebuild for the
latest beta (distfile attached) or applying the patch, and attach it to this
bug. We will do prestable testing here, do not commit anything to CVS!
For testing purposes, I can request PoCs with the researcher and forward them
to you.

CVE-2009-0581 - memory leak
CVE-2009-0723 - buffer overflows
CVE-2009-0733 - lack of upper-gounds check on sizes

I'm removing myself from CC since I only made some minimal changes to the
ebuild in the past.

Just to not make this comment useless, I'll point out that I could find no
duplication of lcms functions in other software as passed by the tinderbox, the
chances of it going under my radar are slim.

HTH!

Created an attachment (id=183389) [details]
ebuild with above patch

Here's an ebuild for lcms-1.17-r1 using the above patch.

Arch Security Liaisons, please test the attached ebuild and report it stable on
this bug.
Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86"

CC'ing current Liaisons:
   alpha : yoswink, armin76
   amd64 : keytoaster, tester
    hppa : jer
     ppc : dertobi123
   ppc64 : corsair
   sparc : fmccor
     x86 : maekke, armin76

1)  It would be better if the ebuild used the name of the patch on the bug
(lcms-1.17-CVE-2009-0581.patch) instead of lcms-1.17-bug260269.patch (assuming
those are the same).

2) On sparc, I see a strange test failure:
=====================================
Testing devicelink generation.........
dE: mean=0.00689702, SD=0.00518751, max=0.0350195 [460000 tics, 0.46 sec.]
lcms: Error #12288; Noncompliant device-link profile
Testing saved linearization devicelinkmake[1]: *** [check] Error 1
make[1]: Leaving directory
`/var/tmp/portage/media-libs/lcms-1.17-r1/work/lcms-1.17/testbed'
make: *** [check-recursive] Error 1
======================================
Is this a problem?  If not, this seems good on sparc.

Sorry, I apparently use the description rather than the name...

That test failure worries me.  It passes on 1.17, so the patch is causing it to
fail (it fails on my box, as well).

Unfortunately, I don't know anything about lcms, so I cannot comment on how to
fix the bug.  rbu:  Would it be better to go to upstream with this issue, or
try the beta?  I'm leary of unleashing a beta directly to stable.

Unfortunately, printing is a bit defunct at the moment.

Yes, all tests pass on sparc, too, with lcms-1.17

Same test failure for HPPA and 1.17 unpatched is OK.

(In reply to comment #9)
> Sorry, I apparently use the description rather than the name...

My fault, I changed name and description after opening the bug. I guess
Bugzilla behaves weirdly once you do that.

> Unfortunately, I don't know anything about lcms, so I cannot comment on how to
> fix the bug.  rbu:  Would it be better to go to upstream with this issue, or
> try the beta?  I'm leary of unleashing a beta directly to stable.

Mailed ocert who are coordinating the issue with upstream.

Created an attachment (id=184243) [details]
lcms-1.18-beta1-additions.patch 

The patch included in 1.18beta1 and linked above is incomplete. Chris Evans
sent in an update (on top of beta1) to the maintainer who will incorporate the
patch, plus it is linked above. Considering the severity of the issue and
complexity of creating a final patch, the embargo date has been pushed to March
19.

As far as we are concerned, can we get prestable testing for the "beta1"
release with the additional patch? The backported patch seems a lot less clean
than the snapshot we have have available.

This is now public. However, we have not been able to prepare an ebuild in time
and upstream's latest release is beta2.

CVE-2009-0581 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-0581):
  Memory leak in LittleCMS (aka lcms or liblcms) before 1.18beta2, as
  used in Firefox 3.1beta, OpenJDK, and GIMP, allows context-dependent
  attackers to cause a denial of service (memory consumption and
  application crash) via a crafted image file.

CVE-2009-0723 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-0723):
  Multiple integer overflows in LittleCMS (aka lcms or liblcms) before
  1.18beta2, as used in Firefox 3.1beta, OpenJDK, and GIMP, allow
  context-dependent attackers to execute arbitrary code via a crafted
  image file that triggers a heap-based buffer overflow.  NOTE: some of
  these details are obtained from third party information.

CVE-2009-0733 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-0733):
  Multiple stack-based buffer overflows in the ReadSetOfCurves function
  in LittleCMS (aka lcms or liblcms) before 1.18beta2, as used in
  Firefox 3.1beta, OpenJDK, and GIMP, allow context-dependent attackers
  to execute arbitrary code via a crafted image file associated with a
  large integer value for the (1) input or (2) output channel, related
  to the ReadLUT_A2B and ReadLUT_B2A functions.

1.18 is out incorporating all patches linked here.

Hi,
kde team needed lcms-1.18 so i bumped it.
I suggest you to faststable 1.18 and remove all other versions.

Howgh ;]

Arches, please test and mark stable:
=media-libs/lcms-1.18
Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86"

ppc64 done

amd64 done

x86 stable

ppc done

Stable on alpha.

sparc stable

arm/ia64/s390/sh stable

I seem to be a bit late this time. Would it be alright to stabilise 1.18-r1
instead?

yes please, i was about to add arches to bug 264604 anyway.

Stable for HPPA.

Okay, does that mean we need 1.18-r1 stable on *all* arches? If yes, why didn't
you (rbu) add all arches again?

(In reply to comment #30)
> Okay, does that mean we need 1.18-r1 stable on *all* arches? If yes, why didn't
> you (rbu) add all arches again?

Let's discuss this on bug 264604.

GLSA 200904-19