Bugzilla – Bug 826097
VUL-0: CVE-2013-4160: lcms2: multiple flaws
Last modified: 2016-04-27 19:28:16 UTC
From Fedora advisore [1]: temporarly swithced to intree lcms as it have security fixes (patch 500) The lcms related parts between icedtea-2.3.9 and icedtea-2.3.10 is [2] and it seems our lcms2 packages are vulnerable. Because we do use icedtea-2.4.0, where in-tree lcms does not contain such fixes, I recommend to port the fix to lcms2 instead. [1] http://lwn.net/Articles/555679/ [2] http://paste.suse.de/7168
bugbot adjusting priority
Porting to our lcms2 was straightforward. It seems that lcms (1) is not affected - vulnerable functions are either not present or use fixed length (32, MAX_PATH) allocation (and set last byte to NUL).
Private mail was sent to the upstream maintainer info@littlecms.com. Is there any CVE?
I tried to find any CVE related to lcms2. Nothing so far. So just wait for a comment from upstream. Do we have already an openSUSE 12.2/12.3 and SLE-11-SP3 lcms2 submission?
Fixes are ready in: https://build.opensuse.org/project/show?project=home%3Asbrabec%3Abranches%3AOBS_Maintained%3Alcms2 https://build.opensuse.org/package/show?package=lcms2&project=home%3Asbrabec%3Abranches%3Amultimedia%3Alibs https://build.suse.de/project/show?project=home%3Asbrabec%3Abranches%3AOBS_Maintained%3Alcms2 Should I submit it now or should I wait for lcms2 upstream maintainer?
I would like to know what the Little CMS guys have to say about the differences between the standalone version of lcms2 and the intree lcms of openjdk. There is no time pressure, as we have to wait until the next openjdk update based on the Oracle JDK 7u25 update from 12_jun_2013. See our Oracle Java tracking bug#825624 for more details.
From: info@littlecms.com To: Stanislav Brabec <sbrabec@suse.cz> Subject: Re: [PATCH] security issue in lcms2 Date: Tue, 25 Jun 2013 18:26:37 +0200 Hi Stanislav, Many thanks for let me know. I'm incorporating the fixes in the incoming lcms2.5 which will be released next week. Best regards Marti Maria
New version of lcms2 was released. I am comparing these versions to check, whether author did anything else. I see in the changelog: Added some checks for non-happy path, mostly failing mallocs It seems that just this bug is a security related.
I just went through all changes between lcms2 2.4->2.5 in the git repository. Fix in this bug was accepted (Tue Jun 25 16:09:16 2013 +0200, i. e. the lcms2 upstream was probably not informed in advance): https://github.com/mm2/Little-CMS/commit/91c2db7f2559be504211b283bc3a2c631d6f06d9 But there are many more changes that can have a potential security impact: https://github.com/mm2/Little-CMS/commit/b0d5ffd4ad91cf8683ee106f13742db3dc66599a https://github.com/mm2/Little-CMS/commit/06d4557477e7ab3330a24d69af4c67adcac9acdf https://github.com/mm2/Little-CMS/commit/41d222df1bc6188131a8f46c32eab0a4d4cdf1b6 https://github.com/mm2/Little-CMS/commit/b0d5ffd4ad91cf8683ee106f13742db3dc66599a https://github.com/mm2/Little-CMS/commit/9cf2d61867375f867e6e80906a571d222bc2cbf3 https://github.com/mm2/Little-CMS/commit/049d634ea6bf2a9bafbf9ddef18464be9caa567f https://github.com/mm2/Little-CMS/commit/03f784fe8d5eaf8353e8521799a301b8a188388c https://github.com/mm2/Little-CMS/commit/d2d902b9a03583ae482c782b2f243f7e5268a47d https://github.com/mm2/Little-CMS/commit/c606462eda773b1cdd51dcfebd81fc8862652c51 https://github.com/mm2/Little-CMS/commit/65e2f1df3495edc984f7e0d7b7b24e29d851e240 https://github.com/mm2/Little-CMS/commit/886e2f524268efe8a1c3aa838c28e446fda24486 https://github.com/mm2/Little-CMS/commit/5d98f40ed58f6e8eb9aee6dd2d9467bbc8551ee7 Maybe we should think about a version update. The first SLE version with lcms2 is SLE11 SP3 (maybe as a dependency). The new version brings not only security, but also apparent color management bug fixes. Also one of future updates of Java may force us to upgrade or use custom lcms2 in the Java code. lcms2 upstream does very detailed enterprise testing before each upgrade: In Fri, 06 Mar 2009 18:05:50 +0100 Marti Maria wrote: Actually, we in HP are using lcms as the embedded color engine for some of our large format Designjet, Indigo prepress and laser printers, so I have to be very careful about what goes in and what may represent a potential issue. Not only because security, but also for Intellectual property. So, I do only a couple of releases each year, and before each release, there is a code review session with several HP engineers, managers and lawyers. This is long and tedious, but with that we make sure legal team is happy. HP allows me to continue with lcms under those conditions.
(In reply to comment #9) > Maybe we should think about a version update. The first SLE version with lcms2 > is SLE11 SP3 (maybe as a dependency). The new version brings not only security, > but also apparent color management bug fixes. > > Also one of future updates of Java may force us to upgrade or use custom lcms2 > in the Java code. As the openjdk is only one consumer actually and it will be probable that more recent versions (jdk8, jdk9, ...) will require most recent lcms2, enabling lcms2 upgrades might be a reasonable choice. Anyway can you check API/ABI changes in newest release?
Note that recent icedtea 2.4.1 does recommends lcms2 2.5, or to use in-tree version. @Sebastian: do you agree with an upgrade? Unfortunately I have no other information than numbers of oracle bugs :(
I see several API additions, several changes in the internal API (not available in header files), and one API change in cmsPipelineInsertStage(). It returns: in 2.4: void in 2.5: int Does it affect ABI?
According my thought and stackowerflow [1] it does not. [1] http://stackoverflow.com/questions/15626579/c-abi-is-it-safe-to-change-void-function-to-return-int
I missed this NEEDINFO , sorry. do they have a different major version?
for opensuse we can just try it out, for SLE we probably need a ECO
(In reply to comment #15) > for opensuse we can just try it out, for SLE we probably need a ECO whom to contact for ECO? BTW: or seeing this as too much burden, what'd you say about use of in-tree copy in SLED?
ad comment 16: Using in-tree lcms would introduce extra work in backporting of security fixes to lcms2. lcms2 was introduces to SLE11 SP3 just as dependecy of JDK, and has no other use in SLE11: SLE11 does not contain any other color-management enabled application. So if we will use JDK in-tree lcms2, dropping of lcms2 as a separate package may make sense. If any of our customers will build any new color management solution based on SLE11 SP3, then lcms2 update to the latest fixed version would be welcome to them.
I would be the ECO driver, or respective the product manager. I diffed 2.4 - 2.5 now and upstream declared it a maintenance release and I agree. There are some new functions (allowed in our ABI policies), the one changed return type (ok in my eyes) and lots of bugfixes. So lets just do an update 2.4 -> 2.5 on both openSUSE and SLE.
The SWAMPID for this issue is 53641. This issue was rated as moderate. Please submit fixed packages until 2013-07-31. When done, please reassign the bug to security-team@suse.de. Patchinfo will be handled by security team.
Submitted: SUSE:SLE-11-SP3:Update:Test: IBS request id 27738 openSUSE: OBS maintenance request id 183551 (openSUSE:12.2:Update + openSUSE:12.3:Update) openSUSE:Factory: It was already updated.
CVE(s) requested.
CVE-2013-4160
openSUSE-SU-2013:1236-1: An update that contains security fixes can now be installed. Category: security (low) Bug References: 826097 CVE References: Sources used: openSUSE 12.3 (src): lcms2-2.5-2.4.1 openSUSE 12.2 (src): lcms2-2.5-2.4.1
reelased
Update released for: lcms2, lcms2-debuginfo, lcms2-debugsource, liblcms2-2, liblcms2-2-32bit, liblcms2-devel, liblcms2-devel-32bit, liblcms2-doc Products: SLE-DEBUGINFO 11-SP3 (i386, x86_64) SLE-DESKTOP 11-SP3 (i386, x86_64) SLE-SDK 11-SP3 (i386, x86_64)
openSUSE-RU-2013:1301-1: An update that has one recommended fix can now be installed. Category: recommended (low) Bug References: 826097 CVE References: Sources used: openSUSE 11.4 (src): lcms2-2.5-7.1