Kees Cook

Today's the 7th anniversary of founding the Kernel Self-Protection Project! @mail.gmail.com/" target="_blank" rel="nofollow noopener">lore.kernel.org/kernel-hardeni… 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: github.com/KSPP/linux/iss…

@kees_cook -Wshadow

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

@Lahvuun I'm recommending "bounds" not "address" and if you use trap mode, it doesn't need the library.

@kees_cook I'm not sure about using -fsanitize. In my case with -fsanitize=address,undefined it linked to libasan, which broke my program for one of the users once their Linux distribution updated the library. I feel like this option should only be used for debug builds.

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

@Khajiit_san FORTIFY is a weird one: it's a combination of compiler builtins, libc headers, and libc runtime features. =1 uses __builtin_object_size(p, 0) =2 uses __builtin_object_size(p, 1) =3 uses __builtin_dynamic_object_size(p, 1) ...

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

In the interest of privacy, security, and clarity we’re beginning to phase out SMS support from the Android app. You’ll have several months to export your messages and either find a new app for SMS or tell your friends to download Signal.  signal.org/blog/sms-remov…

I've started trying to document the various things I've learned about using Coccinelle to match code patterns in the Linux kernel here: github.com/kees/kernel-to… 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! git.kernel.org/linus/865dad20…

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

@palefist The first half of the memcpy story is detailed here: git.kernel.org/linus/f68f2ff9… tl;dr: identify a very common type of buffer overflow so they can be stopped

@kees_cook yes! finally a tweet i can pretend to understand.

We've finally landed the run-time memcpy() overflow warning patch in linux-next: git.kernel.org/pub/scm/linux/… So now I'm constantly reloading a search on lore, checking if anyone has run into new instances on real work loads. :P lore.kernel.org/all/?q=%22dete…

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