argyllcms: code execution [LWN.net]

Package(s):

argyllcms

CVE #(s):

CVE-2012-1616

Created:

May 7, 2012

Updated:

June 19, 2012

Description:

From the Red Hat bugzilla:

A Use-after-free vulnerability was found in the way icclib, a library used for reading and writing of color profile files that conform to the International Color Consortium (ICC) Profile Format Specification, processed certain crafted ICC profile files. The ICC Profile Format is a cross-platform device profile format that can be used to translate color data created on one device into another device's native color space.

A remote attacker could provide a specially crafted file and trick a local user into opening it, which could lead to arbitrary code execution with the privileges of the user running an application linked against icclib.

Alerts:

Fedora	FEDORA-2012-6529	2012-05-04
Gentoo	201206-04	2012-06-18

(Log in to post comments)

argyllcms: code execution

Posted May 17, 2012 1:43 UTC (Thu) by gwg (guest, #20811) [Link]

This report is inaccurate, and rather late.

Firstly, the bug was in fact a double free, so there is
no chance of arbitrary code execution unless your
systems malloc library is very buggy.

Secondly, the bug was present in a single utility,
iccdump, and is not a bug in icclib, and therefore
does not affect general ICC profile access
(ie. it affected no other programs other than iccdump in ArgyllCMS).

Thirdly, this was fixed in ArgllCMS Release 1.4.0 released
on 20th April, nearly a month ago.

argyllcms: code execution

Posted May 17, 2012 20:04 UTC (Thu) by jimparis (subscriber, #38647) [Link]

This report is about a security update in FC16, not the original upstream release.

Why do you claim a double-free is not exploitable? They most certainly are, in general; is there something about iccdump's particular bug that makes it not?

Anyway, if it is misinformation, it's not LWN's fault, see e.g. http://www.securityfocus.com/bid/53240/discuss

argyllcms: code execution

Posted May 17, 2012 20:16 UTC (Thu) by jimparis (subscriber, #38647) [Link]

(replying to myself)
It also seems overly defensive to say that this is only a bug in iccdump and not a bug in icclib. As far as I can tell iccdump.c did not change at all between 1.3.7 and 1.4.0, but rather the fix was located in icc/icc.c, which means the bug *was* compiled into icclib. Maybe what you meant is that iccdump is the only program you're *aware* of that used the vulnerable function, but that doesn't mean someone else wasn't also calling it.