[grsec] GRKERNSEC_BRUTE and ret2libc

[Brad Spengler]

On Sun, Oct 11, 2009 at 03:26:15PM +0800, Pavel Labushev wrote:
> I was thinking of GRKERNSEC_BRUTE... gr_handle_brute_attach() is called
> only when a child fails with SIGKILL or SIGILL, but not with SIGSEGV.
> Why is that? I mean, segmentation failure may happen because of some
> ret2libc-style exploit failed, so it seems like a good idea to call
> gr_handle_brute_attach() when SIGSEGV occurs. But I'm sure there's a
> reason why that's not implemented already. Can anybody explain, why? Brad?

The reason SIGSEGV isn't added to that particular option (though it is 
added along with SIGBUS to the RES_CRASH functionality of the RBAC 
system, as that's a more general "crash" detector) is for compatibility 
reasons.  For the bruteforce logic, I chose to stick with signals that 
generally don't occur normally and are generally good predictors of 
exploit activity.  Specifically, what I didn't want was a SIGSEGV in 
some shared forking daemon caused by a single user's buggy script to 
affect availability for the rest of users by triggering the bruteforce 
logic.  IIRC I had a specific experience with apache which caused me to 
implement it in this way.

Of course, if everything you (and the users of your machine) execute 
within the context of forking daemons is bug-free, you can of course add 
SIGSEGV to the list if you wish, or use RES_CRASH from the RBAC system.

-Brad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://grsecurity.net/pipermail/grsecurity/attachments/20091011/7cc90883/attachment.pgp