[Openicc] Introduction / Gutenprint]

[Michael Sweet]

Robert L Krawitz wrote:
>    Date: Tue, 12 Apr 2005 15:49:19 -0400
>    From: Michael Sweet <mike at easysw.com>
> 
>    Craig Bradney wrote:
>    > ...
>    > And the case where theres only one user on a computer using ICC and
>    > the others not, and that person doesnt have rights to put files in a
>    > system dir? Surely a profile can be loaded from anywhere. Are there
>    > passwords in profiles in any case?
> 
>    No, but it is far easier to force files to be relative to a
>    controlled directory than to filter out the paths and permissions
>    allowed for a specific, possibly non-local user.  Both the System V
>    lp and Berkeley lpr print spoolers have a long history of security
>    problems caused by direct access/references to files.
> 
> This is why I think profiles should be bundled up with the file being
> printed and sent to the spooler, rather than having the spooler know
> about a restricted set of profiles and only allowing the user to pick
> from that list.  Then the user (via the non-privileged lpr command)
> would send the spooler both the file to be printed and the profile via
> IPP.  Passing the ICC profile by reference is what causes a problem;
> if it's passed by value, none of this would occur.

Problem is, I haven't yet heard of a compelling use case which
requires a per-job, user-specified destination profile.  Source
profiles, sure, but then you might use a dozen source profiles
depending on the document you are printing.

My experience has been that professional printers that care about
color management create new destination profiles on a regular basis
(e.g. each day, week, or set of ink/media) and reuse those profiles
for every job in the run.  In this case, embedding/attaching the
destination profile with the document file is unnecessary and
wasteful of disk/bandwidth.  Similarly, professionals regularly
create source profiles for their incoming imagery, but in that
case the source data will not change over time.  Ink, media, and
environment do change over time, though... :)

>    The issue isn't "are there passwords in profiles", it is "can I
>    provide a filename to CUPS which will cause it to emit an error
>    message that discloses some information that is in the file", or
>    "can I provide a filename that will cause a buffer overflow in the
>    ICC parser and execute arbitrary code"....
> 
> This is no different from "can I provide a Postscript file that will
> trigger a buffer overflow in Ghostscript and execute arbitrary code".

It is different in that PostScript exploits typically are "out in the
open", and Ghostscript has a lot more mileage than the various ICC
parsers...

> The ICC parser needs to be audited, just like Ghostscript does, since
> it runs in a system context.

Well, not really a system context, but there are definitely issues
to address and auditing to do...

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Publishing Software        http://www.easysw.com