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-19-2009, 01:50 PM
 
Default 2.6.27-hardened-r8: assassination

On 7 Mar 2009 at 1:46, Alex Efros wrote:

> Hi!
>
> On Fri, Mar 06, 2009 at 03:25:16PM -0800, Ned Ludd wrote:
> > 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.
>
> Some changes in hardened-sources trigger this bug (which exists for years
> and don't bother anybody) and kill my servers (apache and perl are
> critical for normal server operation).

you're both correct . the bug is in glibc and it got 'fixed' (see below)
and that 'fix' worked until recently when i did make a change (for security)
that exposed how wrong that fix was.

the glibc bug revolves around the well known GNU_STACK braindamage. in this
case glibc maintains an internal variable that tracks the executable status
(access rights, to be precise) of stacks. it has to be a dynamic property (vs.
something decided at process creation) as under the GNU_STACK approach apps
can load libraries at runtime that need an executable stack and glibc has to
create future stacks with that in mind (beyond mprotecting all existing ones).

now this variable happened to be put into the RELRO segment, so you can imagine
how it would segfault if an app tried to load such a library.

the 'fix' was to mprotect the variable temporarily so that it could be updated...
except this directly contradicts the definition and purpose of RELRO of course.
not to mention that they royally screwed up the ret2libc 'prevention' as well
at the same time. that's two birds with one shot for the guys at Red Hat .

here's the commit in question:

http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/elf/dl-load.c.diff?r1=1.270&r2=1.271&cvsroot=glibc&f=h

yes, that dates back to 2005 and has been broken ever since.

now what i changed recently was the result of a cleanup in textrel handling.
in earlier versions PaX could allow text relocations (which circumvent
MPROTECT, so it's less than ideal of course) by parsing the ELF headers and
making decisions based on that. for reasons i forget now, i didn't put that
code into the ELF loader so it only supported one kind of ELF, that of the
kernel's bitness. so you'd get textrel processing for your 64 bit amd64
executables, but not for your 32 bit i386 userland on a 64 bit kernel. this
is what i fixed up so now it works for any userland that the kernel's ELF
loader gets compiled for.

along the way i also i implemented a long-standing item on my todo list:
enforcement of RELRO. what it means is that when the kernel detects the
final mprotect(PROT_READ) from userland on a RELRO segment, the new logic
in PaX will change the access rights so that PROT_WRITE cannot be granted
to it ever again (that's kinda the idea behind RELRO after all, it's just
not enforced by the normal kernel). and as you can guess, that enforcement
directly contradicts what the above mentioned 'fix' wants to do.

so there you have it, another little episode in the drama played by Red Hat
where the left hand doesn't seem to know what the right one was doing.
 
Old 03-19-2009, 03:46 PM
John Eckhart
 
Default 2.6.27-hardened-r8: assassination

On Thu, Mar 19, 2009 at 10:50 AM, <pageexec@freemail.hu> wrote:

On 7 Mar 2009 at 1:46, Alex Efros wrote:



> Hi!

>

> On Fri, Mar 06, 2009 at 03:25:16PM -0800, Ned Ludd wrote:

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

>

> Some changes in hardened-sources trigger this bug (which exists for years

> and don't bother anybody) and kill my servers (apache and perl are

> critical for normal server operation).



you're both correct . the bug is in glibc and it got 'fixed' (see below)

and that 'fix' worked until recently when i did make a change (for security)

that exposed how wrong that fix was.



the glibc bug revolves around the well known GNU_STACK braindamage. in this

case glibc maintains an internal variable that tracks the executable status

(access rights, to be precise) of stacks. it has to be a dynamic property (vs.

something decided at process creation) as under the GNU_STACK approach apps

can load libraries at runtime that need an executable stack and glibc has to

create future stacks with that in mind (beyond mprotecting all existing ones).



now this variable happened to be put into the RELRO segment, so you can imagine

how it would segfault if an app tried to load such a library.



the 'fix' was to mprotect the variable temporarily so that it could be updated...

except this directly contradicts the definition and purpose of RELRO of course.

not to mention that they royally screwed up the ret2libc 'prevention' as well

at the same time. that's two birds with one shot for the guys at Red Hat .



here's the commit in question:



*http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/elf/dl-load.c.diff?r1=1.270&r2=1.271&cvsroot=glibc&f=h




yes, that dates back to 2005 and has been broken ever since.



now what i changed recently was the result of a cleanup in textrel handling.

in earlier versions PaX could allow text relocations (which circumvent

MPROTECT, so it's less than ideal of course) by parsing the ELF headers and

making decisions based on that. for reasons i forget now, i didn't put that

code into the ELF loader so it only supported one kind of ELF, that of the

kernel's bitness. so you'd get textrel processing for your 64 bit amd64

executables, but not for your 32 bit i386 userland on a 64 bit kernel. this

is what i fixed up so now it works for any userland that the kernel's ELF

loader gets compiled for.



along the way i also i implemented a long-standing item on my todo list:

enforcement of RELRO. what it means is that when the kernel detects the

final mprotect(PROT_READ) from userland on a RELRO segment, the new logic

in PaX will change the access rights so that PROT_WRITE cannot be granted

to it ever again (that's kinda the idea behind RELRO after all, it's just

not enforced by the normal kernel). and as you can guess, that enforcement

directly contradicts what the above mentioned 'fix' wants to do.



so there you have it, another little episode in the drama played by Red Hat

where the left hand doesn't seem to know what the right one was doing.






It seems like we have a multiway catch22 as the fix for the kernel was correct from both a security and a "trueness to specification" standpoint and the fix for glibc will likely be a long time in coming. Based on that, I would think that the best "gentoo" fix is to put the execstack call into the ebuild (conditionally run on the hardened use flag). However, execstack is part of the prelink, which, by nature, is not compatible with hardened. Any suggestions how to proceed?
 
Old 03-20-2009, 09:31 PM
 
Default 2.6.27-hardened-r8: assassination

On 19 Mar 2009 at 12:46, John Eckhart wrote:

> It seems like we have a multiway catch22 as the fix for the kernel was
> correct from both a security and a "trueness to specification" standpoint
> and the fix for glibc will likely be a long time in coming. Based on that, I
> would think that the best "gentoo" fix is to put the execstack call into the
> ebuild (conditionally run on the hardened use flag). However, execstack is
> part of the prelink, which, by nature, is not compatible with hardened. Any
> suggestions how to proceed?

prelink is compatible with PaX/ASLR as the mmap address hint is simply ignored
there. in any case, playing the GNU_STACK games has only one logical end that
i've advocated since the beginning: ignore it for good. for glibc in this case
that means moving __stack_prot out of RELRO.
 
Old 03-21-2009, 02:12 PM
 
Default 2.6.27-hardened-r8: assassination

I guess all the community members should say thank you to PaxTeam pointing
out such mistakes.

Who would be the best to push through a fix in glibc?

Regards:
Dw.
--
dr Tóth Attila, Radiológus, 06-20-825-8057, 06-30-5962-962
Attila Toth MD, Radiologist, +36-20-825-8057, +36-30-5962-962
--
dr Tóth Attila, Radiológus, 06-20-825-8057, 06-30-5962-962
Attila Toth MD, Radiologist, +36-20-825-8057, +36-30-5962-962

On Pén, Március 20, 2009 23:31, pageexec@freemail.hu wrote:
> On 19 Mar 2009 at 12:46, John Eckhart wrote:
>
>> It seems like we have a multiway catch22 as the fix for the kernel was
>> correct from both a security and a "trueness to specification"
>> standpoint
>> and the fix for glibc will likely be a long time in coming. Based on
>> that, I
>> would think that the best "gentoo" fix is to put the execstack call into
>> the
>> ebuild (conditionally run on the hardened use flag). However, execstack
>> is
>> part of the prelink, which, by nature, is not compatible with hardened.
>> Any
>> suggestions how to proceed?
>
> prelink is compatible with PaX/ASLR as the mmap address hint is simply
> ignored
> there. in any case, playing the GNU_STACK games has only one logical end
> that
> i've advocated since the beginning: ignore it for good. for glibc in this
> case
> that means moving __stack_prot out of RELRO.
>
>
 
Old 03-08-2011, 05:40 PM
Alex Efros
 
Default 2.6.27-hardened-r8: assassination

Hi!

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.

--
WBR, Alex.
 
Old 03-08-2011, 06:05 PM
Mike Frysinger
 
Default 2.6.27-hardened-r8: assassination

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.
-mike
 
Old 03-08-2011, 06:52 PM
Alex Efros
 
Default 2.6.27-hardened-r8: assassination

Hi!

On Tue, Mar 08, 2011 at 02:05:46PM -0500, Mike Frysinger wrote:
> 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.

Actually, from initial discussion I got impression this is *well* known
(at least to PaX/Hardened/Glibc developers) issue, so there unlikely any
needs in opening new bug. And I don't have patch for glibc. If anyone
think it have sense to report this to gentoo's bugzilla - I'll do it.

--
WBR, Alex.
 
Old 03-08-2011, 07:01 PM
Mike Frysinger
 
Default 2.6.27-hardened-r8: assassination

On Tue, Mar 8, 2011 at 2:52 PM, Alex Efros wrote:
> On Tue, Mar 08, 2011 at 02:05:46PM -0500, Mike Frysinger wrote:
>> 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.
>
> Actually, from initial discussion I got impression this is *well* known
> (at least to PaX/Hardened/Glibc developers) issue, so there unlikely any
> needs in opening new bug. And I don't have patch for glibc. If anyone
> think it have sense to report this to gentoo's bugzilla - I'll do it.

nothing in the e-mail you quoted said this was a kernel bug. it did
however say "glibc bug" multiple times.
-mike
 
Old 03-08-2011, 07:48 PM
klondike
 
Default 2.6.27-hardened-r8: assassination

2011/3/8 Alex Efros <powerman@powerman.name>:
> Actually, from initial discussion I got impression this is *well* known
> (at least to PaX/Hardened/Glibc developers) issue, so there unlikely any
> needs in opening new bug. And I don't have patch for glibc. If anyone
> think it have sense to report this to gentoo's bugzilla - I'll do it.

With the "Just use a supported kernel" guy maintaining glibc I doubt
this is going to change soon
 
Old 03-08-2011, 07:49 PM
"Anthony G. Basile"
 
Default 2.6.27-hardened-r8: assassination

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

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.

Take a look at [1] for a good laugh.


Ref:

[1] http://sourceware.org/bugzilla/show_bug.cgi?id=12492

--
Anthony G. Basile, Ph.D.
Gentoo Developer
 

Thread Tools




All times are GMT. The time now is 04:29 PM.

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