Bug 458056 - (CVE-2008-3282) CVE-2008-3282 openoffice.org: numeric truncation error in memory allocator (64bit)
CVE-2008-3282 openoffice.org: numeric truncation error in memory allocator (6...
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
high Severity high
: ---
: ---
Assigned To: Red Hat Product Security
source=redhat,reported=20080721,publi...
: Security
: 455867 (view as bug list)
Depends On: 458064 458065
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-06 08:46 EDT by Tomas Hoger
Modified: 2008-11-06 06:00 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-11-06 06:00:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
OpenOffice.org 92217 None None None Never

  None (edit)
Description Tomas Hoger 2008-08-06 08:46:36 EDT
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:

  if (index < RTL_MEMORY_CACHED_LIMIT >> RTL_MEMALIGN_SHIFT)

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
    http://scary.beasts.org/security/CESA-2008-006.html
Comment 1 Tomas Hoger 2008-08-06 09:08:36 EDT
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:

  http://www.openoffice.org/issues/show_bug.cgi?id=92217

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 08:53:49 EDT
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 12:46:01 EDT
Lifting embargo.
Comment 8 Tomas Hoger 2008-08-27 14:01:24 EDT
*** Bug 455867 has been marked as a duplicate of this bug. ***
Comment 9 Fedora Update System 2008-09-10 02:39:18 EDT
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 03:23:59 EDT
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.