Bug 995090 (CVE-2013-6500) - CVE-2013-6500 foomatic (foomatic-extract-text): Arbitrary code execution due to insecure Perl module loading from CWD
Summary: CVE-2013-6500 foomatic (foomatic-extract-text): Arbitrary code execution due ...
Alias: CVE-2013-6500
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On:
Blocks: 995093
TreeView+ depends on / blocked
Reported: 2013-08-08 14:10 UTC by Jan Lieskovsky
Modified: 2019-09-29 13:07 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-02-18 21:48:32 UTC

Attachments (Terms of Use)

Description Jan Lieskovsky 2013-08-08 14:10:49 UTC
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.

Comment 1 Jan Lieskovsky 2013-08-08 14:16:08 UTC
This issue was found by Murray McAllister of Red Hat Security Response Team.

Comment 7 Kurt Seifried 2015-02-18 17:05:44 UTC
This has been filed upstream: https://bugs.linuxfoundation.org/show_bug.cgi?id=1261

Comment 8 Kurt Seifried 2015-02-18 21:48:32 UTC
(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.

Note You need to log in before you can comment on or make changes to this bug.