pax + fedora

[h4x0r]

I've got a pretty standard fedora box that I've disabled prelinking on and compiled a vanilla 2.4.24 + grsec. I've been able to use all of the grsecurity features except segmexec. It complains about error while loading shared libraries for some binaries. I'm fairly certain that this is a common problem, there's some stuff on google about it, I've read that the solution is to recompile glibc with the execstack-disable patch. Anyone have succcess with this?

[cmouse]

You've disabled text relocations. Most likely. This prevents certain libraries from loading.

[h4x0r]

# CONFIG_GRKERNSEC_PAX_NOELFRELOCS is not set

I actually was stupid enough to accidently enable that option when it first was introduced to grsecurity though

But I believe this problem is specific to fedora because of something redhat has changed in glibc. This guy from the vserver list was having the same problem:

http://list.linux-vserver.org/archive/v ... 05121.html

[PaX Team]

I actually was stupid enough to accidently enable that option when it first was introduced to grsecurity though

actually it's not a stupid thing to enable but your userland had better be prepared for it .

But I believe this problem is specific to fedora because of something redhat has changed in glibc. This guy from the vserver list was having the same problem:

http://list.linux-vserver.org/archive/v ... 05121.html

this is a problem with glibc which will eventually hit all distros as they upgrade (i think 2.3.3 will have the code in question). what the RedHat guys cooked up for supporting ExecShield and gcc nested function trampolines is that they introduced an ELF marking scheme (google for PT_GNU_STACK if you want the details) that in turn is 'understood' by both the(ir) kernel and ld.so. what the ld.so piece does is that when it detects the need for an executable stack in a given library (in practice that's the result of the use of the gcc nested function trampoline) it will call an internal function called make_stack_executable() that does just what its name implies. this is also the point of failure as in the typical PaX setup you have MPROTECT on and that doesn't allow something like this to happen (imagine a return-to-libc style attack to call this function then the payload...). there's also a problem with mixing gcc versions: if you have objects (libraries) produced by different versions of gcc (or other compilers/assemblers) then chances are that some of them don't have the proper markings (in a .o file that would be a .note.GNU-stack section). now when you link an executable/library from objects with such a mixed origin, the linker will mark the output with an executable PT_GNU_STACK program header (to be backwards compatible). as you can guess, that's a fast way to provoke the runtime error you ran into.

now as for fixing this mess:

1. you can take out make_stack_executable() from glibc/ld.so (that's advisable anyway for a secure setup), or just neutralize it by having it ignore the EACCES error from mprotect(). i know that Gentoo took the latter approach and it works.

2. in the not too distant past i added support for PT_GNU_STACK in PaX (i use it to enable EMUTRAMP as needed, this is about the only useful feature of this marking) but it only works when the main executable carries this mark, for libraries it won't work (which is the case that hit you). however you can explicitly mark your executables that load such shared libraries: when you link them add the -z execstack switch to ld or -Wl,-z,execstack to gcc (there's also an execstack utility in the latest prelink package that can do the same). of course before starting this executable (re)marking campaign you should verify first that the library in question does actually use nested functions and wasn't marked because it was merely linked from a mixed set of object files.

3. you can disable MPROTECT in your kernel config or on the affected executables. this is the least desirable approach of course as it will open up a nice attack vector for exploits.

4. the best solution is of course to get rid of nested functions altogether, but that requires some programming effort and is a slow process.

[h4x0r]

From what I can tell the provided execstack-disable patch disables _dl_make_stack_executable(), which should satisfy #1 on the mess fix list. I'm sure you're right and none of the stuff I run on that box needs to have been marked as needing an execstack but was almost certainly marked that way because of pre pt_gnu_stack stuff included when it was compiled.

It's too bad they had to add this "feature" to glibc in such a way that it breaks the segm/mprotect feature(s). Is there any chance of fixing this in kernelspace in the future or are we stuck with rebuilding the glibc libraries along with the kernel from now on? (when I say "now on" I mean untill pt_gnu_stack has been around long enough that I don't have anything linked against old stuff )

btw my box seems to be running normally since i applied the patch.

cheers.

[PaX Team]

Is there any chance of fixing this in kernelspace in the future

i could fix it but i don't want to. one reason is that it would add unnecessary complexity (i'd have to verify every file mapping and see if that's a ELF with an executable PT_GNU_STACK segment, i.e., what ld.so already does in userland) then enable EMUTRAMP or whatever). the other more fundamental reason is that there's enough crap in userland already that the kernel (well, at least PaX) has to be aware of (EMUPLT on many non-i386 archs), i don't want to play this game of fixing badly thought out userland 'features' in the kernel.

or are we stuck with rebuilding the glibc libraries along with the kernel from now on?

i don't quite understand this, to remove make_stack_executable() you have to rebuild glibc once only, the kernel has nothing to do with it.

[h4x0r]

I meant from a maintenance point of view, as updated packages come out I'll have to rebuild said package again. When Fedora core2 comes out in a couple months another rebuild. It's not that big of deal it's just glibc takes alot longer to build than the kernel does. Obviously I won't be doing it again untill it's updated.