Mailing List Archive

hi everyone,

I've been using grsecurity patches in a production box since January.
A couple of days ago, I had to reboot and found out that apache2 wouldn't
start. It couldn't start the php module (4.3.11 compiled the day before).
mod_php 4.3.10 was compiled in December 19 and worked fine even with
grsecurity.

gw root # /etc/init.d/apache2 restart
* Apache2 has detected a syntax error in your configuration files:
Syntax error on line 6 of /usr/lib/apache2/conf/modules.d/70_mod_php.conf:
Cannot load /usr/lib/apache2/extramodules/libphp4.so into
server: /usr/lib/apache2/extramodules/libphp4.so: cannot make segment
writable for relocation: Permission denied
gw root #

After some quick googling, I found this issue to be related to a PAX kernel
option that I have enabled:
(http://www.gentoo.org/proj/en/hardened/hardenedfaq.xml?style=printable#paxnoelf)

This apache2 mod_php module code may be killed by the kernel's PAX features,
but what puzzles me is that the old one (4.3.10) worked fine in the same
environment. The help text indicates that this could be result of misbehaving
assembly code... in mod_php??

After that, I tried
chpax -m /usr/sbin/apache2 /usr/lib/apache2/extramodules/libphp4.so
and even further with chpax -pmrs to the same files. No luck. What can be
going on here?

I tried recompiling the mod_php module but of course, no luck.

Any help?? I'd like to keep mprotect() restricted but with an exception for
mod_php... is this possible?

regards,
pedro venda.

p.s.: this is the second time I'm sending this, I didn't get it back and it
didn't appear in the list archives.
--

Pedro João Lopes Venda
email: pjlv < at > mega.ist.utl.pt
http://arrakis.dhis.org

I've had to drop the 'Disallow ELF text relocations' option due to
problems with MySQL, so I think you will be saving yourself some trouble
by going ahead and disabling it. It does some whacky things with compiles,
too.

just my 2 cents.. ;)

> hi everyone,
>
> I've been using grsecurity patches in a production box since January.
> A couple of days ago, I had to reboot and found out that apache2 wouldn't
> start. It couldn't start the php module (4.3.11 compiled the day before).
> mod_php 4.3.10 was compiled in December 19 and worked fine even with
> grsecurity.
>
> gw root # /etc/init.d/apache2 restart
> * Apache2 has detected a syntax error in your configuration files:
> Syntax error on line 6 of /usr/lib/apache2/conf/modules.d/70_mod_php.conf:
> Cannot load /usr/lib/apache2/extramodules/libphp4.so into
> server: /usr/lib/apache2/extramodules/libphp4.so: cannot make segment
> writable for relocation: Permission denied
> gw root #
>
> After some quick googling, I found this issue to be related to a PAX
> kernel
> option that I have enabled:
> (http://www.gentoo.org/proj/en/hardened/hardenedfaq.xml?style=printable#paxnoelf)
>
> This apache2 mod_php module code may be killed by the kernel's PAX
> features,
> but what puzzles me is that the old one (4.3.10) worked fine in the same
> environment. The help text indicates that this could be result of
> misbehaving
> assembly code... in mod_php??
>
> After that, I tried
> chpax -m /usr/sbin/apache2 /usr/lib/apache2/extramodules/libphp4.so
> and even further with chpax -pmrs to the same files. No luck. What can be
> going on here?
>
> I tried recompiling the mod_php module but of course, no luck.
>
> Any help?? I'd like to keep mprotect() restricted but with an exception
> for
> mod_php... is this possible?
>
> regards,
> pedro venda.
>
> p.s.: this is the second time I'm sending this, I didn't get it back and
> it
> didn't appear in the list archives.
> --
>
> Pedro João Lopes Venda
> email: pjlv < at > mega.ist.utl.pt
> http://arrakis.dhis.org
>


--
gentoo-security@gentoo.org mailing list

On Wed, 2005-05-04 at 16:04 +0100, Pedro Venda wrote:
> On Wednesday 04 May 2005 01:43, ixion wrote:
> > I've had to drop the 'Disallow ELF text relocations' option due to
> > problems with MySQL, so I think you will be saving yourself some trouble
> > by going ahead and disabling it. It does some whacky things with compiles,
> > too.
>


> my mysql works ok even with diallow ELF tex relocations. I don't intend to
> save myself from trouble just by removing security features. I want to
> understand the "why"s behind and to find out if I'm alone with this issue.

I wish more people had this attitude of wanting to get to the root of
the problem :)


Mike Frysinger and myself have written a package to help aid in the
tracking down of these text relocations and other faulty ELF problems.

It's called pax-utils and it's in ~arch
For a quick scan of things that you possiable need to rebuild that have
text relocations you would do something like this.
scanelf -lptq

Or a system wide deep scan.
scanelf -tRF%t%F /|grep TEXTREL

Now I know for a fact that this lib can be built without text
relocations. It's often the conversion process for normal users that
come from non hardened envionments to a hardened one that have this
problem. It's usually caused by a non pic aware libcrypto.a that gets
used to later link to the libphp4.so

> thanks for your help anyway.
>
> I've figured out some other interesting stuff:
>
> - chpax is deprecated - I should have used paxctl instead. my kernel is
> configured to use PT flags instead of EI PaX flags.

Sadly chpax can not be fully deprecated as of yet. There still existing
some corner stone cases such as java and a few other 3rd party vendor
things which will lack the PT_PAX_FLAGS program header. I enable both
for maximum administrator control.

> - glibc, gcc and binutils should be recompiled with hardened and pic flags.
> Will this affect the ELF binary produced by the mod_php compilation? Will it
> work this time, if compiled with PIC? Find out in a couple of days, when I
> have time to do some compilations and reboots.

I really recommended -e world (lot of other cases where non-pic
something.a gets mis linked in)

> regards,
> pedro venda.
--
Ned Ludd <solar@gentoo.org>

--
gentoo-security@gentoo.org mailing list

On Wednesday 04 May 2005 01:43, ixion wrote:
> I've had to drop the 'Disallow ELF text relocations' option due to
> problems with MySQL, so I think you will be saving yourself some trouble
> by going ahead and disabling it. It does some whacky things with compiles,
> too.

my mysql works ok even with diallow ELF tex relocations. I don't intend to
save myself from trouble just by removing security features. I want to
understand the "why"s behind and to find out if I'm alone with this issue.

thanks for your help anyway.

I've figured out some other interesting stuff:

- chpax is deprecated - I should have used paxctl instead. my kernel is
configured to use PT flags instead of EI PaX flags.
- glibc, gcc and binutils should be recompiled with hardened and pic flags.
Will this affect the ELF binary produced by the mod_php compilation? Will it
work this time, if compiled with PIC? Find out in a couple of days, when I
have time to do some compilations and reboots.

regards,
pedro venda.
--

Pedro João Lopes Venda
email: pjlv < at > mega.ist.utl.pt
http://arrakis.dhis.org

On Wednesday 04 May 2005 16:02, Ned Ludd wrote:
> On Wed, 2005-05-04 at 16:04 +0100, Pedro Venda wrote:
> > On Wednesday 04 May 2005 01:43, ixion wrote:
> > > I've had to drop the 'Disallow ELF text relocations' option due to
> > > problems with MySQL, so I think you will be saving yourself some
> > > trouble by going ahead and disabling it. It does some whacky things
> > > with compiles, too.
> >
> > my mysql works ok even with diallow ELF tex relocations. I don't intend
> > to save myself from trouble just by removing security features. I want to
> > understand the "why"s behind and to find out if I'm alone with this
> > issue.
>
> I wish more people had this attitude of wanting to get to the root of
> the problem :)
>
>
> Mike Frysinger and myself have written a package to help aid in the
> tracking down of these text relocations and other faulty ELF problems.
>
> It's called pax-utils and it's in ~arch
> For a quick scan of things that you possiable need to rebuild that have
> text relocations you would do something like this.
> scanelf -lptq
>
> Or a system wide deep scan.
> scanelf -tRF%t%F /|grep TEXTREL

this is GREAT! thanks for the information.

> Now I know for a fact that this lib can be built without text
> relocations. It's often the conversion process for normal users that
> come from non hardened envionments to a hardened one that have this
> problem. It's usually caused by a non pic aware libcrypto.a that gets
> used to later link to the libphp4.so

so the hardened toolchain could rebuild the offending library and link the
module against the pic object, resulting in a working combo?

>
> > thanks for your help anyway.
> >
> > I've figured out some other interesting stuff:
> >
> > - chpax is deprecated - I should have used paxctl instead. my kernel is
> > configured to use PT flags instead of EI PaX flags.
>
> Sadly chpax can not be fully deprecated as of yet. There still existing
> some corner stone cases such as java and a few other 3rd party vendor
> things which will lack the PT_PAX_FLAGS program header. I enable both
> for maximum administrator control.

yes, I absolutely forgot non-compiled packages.

> > - glibc, gcc and binutils should be recompiled with hardened and pic
> > flags. Will this affect the ELF binary produced by the mod_php
> > compilation? Will it work this time, if compiled with PIC? Find out in a
> > couple of days, when I have time to do some compilations and reboots.
>
> I really recommended -e world (lot of other cases where non-pic
> something.a gets mis linked in)

but the use flags hardened and pic seldom appear. I suppose that the flag is
not really necessary to build PIC code. the toolchain will do that for me.
is the flag there for known workarounds?

many many thanks for your informative reply!

regards,
pedro venda.
--

Pedro João Lopes Venda
email: pjlv < at > mega.ist.utl.pt
http://arrakis.dhis.org

On Wed, 4 May 2005, Pedro Venda wrote:

> > Now I know for a fact that this lib can be built without text
> > relocations. It's often the conversion process for normal users that
> > come from non hardened envionments to a hardened one that have this
> > problem. It's usually caused by a non pic aware libcrypto.a that gets
> > used to later link to the libphp4.so
>
> so the hardened toolchain could rebuild the offending library and link the
> module against the pic object, resulting in a working combo?

gcc should be rebuilt w/ hardened so that the system defaults to PIE
executables (ET_DYN), not ET_EXEC adding also SSP protection.

I had trouble myself w/ the php module and php itself (the shared lib)
having text relocations, the only solution for any corner case (also
working w/ uclibc) is to add --with-pic to econf (in ebuild). This is true
for a hardened system, any other proposed solution will break here and
there.

> > I really recommended -e world (lot of other cases where non-pic
> > something.a gets mis linked in)

I would propose before running emerge -e world to:
a. use a hardened profile (or add hardened pic USE)
b. rebuild gcc, binutils, gcc, glibc, gcc (in this order)

>
> but the use flags hardened and pic seldom appear. I suppose that the flag is
> not really necessary to build PIC code. the toolchain will do that for me.
gcc will change defaults as stated earlier

> is the flag there for known workarounds?
no

Peter

--
Peter S. Mazinger <ps dot m at gmx dot net> ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2

--
gentoo-security@gentoo.org mailing list

Hi pedro, did you solve this allready?

If not, I suggest you try to reach the paxguy in the grsec ML.

best regards, abraços

On 5/1/05, Pedro Venda <pjlv@mega.ist.utl.pt> wrote:
> hi everyone,
>
> I've been using grsecurity patches in a production box since January.
> Today I had to reboot and found out that apache2 wouldn't start. Reason was
> that it couldn't start the php module. The guilty php module comes from
> mod_php 4.3.11 ebuild, compiled yesterday. mod_php 4.3.10 was compiled in
> December 19.
>
> gw root # /etc/init.d/apache2 restart
> * Apache2 has detected a syntax error in your configuration files:
> Syntax error on line 6 of /usr/lib/apache2/conf/modules.d/70_mod_php.conf:
> Cannot load /usr/lib/apache2/extramodules/libphp4.so into
> server: /usr/lib/apache2/extramodules/libphp4.so: cannot make segment
> writable for relocation: Permission denied
> gw root #
>
> After some quick googling, I found this issue to be related to a PAX kernel
> option that I have enabled:
> (http://www.gentoo.org/proj/en/hardened/hardenedfaq.xml?style=printable#paxnoelf)
>
> This apache2 mod_php module code may be killed by the kernel's PAX features,
> but what puzzles me is that the old one (4.3.10) worked fine in the same
> environment. The help text indicates that this could be result of misbehaving
> assembly code... in mod_php??
>
> Does any one else has this kind of problems with mod_php? I'll try recompiling
> mod_php... but I don't think it'll solve anything. I may have to cut down
> this feature in the kernel.
>
> regards,
> pedro venda.
> --
>
> Pedro João Lopes Venda
> email: pjlv < at > mega.ist.utl.pt
> http://arrakis.dhis.org
>
>
>


--
Miguel Sousa Filipe

--
gentoo-security@gentoo.org mailing list

On Friday 17 June 2005 12:00, Miguel Filipe wrote:
> Hi pedro, did you solve this allready?

not sure,

I've been messing with mysql and apache, but I've also been very busy (you
know...)

will check on that soon. either it is solved or it needs a paxctl
-m /usr/sbin/whatever/apache2

thanks for the reminder.

regards,
pedro venda.

>
> If not, I suggest you try to reach the paxguy in the grsec ML.
>
> best regards, abraços
>
> On 5/1/05, Pedro Venda <pjlv@mega.ist.utl.pt> wrote:
> > hi everyone,
> >
> > I've been using grsecurity patches in a production box since January.
> > Today I had to reboot and found out that apache2 wouldn't start. Reason
> > was that it couldn't start the php module. The guilty php module comes
> > from mod_php 4.3.11 ebuild, compiled yesterday. mod_php 4.3.10 was
> > compiled in December 19.
> >
> > gw root # /etc/init.d/apache2 restart
> > * Apache2 has detected a syntax error in your configuration files:
> > Syntax error on line 6 of
> > /usr/lib/apache2/conf/modules.d/70_mod_php.conf: Cannot load
> > /usr/lib/apache2/extramodules/libphp4.so into
> > server: /usr/lib/apache2/extramodules/libphp4.so: cannot make segment
> > writable for relocation: Permission denied
> > gw root #
> >
> > After some quick googling, I found this issue to be related to a PAX
> > kernel option that I have enabled:
> > (http://www.gentoo.org/proj/en/hardened/hardenedfaq.xml?style=printable#p
> >axnoelf)
> >
> > This apache2 mod_php module code may be killed by the kernel's PAX
> > features, but what puzzles me is that the old one (4.3.10) worked fine in
> > the same environment. The help text indicates that this could be result
> > of misbehaving assembly code... in mod_php??
> >
> > Does any one else has this kind of problems with mod_php? I'll try
> > recompiling mod_php... but I don't think it'll solve anything. I may have
> > to cut down this feature in the kernel.
> >
> > regards,
> > pedro venda.
> > --
> >
> > Pedro João Lopes Venda
> > email: pjlv < at > mega.ist.utl.pt
> > http://arrakis.dhis.org
>
> --
> Miguel Sousa Filipe

--

Pedro João Lopes Venda
email: pjvenda < at > arrakis.dhis.org
http://arrakis.dhis.org

I'm running 2.6 hardened-kernel with php 4.3.11 + 2.0.54-r4 apache and it
compiles/runs fine. Sounds like you have text relocations disabled?

At 04:00 AM 6/17/2005, you wrote:
>Hi pedro, did you solve this allready?
>
>If not, I suggest you try to reach the paxguy in the grsec ML.
>
>best regards, abraços
>
>On 5/1/05, Pedro Venda <pjlv@mega.ist.utl.pt> wrote:
> > hi everyone,
> >
> > I've been using grsecurity patches in a production box since January.
> > Today I had to reboot and found out that apache2 wouldn't start. Reason was
> > that it couldn't start the php module. The guilty php module comes from
> > mod_php 4.3.11 ebuild, compiled yesterday. mod_php 4.3.10 was compiled in
> > December 19.
> >
> > gw root # /etc/init.d/apache2 restart
> > * Apache2 has detected a syntax error in your configuration files:
> > Syntax error on line 6 of /usr/lib/apache2/conf/modules.d/70_mod_php.conf:
> > Cannot load /usr/lib/apache2/extramodules/libphp4.so into
> > server: /usr/lib/apache2/extramodules/libphp4.so: cannot make segment
> > writable for relocation: Permission denied
> > gw root #
> >
> > After some quick googling, I found this issue to be related to a PAX kernel
> > option that I have enabled:
> >
> (http://www.gentoo.org/proj/en/hardened/hardenedfaq.xml?style=printable#paxnoelf)
> >
> > This apache2 mod_php module code may be killed by the kernel's PAX
> features,
> > but what puzzles me is that the old one (4.3.10) worked fine in the same
> > environment. The help text indicates that this could be result of
> misbehaving
> > assembly code... in mod_php??
> >
> > Does any one else has this kind of problems with mod_php? I'll try
> recompiling
> > mod_php... but I don't think it'll solve anything. I may have to cut down
> > this feature in the kernel.
> >
> > regards,
> > pedro venda.
> > --
> >
> > Pedro João Lopes Venda
> > email: pjlv < at > mega.ist.utl.pt
> > http://arrakis.dhis.org
> >
> >
> >
>
>
>--
>Miguel Sousa Filipe
>
>--
>gentoo-security@gentoo.org mailing list


--
gentoo-security@gentoo.org mailing list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>
> not sure,
>
> I've been messing with mysql and apache, but I've also been very busy (you
> know...)
>
> will check on that soon. either it is solved or it needs a paxctl
> -m /usr/sbin/whatever/apache2
>
> thanks for the reminder.
>
> regards,
> pedro venda.


mod_php contains a ton of TEXTREL's as can be seen with `scanelf -T
/usr/lib/apache2-extramodules/libphp4.so` (scanelf comes from the
pax-utils package, you should get the ~arch version).

As the FAQ said, you will get the error if you have your kernel
disallowing text relocations(CONFIG_PAX_NOELFRELOCS). There are still
enough things containing textrels that for now, it's probably easiest to
disable that option, the other option, as stated, would be to disable
MPROTECT on the appropriate files.

Robert
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCsv+/ZwjIiODIZ4oRAjQJAJwOmFgDZPBZo8sNUtOSGHFS1mmJ+ACfRHPk
R/Ykoh6uZela1QIhhFQD+Wo=
=pgMT
-----END PGP SIGNATURE-----
--
gentoo-security@gentoo.org mailing list

On Fri, 2005-06-17 at 09:31 -0700, Hoka "ME" Tichenci wrote:
> I'm running 2.6 hardened-kernel with php 4.3.11 + 2.0.54-r4 apache and it
> compiles/runs fine. Sounds like you have text relocations disabled?
>
I've had something similar on the same versions, which was due to the
libraries in use by php.
revdep-rebuild solved it. Or rebuild them manually. (it wasn't php
itself)

2p
Antoine

--
gentoo-security@gentoo.org mailing list