@solardiz "32-bit" ASLR is at best 20-bit and actually more like 16-bit. Trivial to brute-force, e.g. in suids.
-
-
Replying to @RichFelker
@RichFelker Sure, but for remote attacks and eventual lockout (which we need upstreamed in the kernel), "32-bit" ASLR is better than nothing2 replies 0 retweets 0 likes -
Replying to @solardiz
@solardiz@RichFelker Remote attacks can often be retried over and over again thanks to service respawning, even if it's throttled.1 reply 0 retweets 0 likes -
Replying to @CopperheadOS
@CopperheadSec@solardiz And it's not clear to me that everyone would want to trade this for a lock-out type behavior.1 reply 0 retweets 0 likes -
Replying to @RichFelker
@CopperheadSec@solardiz Lockout after several crashes transforms momentary-DoS-only bugs into effective long-term DoS attacks.1 reply 0 retweets 2 likes -
Replying to @RichFelker
@RichFelker@solardiz Yeah, and respawning tends to be the default or at least strongly encouraged by service supervisors.2 replies 0 retweets 0 likes -
Replying to @CopperheadOS
@CopperheadSec@RichFelker OTOH, it's surprising that Red Hat sets kernel.panic_on_oops by default, favoring integrity over availability1 reply 0 retweets 1 like -
Replying to @solardiz
@solardiz@RichFelker FWIW, Android sets kernel.panic_on_oops too. There's little choice without PaX since there's no anti-brute-force.1 reply 0 retweets 0 likes -
Replying to @CopperheadOS
@solardiz@RichFelker Since the choice is between allowing any number of crashes with no throttling or panicking after the first one.1 reply 0 retweets 1 like -
Replying to @CopperheadOS
@CopperheadSec@solardiz Well when the crash is in kernel space it rather makes sense to treat the whole kernel as compromised and panic.2 replies 0 retweets 1 like
@CopperheadSec @solardiz I think panic_on_oops is a very different issue from locking out crashing user processes.
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.