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: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
Status: | CLOSED ERRATA | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | unspecified | CC: | 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
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. This was assigned CVE-2010-5325 via http://www.openwall.com/lists/oss-security/2016/02/15/7 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 |