Bug 458056 (CVE-2008-3282) - CVE-2008-3282 openoffice.org: numeric truncation error in memory allocator (64bit)
Summary: CVE-2008-3282 openoffice.org: numeric truncation error in memory allocator (6...
Alias: CVE-2008-3282
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
: 455867 (view as bug list)
Depends On: 458064 458065
TreeView+ depends on / blocked
Reported: 2008-08-06 12:46 UTC by Tomas Hoger
Modified: 2019-09-29 12:26 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-11-06 11:00:29 UTC

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
OpenOffice.org 92217 0 None None None Never
Red Hat Product Errata RHSA-2008:0835 0 normal SHIPPED_LIVE Important: openoffice.org security update 2008-08-27 17:04:03 UTC

Description Tomas Hoger 2008-08-06 12:46:36 UTC
It was discovered, that OpenOffice.org memory allocator is not 64bit clean.
rtl_allocateMemory() function in sal/rtl/source/alloc_global.c accepts one
argument - sal_Size n.  On 64bit platforms such as x86_64, sal_Size is defined
as unsigned long int.  This requested memory chunk size is later memory aligned
as size (type sal_Size).  size is later used to calculate int index to
g_alloc_table[] array:

  int index = (size - 1) >> RTL_MEMALIGN_SHIFT;

However, as sizeof(int) == 4 and sizeof(sal_Size) == 8 on 64bit platforms, the
calculated value may not fit into index (this can happen when
rtl_allocateMemory() is called with large argument, e.g. when some other flaw
causes OpenOffice to attempt to allocate chunk of memory with negative size,
which wraps to large positive value during signed -> unsigned type conversion,
such as [1]).  Value stored in the index is wrapped / truncated, possibly
resulting in the index being negative.

Before index is used, it is checked not to exceed fixed upper limit, but it's
not checked whether its value is >= 0:


Negative index used in g_alloc_table[index] will cause OpenOffice to access
memory outside of the g_alloc_table[] array.  This may result it crash, or if
that points to an attacker controlled memory, attacker may possibly be able to
use this flaw to run arbitrary code.

[1] http://www.openoffice.org/issues/show_bug.cgi?id=91818

Comment 1 Tomas Hoger 2008-08-06 13:08:36 UTC
OpenOffice.org upstream is aware of this issue, but they do not plan to release any security advisory for it, as they do not ship any 64bit pre-built packages. Issue was fixed upstream shortly after we reported it.  Upstream bug report:


This issue does not affect openoffice.org and openoffice.org2 packages as shipped in Red Hat Enterprise Linux 3 and 4, as only 32bit builds are shipped in those versions.

Comment 5 Tomas Hoger 2008-08-07 12:53:49 UTC
Rene Engelhard of Debian pointed out that 64bit builds that use system memory allocator instead of the OpenOffice.org custom one (i.e. compiled with --with-alloc=system) are also unaffected by this problem.

Comment 7 Tomas Hoger 2008-08-27 16:46:01 UTC
Lifting embargo.

Comment 8 Tomas Hoger 2008-08-27 18:01:24 UTC
*** Bug 455867 has been marked as a duplicate of this bug. ***

Comment 9 Fedora Update System 2008-09-10 06:39:18 UTC
openoffice.org-2.4.1-17.6.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 10 Fedora Update System 2008-09-10 07:23:59 UTC
openoffice.org-2.3.0-6.16.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

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