9 ms·
CVE-2022-0435: A Remote Stack Overflow in the Linux Kernel
- mewmellow_cat 5y ago
- dboreham 5y agoDude. Over-share.
- NullPrefix 5y agoSharing is caring
- j_walter 5y agoOversharing is not...
- tragictrash 5y agoThis made my day
- dboreham 5y agoSurprised and slightly worried that there has been a whole protocol out there since 1996 that I never heard of until now.
- imrejonk 5y agoIt does not appear to be enabled in the kernel by default: > While the module can be found in most major distributions, it must be loaded in order to be exploited.
- userbinator 5y agoThis seems to be one of those specialized things that the vast majority of users don't need, so I'm not surprised by its existence. What I am more concerned about is why its presence (albeit disabled) is so widespread.
- jeroenhd 5y agoPosted yesterday, but with no comments: https://news.ycombinator.com/item?id=30291958 https://news.ycombinator.com/item?id=30291958 A bug of similar severity was fixed a few months ago: https://news.ycombinator.com/item?id=29117815 https://news.ycombinator.com/item?id=29117815 Luckily, it looks like most distros don't load this module by default.
- a-dub 5y agoi was scratching my head thinking "wasn't there another security bug in this thing recently?" thanks for posting this.
- trasz 5y agoYay, yet another vulnerability that wouldn't happen if running on CHERI/Morello hardware.
- stonogo 5y agoOr just enabling the default kernel hardening flags. But sure, let's dunk on people for not running hardware that has been in developer-only release for less than a month.
- pjmlp 5y agoI agree with the kernel hardening flags, unfortunately it seems Android (not being a proper GNU/Linux) is the one doing the best at kernel hardening out of the box.
- stargrazer 5y agoFor the record, would you mind supplying a reference to those flags?
- stonogo 5y agoThe relevant flag is listed in the CVE report this whole discussion is about. CONFIG_FORTIFY_SRC=y turns the stack overflow into a panic, preventing the out-of-bounds write attack. You're probably just better off not loading the TIPC module, though, so that you don't have a crash condition either.
- tragictrash 5y agoI don't think this should be a surprise for anyone at this point. All of our systems have critical vulnerabilities that haven't been discovered yet. Welcome to 2022. If you think quantum breaking cryptography is bad, wait until they figure out how to use it for fuzzing.
- orblivion 5y agoActually wouldn't that be good? Assuming the good guys have access to quantum computers.
- sidkshatriya 5y agoEven if both good and bad guys would have access to quantum computers there would still be an asymmetry: The good guys would still need to find and patch everything all the time without fail. The bad guys would just need their quantum computer to find a single flaw that had not been found and/or patched by the good guys yet.
- littlestymaar 5y agoThe thing is: there will also be an asymmetry regarding who can afford a quantum computer that actually serves a purpose, at least for the first decade.
- orblivion 5y agoOkay, so you're expecting new fuzzing techniques to be found all the time, or perhaps that fuzzing may be a long term process. 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).
- fulafel 5y agoOr: Every year this is realization hits a new cohort of people, as it has for decades.
- 5y ago
- notyourday 5y agoWhy are you running sexy protocols when non-sexy protocols do the job?
- fulafel 5y agoAny ideas why this service is in the kernel? https://www.kernel.org/doc/html/latest/networking/tipc.html https://www.kernel.org/doc/html/latest/networking/tipc.html doesn't seem to give provide the motivation.
- snvzz 5y agoBad architecture. Refer to seL4 for a less broken one.
- LinuxBender 5y agoTIPC is one of the many modules that are suggested to be disabled in CIS and NIST hardening documentation unless you have an explicit requirement for it. [1] And here [2] is a previous discussion from 2017 discussing disabling kernel modules. As imrejonk mentioned this is not loaded by default. One can check the loaded modules with lsmod The module can be explicitly disabled with # cat /etc/modprobe.d/tipc.conf install tipc /bin/false There are documents explaining the pros and cons to using /bin/false vs /bin/true for disabling modules. [1] - https://downloads.cisecurity.org/#/ https://downloads.cisecurity.org/#/ [2] - https://news.ycombinator.com/item?id=13709591 https://news.ycombinator.com/item?id=13709591
- mindcrime 5y agoHuh. I'd never heard of TIPC before now either, but this actually sounds pretty interesting now that I'm reading about it. Shame that this was my first introduction to it (and from reading these threads, it seems like I'm not the only one). https://en.wikipedia.org/wiki/Transparent_Inter-process_Communication https://en.wikipedia.org/wiki/Transparent_Inter-process_Comm...
- paulmd 5y agoQuick reminder that KASLR is broken by "metadata leakage" (the metadata is the page table mappings) on AMD processors by default unless you manually enable KPTI. 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://mlq.me/download/amdprefetch.pdf https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1017 https://www.amd.com/en/corporate/product-security/bulletin/a...
- bravetraveler 5y agoForgive me, I'm new to this - but wouldn't the mitigation status also depend on the distribution? 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 I ask and remain somewhat curious partly because I don't see the messages in the ring buffer I'd expect (based on some cursory research)
- 5y ago
- userbinator 5y agoThe vulnerability has been present since the introduction of the TIPC monitoring framework in kernel version 4.8. 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.