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.
This specific issue would have been prevented with with Rust.
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?
I don’t think a rewrite in Rust is necessary for everything that has a bug. Instead fixing the bug is probably more secure, before such alternative Rust code is mature enough to replace it.
Rust haters in shambles
lol no, Rust itself is AI now btw
Unsafe allows that, yes.
This is an issue from 2019?
Still open? Only tagged in 2024?
How makes this rust ai?
It doesn’t. It’s just a separate fact that Rust allows LLM generated code in. The common argument is that Rust doesn’t make everything it touches secure.
The common argument is that Rust doesn’t make everything it touches secure.
No one said Rust makes everything it touches secure. You should stop thinking in black and white. I said this specific issue would not have happened with Rust, because Rust catches this type of issue at compilation time.
catches this type of issue at compilation time
This type of issue is called use-after-free.
I sent a link to a use-after-free bug in RedoxOS, the OS advertised as being written in Rust for security. The issue is tracked as CVE with severity 7.8.
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.
Tacking this on here to increase visibility.
You can see who is already listening to multipath TCP by running:ss -Mlnrunning the sysctl command will prevent future ports being opened, but it will not close existing ones, you need to manually restart the services/containers.
Go applications enable the functionality in their ports by default.
My understanding is that a proper fix will come from a kernel update, since this affects plain TCP, but MPTCP has a known attack path.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.
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.
