Notices by Kees Cook :tux: (kees@fosstodon.org), page 2

@hawkes "build systems are a perfect mix of inscrutability and expressiveness" 💯

@AkaSci

@vegard @corbet @kernellogger @gregkh i.e. LTS are supported for 4 years now, not 2.

@LinuxSecSummit The video for my presentation is up: https://youtu.be/PLcZkgHCk90
Enjoy! 😊

Ubuntu and Android have had CONFIG_UBSAN_BOUNDS for a while now. At my urging, Fedora has just enabled it recently, and now I've opened a PR for Debian:
https://salsa.debian.org/kernel-team/linux/-/merge_requests/1065

I gave my talk at the @LinuxSecSummit ! I'll link to the video once it's posted.

Mitigating Integer Overflow in C
(or "How I learned to love the sanitizer")

Slides:
https://outflux.net/slides/2024/lss-na/

Summary:
https://lssna24.sched.com/event/1aIe9?iframe=no

I probably should have opened this bug a while ago, asking Fedora to turn on CONFIG_UBSAN_BOUNDS. Ubuntu (and Debian, I think) has had it a while...

https://bugzilla.redhat.com/show_bug.cgi?id=2275162

I've seen many Linux offensive security presentations and research include caveats like, "first turn off ASLR", or other stuff where the written exploit doesn't actually work with modern default systems. Here the excellent article includes details on _enabling_ additional non-default defenses. 😍

Man Yue Mo: Gaining kernel code execution on an MTE-enabled Pixel 8
https://github.blog/2024-03-18-gaining-kernel-code-execution-on-an-mte-enabled-pixel-8/

@vegard @kurtseifried @vathpela @gregkh That is exactly right!

I remain impressed that the Ubuntu security team (and kernel team) do severity analysis (with respect to the distro), and usually flaw introduction commit analysis, for each kernel CVE. It's already lot of work, so I'm curious how they will adapt to the higher rate of CVE assignments now.

@vathpela @vegard @gregkh
The corollary of "security bugs are bugs" is "bugs are security bugs". Without an omniscient view of all Linux deployments and the associated reachability analysis, the objective security impact of a behavioral weakness cannot be assessed. And this is especially true given that (even minor) flaws are commonly chained together to build exploits.

This new process won't be perfect, but it'll be a whole lot closer to reality than the prior process: assigning no CVEs. :)

@vegard @vathpela @gregkh FWIW, I think "security bugs are bugs" is a flawed view. The nuance, though, can be extremely time consuming. :(

Ugh. Everyone building with CONFIG_XEN_PV=y has always had a trivial local KASLR exposure via /sys/kernel/notes

https://lore.kernel.org/linux-hardening/202402180028.6DB512C50@keescook/

Also, I had to write my own .notes parser. Is there already one somewhere? It's a simple format, but still.
https://docs.oracle.com/cd/E23824_01/html/819-0690/chapter6-18048.html

v6.5 fixed almost twice as many "high" CVEs (19) than the second most prolific release, v6.6 (11), with v6.4 tied for 3rd place (9) with v5.17. It seems like the rate of fixing is picking up.

Ignoring the first git release (v2.6.12), the "high" flaw counts are relatively even. The most flawed (i.e. most well tested/researched) releases have been v3.8 (9), v3.18 & v2.6.20 tied (8), and v5.9 & v4.1 tied (6).

But there are certainly more flaws in all releases -- they just haven't been found yet.

Last time I did a Linux kernel security flaw lifetime analysis was back in 2021. It showed the average time between flaw introduction and fix was 5.5 years for 108 "high priority" CVEs:
https://outflux.net/slides/2021/lss/kspp.pdf

I refreshed my dataset today and was surprised to see that now with 103 more CVEs, it's still holding at 5.5 years. This actually means Linux is getting faster at finding issues, but the (diminishing) technical debt of the past is still dragging down the average.

I think 13 years is enough time to migrate to CAP_SYSLOG
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=for-next/hardening&id=09ce61e27db83180993e8b1a7f511af62374383c

Happy md data-check first Sunday to all who celebrate

After 4 years the strlcpy() API has been fully removed from the Linux kernel. Long live strscpy().
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d26270061ae66b915138af7cd73ca6f8b85e6b44

Next up, strncpy()!
https://github.com/KSPP/linux/issues/90

Sequentially in my feed: a toot about the Mars helicopter Ingenuity and its continued flying around, followed by a toot about Linux 4.14 reaching EOL.

Which reminds me, Ingenuity is running a 3.6 kernel. And it has the only excuse I can tolerate for having not been upgraded: it's on a different planet. ;)

@amuse The Expanse! Either the shows or the books. :)

Linux Plumbers Conf discussion on using pstore for kernel crash collection, as used by the #SteamDeck

"When kdump is way too much"
Guilherme Piccoli
https://www.youtube.com/live/68EBBgEltXA?t=24102