Bug 132149

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.

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.

Created attachment 103650 [details]
strace rpm --help

This is the output of strace rpm --help
Hope it's useful

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.

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 ...

Jakub: Is PT_GNU_STACK the best way to fix this?

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.
See
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.

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.

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
out.

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.

I will let you know if the problem persists when beecrypt-4.1.0 is
available.

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...

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.