Re: [gentoo-hardened] 2.6.27-hardened-r8: assassination

[Anthony G. Basile]

On 03/09/2011 04:03 AM, pageexec@××××××××.hu wrote:
> On 8 Mar 2011 at 15:55, Mike Frysinger wrote:
>
>> On Tue, Mar 8, 2011 at 3:49 PM, Anthony G. Basile wrote:
>>> Nothing to say that Mike hasn't already said.  pipacs knows about this
>>> but what can he do?  Good luck with upstream glibc.  Next time I speak
>>> with pipacs I can bring it up, see if anything is changing.  I doubt it.
>>
>> if there is a real bug in glibc that drepper is ignoring, that doesnt
>> mean we cant merge it into Gentoo's glibc.  hence open a bug in
>> bugs.g.o with the patch for me to review.
>
> it's not just a glibc bug, it's the whole shit concept of GNU_STACK and
> all it brings with it, see my Nth explanation here:
>
>   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611195#10
>
> i can (and do) disable GNU_STACK handling in PaX, but userland is out of
> my reach (well, technically i could do even that by hacking the page cache
> but that's too ugly to even consider). so as far as i'm concerned, you have
> the following choices in order of preference:
>
> 1. disable GNU_STACK processing (mostly in ld.so i think)
>    - this should solve all current and future problems but it won't be a
>      one-liner patch
>
> 2. fix at least the mprotect return value checks in ld.so
>    - the patch is in the glibc bugzilla
>    - this fixes only the segfaults, it won't let these app to work under PaX,
>    - actually, you could modify the patch and on the first mprotect failure
>      you can just not attempt the write to that relro variable (and not bother
>      with the second mprotect obviously), that should then let the library load
>      too (elsewhere gentoo already fixed the stack mprotect code and ignores
>      *its* mprotect failures under PaX)
>
> 3. execstack -c affected libs/binaries from portage
>    - at install time we can detect (and already do, iirc) RWE GNU_STACK headers
>    - if such a GNU_STACK header is really needed, i.e., the given app/lib does
>      need an executable stack (nested function trampolines are emulated under
>      PaX so they just need EMUTRAMP enabled on the app) then disable MPROTECT
>      on the app (and for libs, all apps using the given lib)
>    - if the RWE GNU_STACK header is a false positive, either fix the app (if we
>      have source code) or execstack -c for binaries.
>    - this is again quite some work
>
>

For what its worth, I've written some proof of concept code for this, a
library which needs execstack because of a trampoline which is
dlopen'ed.  I put the tarball on my dev space:

    http://dev.gentoo.org/~blueness/pocs/trampoline-poc.tgz

If you do

	CFLAGS+="-DTRAMPOLINE" make
	make install
	make dltest

you'll hit the above problem.  If you then do

	strace ./dltest

you'll see it dies because of mprotect.

Note: there's other stuff here because I'm using this in a class I'm
teaching.

-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
[phone]