Bug 995090 (CVE-2013-6500)

Summary:	CVE-2013-6500 foomatic (foomatic-extract-text): Arbitrary code execution due to insecure Perl module loading from CWD
Product:	[Other] Security Response	Reporter:	Jan Lieskovsky <jlieskov>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	carnil, jkurik, jrusnack, security-response-team, twaugh, vkaigoro
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-02-18 21:48:32 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	995093

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.