Bug 1218297 (CVE-2010-5325) - CVE-2010-5325 foomatic: potential remote arbitrary code execution
Summary: CVE-2010-5325 foomatic: potential remote arbitrary code execution
Alias: CVE-2010-5325
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: Red Hat1214534 Engineering1296499 Engineering1296500
Blocks: Embargoed1218306
TreeView+ depends on / blocked
Reported: 2015-05-04 14:13 UTC by Fabio Olive Leite
Modified: 2019-09-29 13:31 UTC (History)
5 users (show)

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.
Clone Of:
Last Closed: 2016-03-22 21:29:17 UTC

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2016:0491 0 normal SHIPPED_LIVE Moderate: foomatic security update 2016-03-23 01:02:15 UTC

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.


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:

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

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