grsecurity forums

I've been using the grsecurity patch for 2.4.32 just fine lately and haven't noticed any problems, in fact I decided to run the paxtest to see how well it was configured and was pleased with the results. Aside from the return to strcpy/memcpy vulnerablities, which could of course be eleviated using propolice, I did some research online and saw that K6/2's compiled with PAGEEXEC will not work, however in my logs from paxtest it shows
Stack randomisation test (PAGEEXEC) : 24 bits (guessed)
so my question is, has this issue been resolved in prior patches or am I to expect it breaking somethings/not really randomizing? Or has this indeed been fixed and will work on the k6/2? Thanks in advanced, I appreciate it

ralphy wrote:Stack randomisation test (PAGEEXEC) : 24 bits (guessed)
so my question is, has this issue been resolved in prior patches or am I to expect it breaking somethings/not really randomizing? Or has this indeed been fixed and will work on the k6/2? Thanks in advanced, I appreciate it

the randomization tests are split because the userland address space size is different between SEGMEXEC/PAGEEXEC which in turn affects the amount of randomization (SEGMEXEC is one bit less in general). so PAGEEXEC still doesn't support the K6 (you can force it but it will hang on /sbin/init in an infinite page fault loop .

so it appears paxtest gave false positives? or is

Stack randomisation test (SEGMEXEC) : 23 bits (guessed)
Stack randomisation test (PAGEEXEC) : 24 bits (guessed)

still sufficient? im extremely worried about incoming attacks including ret2libc type attacks , i realize an entire stack thats randomized won't circumvent this completely but i'd rather have my computer's stack randomized the best it can instead of not being randomized at all. what i don't understand is if i have it enabled then why hasn't my init continously looped yet???

ralphy wrote:so it appears paxtest gave false positives? or is

Stack randomisation test (SEGMEXEC) : 23 bits (guessed)
Stack randomisation test (PAGEEXEC) : 24 bits (guessed)

still sufficient? im extremely worried about incoming attacks including ret2libc type attacks , i realize an entire stack thats randomized won't circumvent this completely but i'd rather have my computer's stack randomized the best it can instead of not being randomized at all. what i don't understand is if i have it enabled then why hasn't my init continously looped yet???

You're right that some randomness is better than none, but remember that randomness only helps you against one class of attacks. It doesn't help against program errors which permit an attacker to receive a service that he wouldn't normally be allowed, such as if I asked your server to send me /etc/passwd and it agreed to do so because I formed the request in such a way that its access checks didn't recognize that I was asking for a prohibited file. For example, I could request "/etc/passwd\0foo", which is not equal to "/etc/passwd" when all characters are considered. However, when the request is passed to the kernel, the kernel will stop at the first null, giving it "/etc/passwd" as the file requested. In such a case, the attack would be based on bad logic in the server, but wouldn't require me to know where any particular piece of code is in the server's memory (and thus randomization wouldn't stop it).

If you're exposing services to potentially malicious users, I'd strongly suggest you use GRsecurity's RBAC system to restrict those services. It's still theoretically possible that there's a way around RBAC, but then the attacker would need to find a request that satisfies both the checks your service imposes and satisfy RBAC's checks. As an added bonus, even if the attacker performs a buffer overflow attack (e.g. ret2libc), his code is still subject to the checks of RBAC, since that's on the kernel side and can't be bypassed no matter where he jumps in userland.

ah yes thats true too, i noticed during my tests that ret2libc was killed automatically so that helps me some. i use some restrictive rules for rbac just in case a service is known to have problems paranoia takes the better of me

ralphy wrote:what i don't understand is if i have it enabled then why hasn't my init continously looped yet???

if you enable both SEGMEXEC and PAGEEXEC in the kernel then SEGMEXEC will be used by default (on 2.6 you can even change the default in the .config).