To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=61537
Issue #:|61537
Summary:|Openoffice uses malloc'ed (C++ "new") heap data for
|executable code without getting executable
|permissions
Component:|udk
Version:|OOo 2.0.1
Platform:|All
URL:|http://bugs.gentoo.org/show_bug.cgi?id=120811
OS/Version:|Linux
Status:|UNCONFIRMED
Status whiteboard:|
Keywords:|
Resolution:|
Issue type:|DEFECT
Priority:|P3
Subcomponent:|code
Assigned to:|kr
Reported by:|kevquinn
------- Additional comments from [EMAIL PROTECTED] Thu Feb 2 10:00:46 -0800
2006 -------
bridges/source/cpp_uno/gcc3_linux_intel/cpp2uno.cxx uses 'new' to allocate
memory into which it then writes code for execution. 'new' memory only has
executable permission due to the inadequacy of the pre-"NX bit" intel
architecture, so it works by accident more than by design. PaX kernels
highlight this as they implement NX behaviour, whereby the heap is by default
non-executable. Future kernels may make use of the NX bit in newer
architectures to set heap data non-executable by default, requiring either
mprotect() or mmap() to be used to obtain executable heap data. Either way,
making the assumption that heap is executable is an unnecessary assumption.
Execshield (RedHat) systems may also be affected, if openoffice is run with
theexecshield variant of NX protection.
The fix is to use either mprotect() or mmap() to get executable heap memory.
The rest of openoffice does this via the rtl_allocateMemory function provideding
rtl/alloc.{c,h}. Luckily there's an example already present in the x86_64 and
netbsd code which makes things simpler, so the fix is to obtain the memory in
the same way.
Other systems that are similarly affected are solaris_intel, solaris_sparc,
freebsd_intel, linux_powerpc, linux_sparc, macos_powerpc (basically everything
except netbsd_intel, linux_s390 and linux_x86-64). Obviously they all work now
because those systems
Also bridges/source/cpp_uno/gcc3_linux_intel/code.s has no .note.GNUstack
section, which leads libgcc3_uno.so to be marked as needing executable stack,
although I think code.s does not require executable stack.
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
