[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#321718: Upgrade caused many libs to complain about "executable stack"

unmerge 321724
reassign 321724 libelfg0 0.8.5-1
unmerge 321723
reassign 321723 libgdbm3 1.8.3-2
unmerge 321721
reassign 321721 libssl0.9.7 0.9.7e-3
severity 321721 minor
unmerge 321720
reassign 321720 libgcrypt11 1.2.0-11.1
severity 321720 minor

On Sun, Aug 07, 2005 at 11:28:41AM +0200, Jerzy Kozera wrote:
> On Sun, 2005-08-07 at 01:51 -0700, Steve Langasek wrote:
> > > Google suggests this has something to do with "pax", which I've never 
> > > heard of and have certainly never installed or enabled.

> > > -- System Information:
> > > Debian Release: testing/unstable
> > >   APT prefers stable
> > >   APT policy: (500, 'stable')
> > > Architecture: i386 (i686)
> > > Shell:  /bin/sh linked to /bin/bash
> > > Kernel: Linux 2.4.18-bf2.4
> > > Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

> [...]

> > It should be straightforward for you to fix your system by installing a
> > 2.4.27 kernel from sarge and rebooting the machine, which is the supported
> > upgrade path in any case.  This means the bug should not be considered
> > critical; I've downgraded it accordingly.

> > It is still important that the glibc package be fixed, so that it does not
> > permit installation on an unsupported kernel.  This has been done in the
> > past for select architectures, but it seems we now have a reason to bump the
> > requirement across all architectures, which should give the glibc team a
> > nice clean start (and a nice clean preinst) for etch. :)

> This bug appears with my 2.6.x grsecurity/PaX kernel too. I'm getting
> similiar error with:
> $ wget
> wget: error while loading shared libraries: libcrypto.so.0.9.7: cannot
> enable executable stack as shared object requires: Permission denied

> It goes away after turning off mprotect() protection by chpax or
> downgrading libc6 back to 2.3.2-ds1-22.

> You might be interested in related threads at
> - debian-user: http://lists.debian.org/debian-user/2005/08/msg00747.html
> - grsecurity forums: http://forums.grsecurity.net/viewtopic.php?t=1152

> Will it be fixed so that libc will work with grsecurity/PaX?

Ok, after talking with Bastian Blank on IRC, it looks fairly implausible
that the version information provided in the original reports was at all
correct.  For one thing, the version of libacl1 that bug #321717 was
reported against was a binNMU version of the package which I uploaded to fix
exactly this issue in bug #301250!

So, even though running etch/sid against a woody kernel is indeed not
supported, that doesn't seem the issue here.

Instead, Joe, it looks like you *are* running a kernel on this machine that
has grsec enabled, even if you don't know how it got there.  It would be
helpful to have more complete information from the actual system in question
to confirm this, though.

I can confirm that the binaries of libacl1 and libelfg0 that shipped in
sarge were built with an old compiler that did not properly set
PT_GNU_STACK.  The libacl1 bug was fixed in the binNMU mentioned.  The bug
in libelfg0 has not been fixed; I've unmerged 321724 and reassigned it back
to libelfg0.  Alex, this should be fixable with a simple rebuild of the

I cannot directly confirm which compiler version was used for building gdbm,
but this package was last rebuilt in September 2003, and the binary is
missing a PT_GNU_STACK header, so there is a reasonable chance it was built
with gcc-2.95.  The libgdbm3 package has the same version in sarge and in
sid; James, it looks like we may want to try rebuilding gdbm to see if it
fixes this problem.  Reassigned back to libgdbm3.

Both the sarge and the sid versions of libssl0.9.7 were definitely *not*
built with gcc-2.95, but they both have a PT_GNU_STACK header in
/usr/lib/i686/cmov/libcrypto.so.0.9.7 which explicitly requests an
executable stack.  This is not the same bug as the others, which were
getting an executable stack by default.  Since there may be legitimate
reasons for requesting an executable stack, I'm downgrading this bug to
minor in addition to reassigning it -- anyone playing with grsec/PaX should
be prepared for the possibility of having to deal with setting such policies
on binaries where needed.

The bug against libgcrypt11 is the same as that against libssl0.9.7 -- the
library has explicitly requested an executable stack.  I don't think this is
a coincidence: it's pretty likely that both of these libraries *use* the
executable stack, which means there's not much chance of them being fixed. 
Reassigning and downgrading, in any case.

The last bug, I'm leaving assigned to glibc, since that is the package whose
behavior change triggered these reports.  Of course, this is simply a case
of glibc bailing on error from mprotect() rather than silently ignoring the
permission issues, so I imagine the glibc maintainers won't do anything with
this bug except close it...

In any case, none of these bugs are of severity higher than important.
There is no policy that Debian supports grsec kernels, and this narrow use
case does not otherwise meet the definition of a "grave" or "critical" bug.

Steve Langasek
postmodern programmer

Attachment: signature.asc
Description: Digital signature

Reply to: