Would dropping these specialized ipv4 syn packets with extra header size beyond 20 bytes with the firewall (iptables/nftables/etc) be low enough in the order of things to mitigate the attack? Like, iptables -A INPUT -p tcp --syn -m u32 --u32 "0>>24&0xF=6:15" -j DROP ?
This one is quite serious and the type of vulnerability is once again, a C style memory corruption and a race condition combined; leading to an RCE.
At this point, we seriously need to discuss whether if the major projects still written in C such as Linux, Chromium and even git can even handle the stream of now near infinite bugs being discovered with AI.
Attackers are already rapidly finding and building exploits for those vulnerabilities the moment they are discovered with abliterated frontier-level models.
These sort of vulnerabilities are far to common in those projects and in the future, it will be extremely unsafe for even experts to continue using C or C++ in any way.
Unless someone vibecodes a new OS and convinces everyone to use it, we're stuck with what we got. Reaching feature parity with Linux and then debugging it to the point where it'd be usable is a gargantuan undertaking.
I bet there's a half-life to bugs though. Bugs might be infinite over the lifespan of a project, but the rate that they are produced goes down with our ability to detect them.
A lot are being found _now_ in projects written in C because the backlog of bugs to find is mostly written in C. We haven't yet gotten to the point when we're detecting most bugs before they're released, but we will.
This is a good portion just slop, another 9000 word article that could have been a couple of paragraphs. More text doesn't mean better.
Thankfully the vast majority of servers are not creating MPTCP listeners by default (that I'm aware of).
Not sure why the article doesn't mention it, but you can specifically check for MPTCP listeners using `ss -M`.
Would dropping these specialized ipv4 syn packets with extra header size beyond 20 bytes with the firewall (iptables/nftables/etc) be low enough in the order of things to mitigate the attack? Like, iptables -A INPUT -p tcp --syn -m u32 --u32 "0>>24&0xF=6:15" -j DROP ?
This one is quite serious and the type of vulnerability is once again, a C style memory corruption and a race condition combined; leading to an RCE.
At this point, we seriously need to discuss whether if the major projects still written in C such as Linux, Chromium and even git can even handle the stream of now near infinite bugs being discovered with AI.
Attackers are already rapidly finding and building exploits for those vulnerabilities the moment they are discovered with abliterated frontier-level models.
These sort of vulnerabilities are far to common in those projects and in the future, it will be extremely unsafe for even experts to continue using C or C++ in any way.
Unless someone vibecodes a new OS and convinces everyone to use it, we're stuck with what we got. Reaching feature parity with Linux and then debugging it to the point where it'd be usable is a gargantuan undertaking.
I bet there's a half-life to bugs though. Bugs might be infinite over the lifespan of a project, but the rate that they are produced goes down with our ability to detect them.
A lot are being found _now_ in projects written in C because the backlog of bugs to find is mostly written in C. We haven't yet gotten to the point when we're detecting most bugs before they're released, but we will.
Leading 'maybe' to an RCE, i imagine you need to groom the heap first, unless there is something i'm missing.
Edit: also thanks for using RCE correctly, it seems to be any kind of code execution these days is considered "RCE".. boo.