grsec 1.9.4 + apache 1.3.26 + php 4.2.3 -> out of memory?

[Darkman]

Hi there,

i know that grsec 1.9.4 isn't really up to date, but before building a new
kernel at all i want to ask first if my problem is a grsec problem.
I have apache 1.3.26 with php 4.2.3 running in a chroot enviroment.
After a couple of days (about 5) php runs out of memory. log entrys:
PHP Fatal error: Allowed memory size of 12582912 bytes exhausted (tried to allocate 42 bytes) in Unknown on line 0

Can the source of that be CHROOT_CAPS or PaX setup?

thanks for help

[PaX Team]

After a couple of days (about 5) php runs out of memory. log entrys:
PHP Fatal error: Allowed memory size of 12582912 bytes exhausted (tried to allocate 42 bytes) in Unknown on line 0

Can the source of that be CHROOT_CAPS or PaX setup?

speaking of PaX only, you can run out of memory only when ASLR (randomization) is in effect and a task wants to use up almost all its address space (3GB on i386). this should be easy to decide, if it's possible to catch the task that's about to run out of memory (i assume after it does it will exit, so it may not be trivial), you should stop it and post the 'cat /proc/<pid>/maps' output here. i would also note that even if this proves to be the case, there's not much we or you can do about it, your task would very likely run out of memory anyway even without ASLR.

[Darkman]

mh, okay, chpax show me:
usr/sbin/httpd: paging based PAGE_EXEC is disabled, trampolines are not emulated, mprotect() is restricted, mmap() base is randomized, ET_EXEC base is not randomized, segmentation based PAGE_EXEC is enabled

so i have mmap randomization enabled which can be the problem, right?

It's correct that the process died if it runs out of memory ;) But not
immedially. I see serval httpd processes running with ~ 99% CPU
time and hanging around befor they die. So i will use such a process
to check the maps. After a while the process will die with a segfault.

thanks for reply

[Darkman]

[quote="PaX Team"]
you should stop it and post the 'cat /proc/<pid>/maps' output here.[/quote]

Okay, here we go, apache/php runs out of mem and thats how maps
look like: http://www.darkman.de/httpd.maps
(to much to post here imho.)

Any Idea?

Greets and thanks

[PaX Team]

Okay, here we go, apache/php runs out of mem and thats how maps look like: http://www.darkman.de/httpd.maps
(to much to post here imho.)

Any Idea?

hmm, what options were enabled for this process? it seems that
mprotect() restrictions were on but randomization was off. in any
case i don't see how PaX could cause an out of memory problem
(there's enough space for sbrk() and mmap() based allocations,
even if randomization was enabled in fact).

[Darkman]

chpax shows:

chpax -v /chroot/webserver/usr/sbin/httpd
/chroot/webserver/usr/sbin/httpd: paging based PAGE_EXEC is disabled, trampolines are not emulated, mprotect() is restricted, mmap() base is not randomized, ET_EXEC base is not randomized, segmentation based PAGE_EXEC is enabled

so mprot is restricted, yes. I dunno if pax or grsec is the problem of the
out of memory, thats just a shot in the blue cause grsec is the only difference
to another maschine where it works. I still can just thank you for your
time + help :)