Bug 132149 - libbeecrypt.so.6: cannot enable executable stack
libbeecrypt.so.6: cannot enable executable stack
Product: Fedora
Classification: Fedora
Component: beecrypt (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
Depends On:
Blocks: FC4Blocker
  Show dependency treegraph
Reported: 2004-09-09 04:27 EDT by Sandino Araico Sánchez
Modified: 2007-11-30 17:10 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-02-07 14:08:39 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
strace rpm --help (4.50 KB, text/plain)
2004-09-09 16:04 EDT, Sandino Araico Sánchez
no flags Details

  None (edit)
Description Sandino Araico Sánchez 2004-09-09 04:27:36 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7)
Gecko/20040818 Firefox/0.9.3

Description of problem:
When using a kernel patched with GR Security http://grsecurity.net I
get an error each time I try to run rpm version 4.3.1 on Fedora Core 2:

rpm: error while loading shared libraries: libbeecrypt.so.6: cannot
enable executable stack as shared object requires: Permission denied

This error means a problem with libbeecrypt.so.6 which is incorrectly
trying to execute code in the non-executable stack.

There's a workaround using chpax -ps /bin/rpm but it doesn't mean an
error in GR Security since the purpose of PAX stack protection is to
protect the security of the system against stack attacks so it should
never be turned off. It's beecrypt library the one that should use
cleaner methods for loading executable code like ld.so.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Install Fedora Core 2
2. Compile kernel With GR Security and PAX stack protection enabled
3. rpm --version

Additional info:
Comment 1 Jeff Johnson 2004-09-09 07:39:40 EDT
beecrypt sources execute no code in the stack I'm aware of,
so "loading executable code like ld.so" is not going to be
a solution afaik.

What is the problem precisely? Can you provide more details?
I suspect that this is a generic problem using NPTL rather
than a specific beecrypt problem.
Comment 2 Sandino Araico Sánchez 2004-09-09 15:55:48 EDT
The error happens when running rpm

rpm --help
rpm: error while loading shared libraries: libbeecrypt.so.6: cannot
enable executable stack as shared object requires: Permission denied

It doesn't seem to be a problem in the executable since the error
message explicitly indicates that the shared object is the one trying
to (for some reason) enable the executable stack. 

I haven't looked at the source code, I have no clues about what to
look for but I will attach a strace dump hoping it's useful.
Comment 3 Sandino Araico Sánchez 2004-09-09 16:04:23 EDT
Created attachment 103650 [details]
strace rpm --help

This is the output of strace rpm --help
Hope it's useful
Comment 4 Jeff Johnson 2004-09-09 17:13:53 EDT
If happening with rpm --help, then this is a load, not
a run-time, issue, and has to do with elf sections and
how beecrypt is built, not how beecrypt is executed.

The strace confirms.

AFAIK, executable stacks are what was (and perhaps still is) the
intent on recent RH distros.

I will check tomorrow.
Comment 5 Jeff Johnson 2004-09-10 19:52:01 EDT
AFAIK, executables stacks are what is intended on ix86.

Howvere, there appears to be some PT_GNU_STACK that might
be attached to the beecrypt stack when building that
might permit running in rpm in your GRsec environment.
STill investigating, dunno yet ...
Comment 6 Jeff Johnson 2004-09-14 06:56:59 EDT
Jakub: Is PT_GNU_STACK the best way to fix this?
Comment 7 Jakub Jelinek 2004-09-14 09:13:47 EDT
In FC2+ certainly (and in RHEL3 U3+ if possible too) all shared libraries
should have PT_GNU_STACK header.
If a shared library doesn't need executable stack, it should be
PF_R|PF_W, otheriwse PF_R|PF_W|PF_X.
readelf -l /usr/lib/libbeecrypt.so.6.2.0 | grep STACK
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4

The flag in a shared library is determined by executable stack
flags in each of its inputs.
readelf -WS /usr/lib/libbeecrypt.a | grep '^File\|.note.GNU-stack'
If a .note.GNU-stack section has X flags, it means the object requires
executable stack, if it contains no flags, it means it doesn't require
executable stack.
If .note.GNU-stack section is missing, it is unknown (and linker has
to assume executable stack if there were any markings at all).
Seems there are no objects that require executable stack from GCC, and
File: /usr/lib/libbeecrypt.a(aesopt.o)
File: /usr/lib/libbeecrypt.a(blowfishopt.o)
File: /usr/lib/libbeecrypt.a(mpopt.o)
File: /usr/lib/libbeecrypt.a(sha1opt.o)
are unknown.  Most probably these are assembly files, which have to
be marked manually.  These have to be skimmed if they don't need executable stack,
and if they don't, there are 3 ways:
1) add
.section .note.GNU-stack,"",@progbits; .previous
to each .s/.S file that doesn't need executable stack
2) assemble the file with -Wa,--noexecstack (when using gcc)
   or --noexecstack (when using as directly, which you shouldn't)
3) during final link override, with -Wl,-z,noexecstack

BTW, if GRsecurity can't handle programs that really require executable
stack (e.g. Ada and lots of other programs), it is IMHO terminally broken.
Comment 8 PaX Team 2004-09-14 19:36:16 EDT
grsecurity (or more precisely, PaX in it) can very well handle 
executable stacks, despite your snide remark (you can't help making 
them when it's about competing (and better) security solutions?). the 
problem that manifested with libbeecrypt is however a typical sign of 
the terminally broken PT_GNU_STACK approach.

for security purposes it's absolutely irrelevant whether the stack 
alone is executable or not. what matters is whether a given piece of 
code wants to generate code at runtime or not. where it does that is 
irrelevant, once the program needs this privilege, all bets are off 
as to what an attacker can do, he's already working with the ability 
to generate code at runtime and can leverage that to execute his own 
payload (this is the consequence of what we call the assumption of 
arbitrary read/write ability, and it is the accepted threat model in 
this field of research and exploit prevention measures are supposed 
to stand up to it). therefore any attempt to regulate stack execution 
is missing the big picture and is positively useless for security 
purposes (which somewhat ironically was probably the motivation 
behind the 'design' of PT_GNU_STACK).

the implementation of PT_GNU_STACK is also terminally broken as you 
can witness it here and many other places that don't reach the redhat 
bugzilla. the biggest offence is probably make_stack_executable() 
that is about as good a backdoor (circumvention device for this very 
security measure) as it can get. you do realize that once an attacker 
has control over a function pointer (remember the ultimate threat 
model), he can call this function and make the stack (and as a 
sidenote, under ExecShield/i386 the entire address space) executable 
without any fuss? randomization is pretty much irrelevant, a 
pointless 12 bits under ExecShield, and nothing on other systems (in 
PaX based systems we have at least 16 bits, but instead of relying on 
randomization we simply disable this piece of code and solve the 
problem another way, without exposing innocent applications to this 
security nightmare).

the other implementation problem is that the toolchain has extremely 
poor 'detection' ability for the need of an executable stack, it's 
pretty much about the nested function trampolines. there are more 
ways to generate code on the stack, none of which is detected by the 
toolchain and hence this entire PT_GNU_STACK approach is just broken. 
if you're going to suggest the manual inspection of packages then you 
might as well just mark them for runtime code generation and solve 
the real underlying problem at once.

to conclude, instead of PT_GNU_STACK you should have followed what 
PaX does and give the ability to control runtime code generation in 
general. using another program header that is considered only for the 
main executable is the only secure way of doing it, everything else 
is trivially circumvented (so no need for silly ld.so magic, ld 
should simply propagate the marking info into the main executable or 
force it one way via command line switches).

PS. there's a 4th way of fixing this problem quickly: execstack -c.
Comment 9 Jeff Johnson 2004-09-15 10:04:39 EDT
Please, argue executable stack design issues somewhere other than here.

The beecrypt maintainer is going to add
    .section .note.GNU-stack,"",@progbits; .previous
to the asm in beecrypt-4.1.0, release promised a couple weeks
Comment 10 PaX Team 2004-09-15 11:13:12 EDT
this bug is caused by the fundamentally flawed design and 
implementation of PT_GNU_STACK, of course i will report it here. not 
wanting to hear about it doesn't make the problem go away, there are 
and will always be more libraries suffering from the same problem. at 
least i can now point people here, and i won't have to repeat myself 
over and over again. and thanks for listening at least.
Comment 11 Sandino Araico Sánchez 2004-09-15 21:11:04 EDT
I will let you know if the problem persists when beecrypt-4.1.0 is
Comment 12 Joe Orton 2005-01-12 10:23:04 EST
PHP Warning:  PHP Startup: Unable to load dynamic library
'/usr/lib/php/modules/snmp.so' - libbeecrypt.so.6: cannot enable
executable stack as shared object requires: Permission denied in
Unknown on line 0

Not resolved in Raw Hide, also the Fedora CVS beecrypt/devel does not
build due to messed up sources file/missing .tar.gz upload, I think:

jorton@jedi:devel$ cat sources
877aa312c8338b84ff438b53917ce880  beecrypt-4.0.0.tar.gz.sig

.sig should not be a source...
Comment 13 Jeff Johnson 2005-02-07 14:08:39 EST
beecrypt-4.1.2-1 includes autoconf check:
    checking whether the linker can use noexecstack... yes
and links with -Wa,--noexecstack.

Including the original .sig permits independent strong
test that the tarball is untouched.

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