An array index error leading to heap-based buffer out-of-buffer bounds write flaw was found in the way International Color Consortium (ICC) Format library (aka icclib) as used in Ghostscript and Argyll Color Management System computed dimensional increment through the clut based on the count of input channels. Using specially-crafted ICC profiles, an attacker could create a malicious PostScript or PDF file with embedded images which would cause Ghostscript to crash or, potentially, execute arbitrary code when opened by the victim. Similarly when such specially-crafted ICC profile was inspected by some of the Argyll Color Management System tools it could lead to particular executable crash or, arbitrary code execution with the privileges of the user running the binary.
Acknowledgements:
Red Hat would like to thank Marc Schönefeld for reporting this issue.

This issue affects the versions of the ghostscript package, as shipped with Red Hat Enterprise Linux 5 and 6.
--
This issue affects the version of the ghostscript package, as shipped with Fedora release of 16 and 17.
--
This issue affects the versions of the argyllcms package, as shipped with Fedora release of 16 and 17.

Analysis:
This really is an integer overflow, causing heap-buffer overflow.
In icc.c:icmLut_allocate()
icmbase *pp is taken as an arguement to this function, from which icmLut *p is extracted.
Various checks are done on the members of the struct pointed by *pp. Later the following happens:
6471 i = p->inputChan-1;
6472 p->dinc[i--] = p->outputChan;
Though p->inputChan is checked for upper bounds, its not really checked for lower bounds. In case of our malicious input file, p->inputChan = 0. Since i is unsigned, this causes an integer overflow for i, resulting in a very large value for it.
Later p->dinc[i--] = p->outputChan; causes an out of bounds write in the buffer
p->dinc, which is controlled i.
The size of the p->dinc buffer is 15. The chances of exploitation seem a little higher to me, specially because the _icmLut structure contains pointers to functions.

Probably a good idea to notify upstream in the case of discovering bugs
in external software, so that your fixes don't get undone at the next update.
[i.e. you seem to be expecting me to randomly stumble over this bug report.
There is no guarantee that this will be the case. ]

(In reply to comment #12)
Hello Graeme,
> Probably a good idea to notify upstream in the case of discovering bugs
> in external software, so that your fixes don't get undone at the next update.
Sure. This has been the practice for previous cases like this one. I am not sure why / how in this specific case it did not happen.
Anyway, we will make a note about this and ensure this will not occur again.
Apologize for the inconvenience.
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Response Team
>
> [i.e. you seem to be expecting me to randomly stumble over this bug report.
> There is no guarantee that this will be the case. ]