Recent informative ML thread: List of security features in musl. http://www.openwall.com/lists/musl/2016/02/11/4 …
-
-
Replying to @musllibc
@musllibc@RichFelker Protecting the setjmp registers and internal function pointers (vdso, atexit, atfork) is one of the missing pieces.1 reply 0 retweets 0 likes -
Replying to @CopperheadOS
@musllibc@RichFelker Could extend RELRO or use a page-aligned/padded global data structure for vdso function pointers, etc. like Bionic.1 reply 0 retweets 0 likes -
Replying to @CopperheadOS
@musllibc@RichFelker Bionic and glibc use the XOR mitigation for setjmp. Bionic does it for all of the registers. Not sure about glibc.1 reply 0 retweets 0 likes -
Replying to @CopperheadOS
@musllibc@RichFelker Then there's a choice between OpenBSD-style memory protection and/or glibc-style XOR for atexit, pthread_atfork, etc.2 replies 0 retweets 1 like -
Replying to @CopperheadOS
@CopperheadSec For hardening that induces impl complexity I first want to see evidence that there are realworld vulns it would avert.1 reply 0 retweets 0 likes -
Replying to @RichFelker
@CopperheadSec Have there actually been a significant number of jmp_buf based exploits? I don't know. Does anyone?1 reply 0 retweets 0 likes -
Replying to @RichFelker
@RichFelker It doesn't prevent vulnerabilities. It prevents control flow hijacking via those function pointers as part of exploitation.2 replies 0 retweets 0 likes
@CopperheadSec Yes. But what I'm asking is whether vulnerable jmp_buf's are sufficiently common to be worthwhile to harden.
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.