[grsec] GRKERNSEC_BRUTE and ret2libc
spender at grsecurity.net
Sun Oct 11 17:49:17 EDT 2009
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : http://grsecurity.net/pipermail/grsecurity/attachments/20091011/7cc90883/attachment.pgp
More information about the grsecurity