This specific issue would have been prevented with with Rust.
Rust haters in shambles
lol no, Rust itself is AI now btw
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.
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 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.
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.
