Quick 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.<p>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.<p>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.<p>(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.)<p>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.<p><a href="https://mlq.me/download/amdprefetch.pdf" rel="nofollow">https://mlq.me/download/amdprefetch.pdf</a><p><a href="https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1017" rel="nofollow">https://www.amd.com/en/corporate/product-security/bulletin/a...</a>
TIPC 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.<p>One can check the loaded modules with<p><pre><code> lsmod
</code></pre>
The module can be explicitly disabled with<p><pre><code> # cat /etc/modprobe.d/tipc.conf
install tipc /bin/false
</code></pre>
There are documents explaining the pros and cons to using /bin/false vs /bin/true for disabling modules.<p>[1] - <a href="https://downloads.cisecurity.org/#/" rel="nofollow">https://downloads.cisecurity.org/#/</a><p>[2] - <a href="https://news.ycombinator.com/item?id=13709591" rel="nofollow">https://news.ycombinator.com/item?id=13709591</a>
Huh. 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).<p><a href="https://en.wikipedia.org/wiki/Transparent_Inter-process_Communication" rel="nofollow">https://en.wikipedia.org/wiki/Transparent_Inter-process_Comm...</a>
Posted yesterday, but with no comments: <a href="https://news.ycombinator.com/item?id=30291958" rel="nofollow">https://news.ycombinator.com/item?id=30291958</a><p>A bug of similar severity was fixed a few months ago: <a href="https://news.ycombinator.com/item?id=29117815" rel="nofollow">https://news.ycombinator.com/item?id=29117815</a><p>Luckily, it looks like most distros don't load this module by default.
<i>The vulnerability has been present since the introduction of the TIPC monitoring framework in kernel version 4.8.</i><p>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.
I 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.<p>If you think quantum breaking cryptography is bad, wait until they figure out how to use it for fuzzing.
Any ideas why this service is in the kernel? <a href="https://www.kernel.org/doc/html/latest/networking/tipc.html" rel="nofollow">https://www.kernel.org/doc/html/latest/networking/tipc.html</a> doesn't seem to give provide the motivation.