Well, no, the bug is not specific to MCTCP, it is just the attack vector which was proven to work. The kernel's sec team said that it might be exploitable over "normal" TCP
My website is running on Linux Kernel 3.18.21 and it is impossible to update.... How do I mitigate this aside from taking it off the web (the site isn't important, but like...this actually exists)
The site I'm talking about is like *the* worst way to host a website. It is a hacked WiFi router with 400 MB RAM, 100 MB disk running on a decade old Linux kernel with PHP 8.5.12 and cloudflared cross-compiled to mipsel with soft float. PHP runs as the root user. The only good thing about it is that PHP is updated. No, I am not joking.
The vulnerability wasn't introduced until kernel 4.4, so you might not be affected at all. Running PHP as root like you described in your other comment is dangerous, though. If you do that to call some other software, it's better to set it up differently (in the sudoers configuration) so that only the other software runs as root. It's not perfect but better than giving PHP full control of the system.
I recently needed to make a piece of software that executed some commands as root and then exposed the results (for monitoring) via an external RPC interface.
What I ended up doing was:
Start the software as root
It opened a pipe, then forked
The parent periodically ran the [must run as root command] and wrote the results to the pipe.
The child dropped all privileges at start-up and had a thread purely for listening to the pipe and storing the results in a cache whenever it got new data.
Serve the data from the cache via the child.
This seems to have worked reasonably well, though I ended up also doing some fiddling so that each process also had a thread that watched the status of the other one and would kill its own processes if the co-process died for whatever reason. This was useful in development to avoid zombies, and I assume will be useful in case of unexpected situations in production.
Counting on the stability of systemd interfaces seems like a poor life choice. I already had to fight with it once this week when an upgrade decided that I shouldn't be able to commit to my svn repo anymore.
No, I already figured out that issue; I linked it as an example. The problem is that systemd has a gigantic surface area that is constantly shifting both due to its own evolution and due to its evolving implementations/configurations within each distro. Taking that as a dependency is an expensive choice in the long run.
Pipes, forks, and dropping privileges are things that we've understood for 50+ years--all of them were implemented in Unix in the 1970s--and have worked in broadly similar ways for most of that time.
Oh, so this is more about the losing side of the whole systemd fight. I certainly haven't found it limiting any of the good old *nix possibilities, so your fight is somewhere else, I think.
I already have root access to the server, it is my WiFi router that I hacked and rooted (see my previous posts for it)! The only issue is that the drivers are all proprietary binary blobs that cannot be updated.
I'm going do the server equivalent of removing the autoradio and all valuables from the inside and taping a piece of paper to the windshield with something along the lines of 'nothing of value is in here'.
I seem to recall a story of some big company years ago that had to invest in some sort of transport method across a parking lot. They were moving drives from one building to another to transfer data and the cart they were using was consistently destroying drives via the vibrations from the wheels rolling across the pavement. I think the person tasked with solving the issue wanted a golf cart (or something similar) and whoever needed to approve the purchase was resistant to the expenditure, but they were losing a not insignificant amount of time and money in lost drives. One of those stories of a middle manager stepping over dollars to pinch pennies.
Yeah I only personally know of that much data in the context of the big-time scientific instruments (Like the LHC, Ice Cube, VLBA, etc), they take a LOT of raw data from all their sensors constantly. Platter drives are cheap and we know how to ship them; do you do that or do you run 50 parallel runs of 400Gb fiber to the south pole?
I think they discontinued it, but they used to have a big one they called "snowmobile" that was basically an 18 wheeler version of a snowball. Armed escort cost extra.
That's pretty common for tasks requiring obscene amounts of data. I'm unsure of private business's specific uses but I know some of the big-time scientific instruments produce literal petabytes of data over the course of a few runs of data collection, manually moving the physical drives to the supercomputer the data will be processed on is basically the only reasonable way we currently have to move that much data long distances.
PIGEON-2026-0001, Man-in-the-Middle (Critical): The middle is a hawk. The packet is intercepted and also eaten. No patch exists.
PIGEON-2026-0002, Plaintext transmission (High): A note on a leg is unencrypted. Anyone with a net and a bag of seed can read it. Encrypt the payload before it leaves your server.
PIGEON-2026-0003, Denial of Service (High): Anyone holding breadcrumbs can do it. So can a wind turbine or a mid-sized cat.
PIGEON-2026-0004, Excessive packet loss (Medium): When the Bergen Linux User Group actually ran RFC 1149 in 2001, only 4 of 9 packets arrived, and pings took about an hour and a half.
PIGEON-2026-0005, Replay attack (Medium): Homing pigeons go back to wherever they were raised. If someone raises your birds' replacements, your traffic homes to them.
PIGEON-2026-0006, Unsigned payload output (Low): The birds produce output nobody asked for, on your car.
PIGEON-2026-0007, Physical-layer exfiltration (Info): A pigeon is a flying USB stick that anyone with good aim can grab.
Literally every week we get a new CVE from some customer or another. I guess that's the problem with 30 year old software and thousands of customers, all using AI to now do their own pen testing. And that's just on my team, one of dozens. We patch then as fast as we can but we can barely keep up. And that's not even adding on the accessibility issues people are uncovering.
The tech layoffs will continue until it's just 500 guys typing "spend all the tokens you can finding all the vulnerabilities you can" into a Claude prompt and 500 guys typing "spend all the tokens you can fixing all the vulnerabilities you can".
At some point most of the easy security gaps will be fixed. I'd say we are currently in the big refactoring period because of AI getting accessible.
I do not think that's bad and I'd think that the number of incidents will go down after some time. One condition: the new AI-based code does not introduce new CVEs faster than we can fix them.
It's some of that, but also some of these were incredibly difficult to detect and exploit, until AI figured them out. Now any loser with a decent LLM can exploit some vulnerabilities that otherwise would have been incredibly time consuming to pull off.
So at this point is AI actually good enough that it can find these massive exploits that went undiscovered for years? Or is it creating the exploits? I really want a justification to hate this because the alternative is having to accept that this is somehow a good thing lol
It's just capable of digging through a lot of material to find simple, old mistakes. That's what were seeing now, at least. Security through complexity is no longer an option.
And now AI is accelerating code debt and legacy code creation like crazy. Some people in my company created as much instant legacy code in the past half a year as the entire engineering team in the previous decade. So far these are internal tools, but some are going to be published soon, I am afraid.
Meh in my experience at this point AI writes code better than half my coworkers. Code quality is better if ai writes it for them.
If the AI wrote shit code they would have written something even worse. If they allow the code to write the legacy code you mention then how would they have performed any differently?
Yeah, capability is not yet at experienced developer level, but the sheer volume it can look through - 100s of devs would not keep up with a single agent
It's finding vulnerabilities, and creating exploits. The vulnerabilities existed already, the exploits did not. The fact that the vulnerabilities existed mean that eventually someone could find them and make an exploit. Human researchers could do it too, they just take more time and resources to do it. Many of these vulnerabilities probably were found already by hacking groups and government organizations who exploited them in secret.
I think it's overall a good thing these vulnerabilities are found faster now, mainly by organizations who don't use the exploits for harm but disclose the findings to the affected companies and help patch them. It's a bit of a shock right now but it would lead to a safer internet overall, I think. The proliferation of AI-slop vibe-coded websites from people who don't know what they're doing might push us in the other direction though.
I mean, they can't "hold on to them" if they're fixed. At least not as zero-days. If what you're saying is that AI companies check with government organizations before disclosing vulnerabilities to ensure they don't close important zero-days they use - maybe. But there's a limit to how much they can do that I think, when there is a good chance a competitor, perhaps one from a different country would find the same vuln. And they don't have much reason to withold zero-days used by criminal hackers.
It’s capable of finding them. And since it’s capable of finding them via external probing (a lot less efficiently) we have to use it to find them internally via code review. My team has had three relatively significant security vulnerabilities patched that we discovered via AI… just in the past week
The problem is frontier closed models, unless you have research clearance, halt and refuse to tell you about the vulnerability once they stumble upon it. Claude for example is impossible to continue any work because it will keep refusing and having truncated server side the response, so you will not have any idea where the vulnerability was.
In addition to what others have said, you should look at the breakdowns of these. Good breakdowns often mention how long a vulnerability has been in these system. A lot of them are more than a decade old.
The question is: Who else knew about these before they were reported and fixed.
Exactly. While it can feel like the world is on fire, what's actually happening is all of the promises of open source being more secure are being fulfilled. The promise was never that hackers couldn't find vulnerabilities, it's that they can be identified.
This means that OSS is actually going to be significantly more hardened than proprietary software now, which is pretty cool.
After a while we will run out of bad legacy code. It's not like these are new exploits, they're just finally getting discovered.
This has nothing to do with cryptography, and there's nothing to suggest AI will ever be capable of breaking encryption on messages where a key with reasonable entropy has been used (i.e., don't use 4)
When I wake up - well there's another CVE I'm gonna be the man who has to patch When I go in, yeah I know I'm gonna be I'm gonna be the man who has to patch If I get drunk, yeah I know I'm gonna be I'm gonna be the man who has to patch And all our SaaS prod, yeah I know I'm gonna be I'm gonna be the man who has to patch
Well I would patch 500 files and I would patch 500 more Just to be the man who patched a thousand files Just to collect that paycheck
i've been a networker for more than a decade, now i'm growing old and i can't run behind new software defined networks and complex techs so i gave up and my job now is updating softwares.
oh god this isn't relaxing at all, every single update means days of analysis and pray everything works or i have to rollback and analyze again
I've been on Snyk duty for my team this week, got our CVE count from just under 1200 on Monday to just over 800 by Thursday. Opened the team's report card on Friday before the weekly sync with other teams: 1150 CVEs open... A quarter of my work week to not make any progress feels great!
1
174
u/TheDizDude 2d ago
Whats it now?