| 1 |
On 20 Mar 2013 at 10:11, Alex Efros wrote: |
| 2 |
|
| 3 |
> Hi! |
| 4 |
> |
| 5 |
> On Wed, Mar 20, 2013 at 09:25:07AM +0200, Alex Efros wrote: |
| 6 |
> > https://bugs.gentoo.org/show_bug.cgi?id=462430 |
| 7 |
|
| 8 |
next time add me to the bug if you expect an answer instead of spamming |
| 9 |
every possible forum. |
| 10 |
|
| 11 |
> > Any ideas which grsec/pax option may result in this (subj) behavior? |
| 12 |
> |
| 13 |
> Looks like PAX_RANDMMAP is broken (or improved too much). |
| 14 |
|
| 15 |
from the 3.7.4 changelog: |
| 16 |
|
| 17 |
- added countermeasure against attacks that reduce ASLR by exhausting the address space on 32 bit userland |
| 18 |
see kingcope's post for the windows version |
| 19 |
http://kingcope.wordpress.com/2013/01/24/attacking-the-windows-78-address-space-randomization/ |
| 20 |
|
| 21 |
> If trivial tools like tcpserver on 32-bit system instead of 2MB will |
| 22 |
> randomly use up to 300MB just as result of RANDMMAP - this isn't good. |
| 23 |
> Even if it doesn't really allocate all these memory it still break |
| 24 |
> things like ulimit/softlimit. |
| 25 |
|
| 26 |
these artificial random gaps don't actually consume RAM, only virtual address |
| 27 |
space and applications trying to account for their address space needs while |
| 28 |
also second guessing the kernel are simply buggy. |
| 29 |
|
| 30 |
nevertheless to reduce the pain i've fixed the gap accounting in that these |
| 31 |
areas are not taken into account when mmap checks RLIMIT_AS, so it should |
| 32 |
be fine now (did you even search the gentoo bugzilla or the grsec forums for |
| 33 |
similar issues? i thought so). you'll need to update to 3.8.3 though because |
| 34 |
3.7 is no longer supported. |
Archives