A security flaw was found in the way foomatic-extract-text tool of foomatic, a comprehensive, spooler-independent database of printers, printer drivers, and driver descriptions, previously used to extract text from database and/or PPD files. A local attacker, with write privilege into the directory, the foomatic-extract-text tool was run by the victim from, could use this flaw to execute arbitrary code with the privileges of the user running the foomatic-extract-text tool.
This issue was found by Murray McAllister of Red Hat Security Response Team.
This has been filed upstream: https://bugs.linuxfoundation.org/show_bug.cgi?id=1261
(In reply to Tomas Hoger from comment #6)
> (In reply to Vasyl Kaigorodov from comment #5)
> > With the above said, this bug should probably be CLOSED/NOTABUG.
> This may be perl-Encode flaw rather than foomatic. It may not be unexpected
> given that perl @INC contains . by default (which is likely to never change
> to anything safer). However, I'm not convinced notabug is correct
> resolution. Wontfix may be more correct.
> If modules user require inside eval to load non-mandatory modules, we can
> still address that when doing RPM packaging by having the other module RPM
> required. In this case, it seems Encode::ConfigLocal is not expected to be
> provided by any package. Looks like an insecure-by-default design.
Upstream can't find the vuln code, neither can I, I have CVE reject'ed this, we may want to do a flaw for perl encode however it seems like a non issue. If no-one objects I'm closing this WONTIX, whether or not someone wants to chase this down in Perl Encode is up to them, I don't think it's a terribly efficient use of time.