FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Hardened

 
 
LinkBack Thread Tools
 
Old 03-08-2011, 07:55 PM
Mike Frysinger
 
Default 2.6.27-hardened-r8: assassination

On Tue, Mar 8, 2011 at 3:49 PM, Anthony G. Basile wrote:
> On 03/08/2011 02:05 PM, Mike Frysinger wrote:
>> On Tue, Mar 8, 2011 at 1:40 PM, Alex Efros wrote:
>>> On Fri, Mar 06, 2009 at 03:25:16PM -0800, Ned Ludd wrote:
>>>>> On Fri, Mar 06, 2009 at 11:12:59PM +0200, pageexec@freemail.hu wrote:
>>>>>> ah crap, i know what it is. it's a several years old glibc bug where someone
>>>>>> put a certain variable into the RELRO segment but forgot that it'll be written
>>>>>> to later when a library with RWE GNU_STACK is loaded. the workaround is
>>>>>> to find that library (just extract them from strace, probably it'll be
>>>>>> pari's library) and run execstack -c on it.
>>>>>
>>>>> I don't have execstack command. Looks like it belong to prelink package,
>>>>> but http://www.gentoo.org/doc/en/prelink-howto.xml states it's
>>>>> incompatible with hardened. Because of this I decide to compile it
>>>>> manually, just to get execstack command:
>>>>>
>>>>> # emerge -f prelink
>>>>> # cd /usr/src
>>>>> # tar xjvf /usr/portage-distfiles/prelink-20071009.tar.bz2
>>>>> # cd prelink
>>>>> # ./configure && make
>>>>>
>>>>> Now I tried your workaround:
>>>>>
>>>>> # /usr/src/prelink/src/execstack -c /usr/lib/perl5/site_perl/5.8.8/i686-linux/auto/Math/Pari/Pari.so
>>>>> # /usr/src/prelink/src/execstack -c /usr/local/ioncube/ioncube_loader_lin_5.2.so
>>>>> # /usr/src/prelink/src/execstack -c /usr/local/Zend/lib/ZendExtensionManager.so
>>>>> # /usr/src/prelink/src/execstack -c /usr/local/Zend/lib/ZendExtensionManager_TS.so
>>>>> # /usr/src/prelink/src/execstack -c /usr/local/Zend/lib/Optimizer-3.3.0/php-5.2.x/ZendOptimizer.so
>>>>>
>>>>> and it works!!
>>>>>
>>>>> Is this issue will be fixed in next stable hardened-sources?
>>>>
>>>> FYI.. PaX Team maintains the PaX kernel and has little control over what
>>>> fixes go into the "next" hardened-sources. Also seems to me a little
>>>> strange that the PaX Team would have to put a work-around in the kernel
>>>> for a bug in glibc.. Seems like glibc should be fixed vs the kernel.
>>>
>>> 2 years later… Just updated system, bug still exists, and I still have to
>>> use execstack workaround for zendoptimizer and ioncube.
>>
>> like they said, this doesnt seem to be a bug in the kernel, so the pax
>> source arent going to be changing
>>
>> if there's a bug in glibc, an actual bug in bugs.g.o needs to be
>> opened with real details/patches. Â*otherwise, nothing is going to
>> change.
>
> 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.
-mike
 
Old 03-08-2011, 08:07 PM
Alex Efros
 
Default 2.6.27-hardened-r8: assassination

Hi!

On Tue, Mar 08, 2011 at 03:49:34PM -0500, Anthony G. Basile wrote:
> Take a look at [1] for a good laugh.

Yep, that was funny. BTW, if I understood correctly, with proposed
patch my apache won't segfault anymore, but zendoptimizer and ioncube libs
won't be loaded… so this isn't looks like complete solution for this issue.

--
WBR, Alex.
 
Old 03-09-2011, 08:03 AM
 
Default 2.6.27-hardened-r8: assassination

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
 
Old 03-09-2011, 12:07 PM
med
 
Default 2.6.27-hardened-r8: assassination

unsubsribe
 
Old 03-10-2011, 07:30 PM
"Anthony G. Basile"
 
Default 2.6.27-hardened-r8: assassination

On 03/09/2011 04:03 AM, pageexec@freemail.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
(716) 829-8197
 
Old 03-10-2011, 07:39 PM
"Anthony G. Basile"
 
Default 2.6.27-hardened-r8: assassination

On 03/09/2011 04:03 AM, pageexec@freemail.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.
Gentoo Developer
 

Thread Tools




All times are GMT. The time now is 12:53 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org