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. :)

Actually, -D_FORTIFY_SOURCE=3 these days...

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+)

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

I think -Wimplicit-fallthrough should be enabled by -Wall. Right now it's only on with -Wextra. Thoughts?

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."

Here are my notes on how I've been doing "no binary change" analysis of Linux kernel patches that are meant to not change executable output, motivated by our efforts to replace 1-element arrays with proper flexible arrays: https://t.co/UtPcZU9Rn4 tl;dr: diffoscope

Fantastic write-up, confirms the benefits of CFI and auto-var-init: "automatic variable initialization ... kill[s] a whole class of bugs, but it also breaks some useful exploit primitives." "[kernel]CFI is arguably the mitigation that takes the most effort to bypass"

Everyone please go add -ftrivial-auto-var-init=zero to your default build flags. :)

Here's a new API for dealing with bounds-checking flexible array structs in C (i.e. to replace open-coded memcpy(): https://t.co/pmRnYlDKC7 These new helpers got redesigned so many times before I was happy with them. :P

https://t.co/9WdnR1Slab The Linux Security Summit NA 2022 schedule is up! Come join us: Austin, TX, USA June 23/24.

https://t.co/3nbs3rSnrO @fugueish: "A big part of the purpose — or, potential — for public vulnerability announcements and reports is to teach and learn, mature the engineering culture, and above all to avoid repeating these problems" i.e. "actually describe the flaw in detail"

It feels a little bit like archaeology, but here are my notes on security things in Linux v5.10: addfd, SEV-ES, static calls, pRNG improvement, SafeSetID with gid, set_fs removal, sysfs_emit, nosymfollow, MTE, UBSAN-discovered fixes, and flex array work. https://t.co/QvUO5qa3ix

I'm really happy to see kernel IBT support land. Coarse-grained forward edge CFI! (Supported on Tigerlake and later Intel systems, and Zen3 and later AMD systems.) https://t.co/PLYrSIaoUZ

Based on the excellent by worLdle, I have replaced the country data with US states, and present: statele https://t.co/zFp3rWMGCF