Does the RLIMIT_STACK bug you're hinting at has any real-life relevance for @grsecurity kernels?
-
-
Replying to @_minipli
I didn't try, but it should make Stack Clash easier to hit on old grsecurity since the memory layout becomes controllable again
2 replies 0 retweets 0 likes -
Replying to @kees_cook
Actually, what memory layout becomes controllable again?
1 reply 0 retweets 0 likes -
Replying to @_minipli
legacy bottom-up vs regular top-down mmap layout, see IV.1.1, IV.1.4, IV.1.5. IV.1.6 misses this, so the analysis is incomplete.
1 reply 0 retweets 0 likes -
Replying to @kees_cook
Well, IV.1.1-5 of the Qualys analysis covers the behaviour of *vanilla* Linux, not grsec. Don't mix that up!
1 reply 1 retweet 0 likes -
Replying to @_minipli @kees_cook
All of the described attacks require passing large argv[] + envp[] to the SUID binary. However, grsec limits them to 512kB.
1 reply 0 retweets 0 likes -
Replying to @_minipli @kees_cook
For the sudo vulnerability (allowing to work-around even this restriction) the advisory states an "exploitation [is] impossible".
1 reply 0 retweets 0 likes -
Replying to @_minipli @kees_cook
So even without the 8 MB RLIMIT_STACK restriction in place, grsec has other mechanisms making 'Stack Clash' kind of attacks infeasible:pic.twitter.com/GZA1uDElZI
1 reply 1 retweet 0 likes -
Replying to @_minipli
my point was grsec's "8MB setuid stack limit" didn't work as intended; upstreaming those kinds of ideas requires time/effort.
1 reply 0 retweets 0 likes -
Replying to @kees_cook
Indeed it does! However, in grsec's case it doesn't/didn't matter much as other mechanisms ensure "defense in depth" still stands.
1 reply 1 retweet 1 like
Yup, agreed. That's why I worked on getting it upstreamed (along with other accounting fixes/limits). Defense in depth FTW!
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.