Red Hat Bugzilla – Bug 995090
CVE-2013-6500 foomatic (foomatic-extract-text): Arbitrary code execution due to insecure Perl module loading from CWD
Last modified: 2015-08-19 05:21:42 EDT
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.