Mailing List Archive

Hi!

On Wed, Mar 20, 2013 at 09:25:07AM +0200, Alex Efros wrote:
> https://bugs.gentoo.org/show_bug.cgi?id=462430
>
> Any ideas which grsec/pax option may result in this (subj) behavior?

Looks like PAX_RANDMMAP is broken (or improved too much). If trivial tools
like tcpserver on 32-bit system instead of 2MB will randomly use up to
300MB just as result of RANDMMAP - this isn't good. Even if it doesn't
really allocate all these memory it still break things like ulimit/softlimit.

Also it looks like on 64-bit system it use up to 60MB instead of 4MB for
tcpserver. Maybe there is typo in some constant in PaX code and because of
this it allocate up to 300MB instead of, say, up to 32MB?

--
WBR, Alex.

On 20 Mar 2013 at 10:11, Alex Efros wrote:

> Hi!
>
> On Wed, Mar 20, 2013 at 09:25:07AM +0200, Alex Efros wrote:
> > https://bugs.gentoo.org/show_bug.cgi?id=462430

next time add me to the bug if you expect an answer instead of spamming
every possible forum.

> > Any ideas which grsec/pax option may result in this (subj) behavior?
>
> Looks like PAX_RANDMMAP is broken (or improved too much).

from the 3.7.4 changelog:

- added countermeasure against attacks that reduce ASLR by exhausting the address space on 32 bit userland
see kingcope's post for the windows version
http://kingcope.wordpress.com/2013/01/24/attacking-the-windows-78-address-space-randomization/

> If trivial tools like tcpserver on 32-bit system instead of 2MB will
> randomly use up to 300MB just as result of RANDMMAP - this isn't good.
> Even if it doesn't really allocate all these memory it still break
> things like ulimit/softlimit.

these artificial random gaps don't actually consume RAM, only virtual address
space and applications trying to account for their address space needs while
also second guessing the kernel are simply buggy.

nevertheless to reduce the pain i've fixed the gap accounting in that these
areas are not taken into account when mmap checks RLIMIT_AS, so it should
be fine now (did you even search the gentoo bugzilla or the grsec forums for
similar issues? i thought so). you'll need to update to 3.8.3 though because
3.7 is no longer supported.

Hi!

On Wed, Mar 20, 2013 at 10:15:16AM +0100, PaX Team wrote:
> > > https://bugs.gentoo.org/show_bug.cgi?id=462430
>
> next time add me to the bug if you expect an answer instead of spamming
> every possible forum.

Ok.

> nevertheless to reduce the pain i've fixed the gap accounting in that these
> areas are not taken into account when mmap checks RLIMIT_AS, so it should
> be fine now (did you even search the gentoo bugzilla or the grsec forums for
> similar issues? i thought so). you'll need to update to 3.8.3 though because
> 3.7 is no longer supported.

I've searched gentoo bugzilla, but not grsec forums (when I report this
issue I wasn't sure it's related to hardened).

Anyway, I've tried 3.8.3, and see no difference at all on 32-bit system:

# uname -a
Linux web 3.8.3-hardened #1 SMP Wed Mar 20 15:45:48 GMT 2013 i686 Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz GenuineIntel GNU/Linux
# softlimit -m 32000000 tcpserver 0.0.0.0 11111 echo ok
Killed
kern.alert: grsec: From 127.0.0.1: denied resource overstep by requesting 189251584 for RLIMIT_AS against limit 32000000 for /usr/bin/tcpserver[tcpserver:1821] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:1307] uid/euid:0/0 gid/egid:0/0

At same time, on 3.8.3 64-bit system tcpserver works ok under much lower
softlimit -m 5000000 (5MB!) without any grsec errors in log (`ps axu`
still show tcpserver uses up to 60MB VSZ).

--
WBR, Alex.

On 20 Mar 2013 at 17:59, Alex Efros wrote:

> Anyway, I've tried 3.8.3, and see no difference at all on 32-bit system:

which grsec is that? the last bits of the fix went in like 2 days ago only,
i think gentoo's ebuild uses an older patch than that. best would be if you
tested the latest grsec yourself.

Hi!

On Wed, Mar 20, 2013 at 05:24:09PM +0100, PaX Team wrote:
> > Anyway, I've tried 3.8.3, and see no difference at all on 32-bit system:
>
> which grsec is that? the last bits of the fix went in like 2 days ago only,
> i think gentoo's ebuild uses an older patch than that. best would be if you
> tested the latest grsec yourself.

It's 4420_grsecurity-2.9.1-3.8.3-201303142235.patch.
I've updated it to 201303191956 and testing now…

On 64-bit system tcpserver still uses up to 60MB, but 5MB softlimit for
tcpserver doesn't work anymore, now it require 64MB softlimit (which makes
more sense).
On 32-bit system nothing changed, tcpserver still uses 60-300MB and
require about 300MB softlimit to run.

--
WBR, Alex.