Bug 1218297 (CVE-2010-5325)

Summary: CVE-2010-5325 foomatic: potential remote arbitrary code execution
Product: [Other] Security Response Reporter: Fabio Olive Leite <fleite>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: carnil, jpopelka, security-response-team, slong, twaugh
Target Milestone: ---Keywords: Reopened, Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
It was discovered that the unhtmlify() function of foomatic-rip did not correctly calculate buffer sizes, possibly leading to a heap-based memory corruption. A malicious attacker could exploit this flaw to cause foomatic-rip to crash or, possibly, execute arbitrary code.
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-03-22 21:29:17 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: 1214534, 1296499, 1296500    
Bug Blocks: 1218306    

Description Fabio Olive Leite 2015-05-04 14:13:08 UTC
This flaw was fixed upstream back in 2010, without much attention being
given to the possible security implications of it. It is a remote buffer
overflow with possibility of executing arbitrary code, with only a few
restrictions, such as having the cups service open to the network and a
particular kind of filter in use.

Analysis by Engineering shows that only RHEL-6 contains the affected code,
so RHEL-5, RHEL-7 and Fedora are not affected. Giving this flaw a Moderate
rating, despite the 7.7 CVSSv2 score, as cups is not usually configured
widely open to the network or internet at large, and because it depends on
a particular kind of filter being used.

References:
https://bugs.linuxfoundation.org/show_bug.cgi?id=515

Comment 2 Stefan Cornelius 2015-05-05 18:25:43 UTC
The simplified code looks a bit like:
>static void unhtmlify(char *dest, size_t size, const char *src)
>{
>   char *pdest = dest;
>   const char *psrc = src;
>   const char *repl;
>
>   while (*psrc && pdest - dest < size) {
>     if (repl) {
>           strncpy(pdest, repl, size - (pdest - dest));
>           pdest += strlen(repl);
>           psrc = strchr(psrc, ';') +1;
>           }
>   }
>*pdest = '\0';
>}

The size calculation and the loop condition seem to have an off-by-one-ish problem, but I didn't investigate that; the patch would fix it and there's a bigger problem than a potential off-by-one:
>           strncpy(pdest, repl, size - (pdest - dest));
>           pdest += strlen(repl);

We increase pdest by the length of the source string, not taking the remaining space of pdest/dest into account. This could catapult pdest beyond the "dest" boundaries, leading to an out of bounds write when reaching the *pdest = '\0'; part.

So, the mechanic at hand is essentially "write a 0 byte at a semi-controlled OOB location on the heap". That's fairly limited but might just be crazy enough to gain code execution.

Comment 5 Stefan Cornelius 2016-02-15 09:45:50 UTC
CVE request:
http://www.openwall.com/lists/oss-security/2016/02/15/1

Comment 6 Stefan Cornelius 2016-02-15 21:41:05 UTC
This was assigned CVE-2010-5325 via http://www.openwall.com/lists/oss-security/2016/02/15/7

Comment 7 errata-xmlrpc 2016-03-22 21:03:55 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 6

Via RHSA-2016:0491 https://rhn.redhat.com/errata/RHSA-2016-0491.html