A security flaw was found in the way ordered_malloc() routine implementation in Boost, the free peer-reviewed portable C++ source libraries, performed 'next-size' and 'max_size' parameters sanitization, when allocating memory. If an application, using the Boost C++ source libraries for memory allocation, was missing application-level checks for safety of 'next_size' and 'max_size' values, a remote attacker could provide a specially-crafted application-specific file (requiring runtime memory allocation it to be processed correctly) that, when opened would lead to that application crash, or, potentially arbitrary code execution with the privileges of the user running the application. CVE request: [1] http://www.openwall.com/lists/oss-security/2012/06/05/1 Relevant upstream patch (including reproducer): [2] https://svn.boost.org/trac/boost/changeset/78326 References: [3] https://svn.boost.org/trac/boost/ticket/6701 [4] https://bugzilla.novell.com/show_bug.cgi?id=765443 [5] http://kqueue.org/blog/2012/03/05/memory-allocator-security-revisited/
This issue affects the versions of the boost package, as shipped with Red Hat Enterprise Linux 5 and 6. -- This issue affects the versions of the boost package, as shipped with Fedora release of 15, 16, and 17. Please schedule an update. This issue affects the version of the boost141 package, as shipped with Fedora release of 17. Please schedule an update. -- This issue affects the version of the boost141 package, as shipped with Fedora EPEL 5. Please schedule an update.
Created boost tracking bugs for this issue Affects: fedora-all [bug 828857]
Created boost141 tracking bugs for this issue Affects: fedora-17 [bug 828858] Affects: epel-5 [bug 828860]
I do not see an updated boost package in RHEL 6 yet, where boost141 is based on. Can you please provide me the updated boost source RPM of RHEL 6, as I could imagine, that the RHEL package update is likely a combined bugfix and security update (and thus also covers other known bugs). Thank you :)
That test case triggers on Fedora 15 and Fedora 16. After adjusting to accommodate for interface changes, it triggers on RHEL 6 and RHEL 5 as well. Interestingly it doesn't appear to trigger Fedora 17. That's strange, as Fedora 17 certainly doesn't ship the fix.
... but that's just a happy coincidence. When we increase next_size in the test program (dividing by e.g. 100 instead of 768), it fails anyway. It just shifts the value at one place, avoiding this, but not solving the general problem. The provided patch fixes the issue. I'll proceed with spinning builds etc.
The CVE identifier of CVE-2012-2677 has been assigned to this issue: http://www.openwall.com/lists/oss-security/2012/06/07/13
Looks like there hasn't been any need for Red Hat to patch this issue within the last 6 month for RHEL 6...
This issue has been addressed in following products: Red Hat Enterprise Linux 5 Red Hat Enterprise Linux 6 Via RHSA-2013:0668 https://rhn.redhat.com/errata/RHSA-2013-0668.html
boost141-1.41.0-4.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.
N.B. the upstream ticket is https://svn.boost.org/trac/boost/ticket/6701