CVE-2022-0435: A Remote Stack Overflow in the Linux Kernel
openwall.com
openwall.com
This was discovered by the same team that discovered Spectre and Meltdown and the official AMD stance is WONTFIX because it can be mitigated by enabling KPTI, however they also refuse to state that KPTI should be enabled by default on their processors because that would tank their benchmarks.
They don't put it in quite those exact words in the bulletin, but the "user and kernel address space boundary" they are referring to that the exploit cannot cross is KPTI. Turn it on and it's mitigated, if it's off kernel pages and user pages live in the same tables and are thus vulnerable. However AMD's official stance is KPTI off-by-default, so generally they are still vulnerable unless you manually enable KPTI.
(their ass is covered by the "obey good security practices", i.e. if you actually care you should be turning it on because it's a good security practice in general, but it would nuke their benchmarks just like it did to Intel, so they want it off by default since that's how things are usually benchmarked.)
The paper describes several approaches, some of which can be mitigated (the time and power measurement attacks) and some of which cannot except via KPTI (TLB-Evict+Prefetch). The issue is, broadly speaking, unfixed. And actually I think at this point it's past metadata leakage and actually just leaking data considering Lipp has extracted actual memory from the kernel.
https://mlq.me/download/amdprefetch.pdf
https://www.amd.com/en/corporate/product-security/bulletin/a...
It doesn't paint AMD in any better of a light, but it may not be so dire.
The distributions at the top don't usually run a mainstream [vanilla] kernel. Consequently, neither do their children/derivatives.
For example, the kernel configs for my distribution (Fedora 35) show it as enabled - unless I'm missing some further step:
$ zgrep CONFIG_PAGE_TABLE_ISO /boot/config-`uname -r`
CONFIG_PAGE_TABLE_ISOLATION=y
(based on some cursory research)
There's a bit of hand waving around this it seems lol
I have a modern/current kernel (4.x is ancient) built with the option enabled, my command line lacks nopti, yet I do not see the protection message. That's the root of my confusion.
When I get back to my machine I'll check the sysfs file
https://www.phoronix.com/scan.php?page=article&item=if-amd-k...
Some googling suggests that flag is whether the kernel is compiled with support, not whether it's turned on. You'd need to force boot flag "pti=on" for an AMD system. Postmark or a database benchmark would be a good bench for you to compare, probably.
(apparently "kpti=on" is aarch64-specific, other uarchs use "pti" instead, seems kind of odd)
From the page you link: CONFIG_PAGE_TABLE_ISOLATION=y in the kernel configuration. This only indicates that the kernel is capable of kernel page-table isolation. KPTI can be disabled at boot time from the kernel command line through the nopti or pti=off options. On some systems, it can be disabled at runtime by writing 0 to /sys/kernel/debug/x86/pti_enabled.
Does AMD dictate if this nopti or pti=off is set in the _kernel_ commandline? (curiosity - pls don't kill me :cat-emote:)
https://www.phoronix.com/scan.php?page=article&item=if-amd-k...
Now - the problem is there's obviously a lot of self-interest here, because the KPTI mitigation is pretty performance-intensive. You have to basically flush the TLB every time you do a syscall, and that hurts server pretty heavily in particular. AMD is making a big push into server with Epyc - it's really the entire focus of the Zen/Ryzen design, consumer CPUs are a convenient synergy. The performance hit is around 10% in most cases, 20-30% in some more IO-intensive situations (database loads, etc). Obviously they would rather not have that turned on, but what they're low-key saying in their bulletin is that not turning it on (no user-kernel cache boundary) leaks memory.
They're being coy and downplaying it, so they're saying the inverse "the exploit doesn't work if you turn on KPTI", rather than outright confirming "it does work if you don't enable KPTI", and they refuse to say KPTI by name, but that's what's going on there. The exploit author stated outright that KPTI mitigated the problem and should probably be enabled by default, but AMD is conveniently leaving off the second half of that sentence. Systems are routinely benchmarked in a default/manufacturer-recommended configuration, if they had to turn on KPTI by default it would significantly hurt their server benchmarks, at a time when the company is making an enormous push for server.
It's much better for them to have their processors benched in an insecure-by-default configuration while forcing Intel to constantly flush their caches, and that's what I see going on there. But people are generally very generous with giving AMD the benefit of the doubt, and truth be told the chances of it actually being exploited in practice are slim anyway (just like Intel), so it's likely a bet that will work out for AMD. And even if someone did get hacked - they did the CYA "if you care you should probably enable it" in their various security bulletins, so sucks to be you, even if their default was unsafe.
Even ignoring whether or not it leaks actual memory - the exploit author says it does, AMD doesn't explicitly confirm or deny either way - KASLR has been broken for some time on AMD processors unless you manually enable KPTI. And that makes chaining attacks much easier, because now you don't have to guess where to point your Specter exploit (or in this case - a stack overflow), the chip will just tell you.
One can check the loaded modules with
lsmod
# cat /etc/modprobe.d/tipc.conf
install tipc /bin/false
https://en.wikipedia.org/wiki/Transparent_Inter-process_Comm...
A bug of similar severity was fixed a few months ago: https://news.ycombinator.com/item?id=29117815
Luckily, it looks like most distros don't load this module by default.
thanks for posting this.
I guess this is another one of those times when newer isn't always better... especially when it comes with extra stuff you never needed anyway. At least this one doesn't seem to be enabled by default.
> While the module can be found in most major distributions, it must be loaded in order to be exploited.
If you think quantum breaking cryptography is bad, wait until they figure out how to use it for fuzzing.
I was sort of assuming that you'd have a super fuzzer that you can throw at every piece of software that comes out, so it's fixed before it gets released. (Obviously the interim would be real bumpy given existing software).
edit: OK I thought a bit more. Maybe if QC would improve concolic execution, but I haven't heard that that would be the case - that there are algorithms used for symbolic execution that would benefit from a QC.