Today's the 7th anniversary of founding the Kernel Self-Protection Project!
https://t.co/dX7pRTAAkq
We've come a long way, but there's still lots more work to do. :)
@trufae This is a problem in the kernel where we intentionally replace some globals, so I'm hoping to use -Wshadow=local instead:
https://t.co/quqt9viIkS
If you can't switch your C to Rust immediately, consider at least enabling all the sanity checking the compiler can already do for free:
-Wall
-D_FORTIFY_SOURCE=2
-fsanitize=bounds fsanitize-undefined-trap-on-error
-fstrict-flex-arrays (GCC 13+, Clang 16+)
@Khajiit_san glibc headers/runtime supports 1-3.
Bionic supports 1-2.
musl doesn't support it at all, and the separate fortify-aware headers (for 1-2) don't come with a runtime.
So, yeah, =3 is glibc only currently.
@zgrlin -fsanitize=address is ASAN (and is great) but usually considered too heavy for production code.
-fsanitize=bounds has trivial overhead, though. Compiler can, you know, check the bounds:
"Am I about to use an index outside the size of the array I know the length of? Maybe don't!"
@_trou_@BincatLady Cool! You remind me I've had buffer overflows on my mind too much recently: there's so much more to enable for other security bug classes, too:
-fstack-protector-strong
-Wvla
-Wimplicit-fallthrough
-ftrivial-auto-var-init=zero
All of these should be default on in distros! :|
@lafp I thought that part of -Wall?
I ran out of characters on the first tweet, but if not -Wall, then yes, these:
-Warray-bounds
-Wstringop-overflow
-Wstringop-overread
-Wstringop-truncation
@signalapp This is extremely disappointing. SMS integration is what set Signal apart from the fragmented ecosystem of other messaging apps. It's what made it easy for less technical friends & family to switch to and stay with Signal.
I've started trying to document the various things I've learned about using Coccinelle to match code patterns in the Linux kernel here:
https://t.co/bjL82rlkWF
It's hardly complete, but I wanted to start keeping notes somewhere I could find later. :)
On Linux there's at least 2 ways to mitigate these kinds of attacks:
- easy: seccomp filter of "exec" system call
- better: MAC (e.g. AppArmor, SELinux, etc) to block both "exec" and limit unexpected path traversals and file accesses
I looked through these RCEs: they appear to all be command injection. (Though the MS issues don't have much detail.) Notably, there aren't any memory safety issues. But this is also more about web/net services, and command injection is the low hanging fruit in that environment.
Thank you @samitolvanen, Peter, Joao, @nullmodem, @embeddedgus, @nathanchance, Nick, Sedat, Josh, and everyone else who helped get KCFI developed and landed!
https://t.co/7OEXa1fKfm
@palefist The first half of the memcpy story is detailed here:
https://t.co/rtWl5MCGd1
tl;dr: identify a very common type of buffer overflow so they can be stopped
We've finally landed the run-time memcpy() overflow warning patch in linux-next:
https://t.co/t2WxxcO78S
So now I'm constantly reloading a search on lore, checking if anyone has run into new instances on real work loads. :P
https://t.co/11Cz5eY7t2
So many interesting finds in this research! I struggle to fit even one in a tweet:
"... while we may not be decreasing the # of vulns... there are indications [of] ... a notion of maturity, where vulns will be mostly absent from code older than a specific point in the past."
How Long Do Vulnerabilities Live in the Code? A Large-Scale Empirical Measurement Study on FOSS Vulnerability Lifetimes | USENIX https://t.co/12jbgrP4Ot