Why are they calling out specific distros for a kernel issue? It’s the kernel, it affects every distro using an affected release of it.
Because some have released updated kernels while others haven’t
Maybe they should use better distros.
I use Arch, btw.
I use Arch, btw
Yes. We figured. Lol
I know the answer to that. It’s in the article.
You can disable multipath TCP by issuing this command
sudo sysctl -w net.mptcp.enabled=0persist across reboots with
echo "net.mptcp.enabled=0" | sudo tee /etc/sysctl.d/99-mptcp.conf
If your kernel is older than 5.6 then there is no multipath TCP to disable. e.g. Ubuntu 20.04 should be fine.
Note: It’s unclear whether this is an adequate mitigation.
The score sounds a bit overblown considering this is for MPTCP which is as far as I understand rarely used? And it sounds like the chance of this leading to anything more than a crash is low. But whatever.
It’s a data race. Memory safety is still super important for security.
Every Go application since 1.24 will activate MPTCP on their sockets by default, so it’s in fact quite widely used.
Many orgs consider the rating overblown. While the impact is devastating, the attack is hard to pull of.
They’re able to issue shell commands as root.
This specific issue would have been prevented with with Rust.
Rust haters in shambles
So could have Java, Go, C# or any language with GC. With garbage collection, the options object stays alive as long as any CPU holds a pointer to it, so use-after-free can’t happen.
Besides, this exploit is so hard to pull off the only realistic outcome is a kernel panic, and that hasn’t even been publicly demoed.
So could have Java, Go, C# or any language with GC.
No. Those aren’t allowed in Linux Kernel.
With garbage collection
Garbage Collection is not usable in an operating system Kernel.
Clearly, but it’s worth pointing out that this kind of problem isn’t uniquely fixed by “just use Rust”.
I never said that only Rust prevents this. I just said using Rust in the Kernel would have prevented this issue.
Fair enough. Don’t you think it simplifies the issue a little bit? How long would it take to rewrite the entire TCP stack in rust?
lol no, Rust itself is AI now btw
IPv6 is not affected by this race because the kernel copies the options for IPv6 connections.
It’s been a slow-going effort to get a compile flag into the kernel that disables IPv4, but this is precisely the type of bug which that flag would have avoided. When devices choose to natively use IPv6-only – eg IoT – they really shouldn’t have to also accept an increased attack surface from Legacy IP, something that is increasingly unnecessary.
Disabling IPv4 when it’s unneeded is good security posture, but such a choice is not available yet in Linux.
On every embedded including a few IoT devices I worked on, every single time the IPv6 is either outright disabled, ignored, or treated like IPv4 even when telling my client what they want is not how IPv6 is designed.
May not be the same everywhere, just my anecdotal experience.
Also remember:
The ‘S’ in IoT stands for security.
I’ve been doing this at home. So far, none of my phones or access points use IPv4. I should be able to get the desktops off it soon. Microsoft finally got it working in Windows after decades of (stalled) development.
I disable IPv6 to reduce the vector
Nice.
