** Please note that this issue is SEMI-PUBLIC and no additional information should be disclosed until it is made public, see "Whiteboard" for a date ** Tomas Hoger of the Red Hat Security Response Team reported: 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
As mentioned, this issue only affects 64bit builds, and therefore only openoffice (not -bin), and only amd64. Andreas, since the patch is public, please commit a revbump including the it in our patchset with an innocent ChangeLog (like your last one).
As far as I understand this is only a problem in Suns own memory allocator. Fortunately we are NOT using this anymore in our own OOo builds since March of this year (pre 2.4.1), but rely on the system memory allocator instead. So actually there shouldn't be any action required on our side, as this bug doesn't affect us. Citing a mail from the Debian maintainer on the OOo security list in response to Red Hats planned security advisory: "Please mention that many distros are also not affected because they don't use the custom allocatiors implemented by Sun but malloc() as they should (--with-alloc=system to configure)" Which actually is exactly what we do.
Great, thank you for the analysis. I'll close this INVALID and leave it closed until the due date.
*** Bug 236083 has been marked as a duplicate of this bug. ***
