Maybe you shouldn't install new software for a bit

This was always a nightmare waiting to happen. The sheer mass of packages and the consequent vast attack surface for supply chain attacks was always a problem that was eventually going to blow up in everyone's face.

But it was too convenient. Anyone warning about it or trying to limit the damage was shouted down by people who had no experience of any other way of doing things. "import antigravity" is just too easy to do without.

Well, now we're reaching the "find out" part of the process I guess.

Alternatively, switch to an operating system like FreeBSD which doesn't take a YOLO approach to security. Security fixes don't just get tossed into the FreeBSD kernel without coordination; they go through the FreeBSD security team and we have binary updates (via FreeBSD Update, and via pkgbase for 15.0-RELEASE) published within a couple minutes of the patches hitting the src tree. (Roughly speaking, a few seconds for the "I've pushed the patches" message to go out on slack, 10-30 seconds for patches to be uploaded, and up to a minute for mirrors to sync).

"Wait a week to install software" does not work. Just a few months ago a massive exploit hit the web, which was a timed attack which sat for more than a month before executing. If everyone starts waiting a week, their exploits will wait 2 weeks. Cyber criminals do not need to exploit you immediately, they just need to exploit you. (It also doesn't change a large range of vuln classes like typosquatting)

There's already an okay solution to supply-chain attacks against dependency managers like npm, PyPI, and Cargo: set them to only install package versions that are more than a few days old. The recent high-profile attacks were all caught and rolled back within a day, so doing this would have let you safely avoid the attacks. It really should be the default behavior. Let self-selected beta testers and security scanner companies try out the newest versions of packages for a day before you try them. Instructions: https://cooldowns.dev/

For the newer players who have gotten into continuous integration and containerized builds, consider checking on your systems to be sure you're not pulling 'latest' across a bunch of packages with every build.

We set up our base containers with all the external dependencies already in them and then only update those explicitly when we decide it's time.

This means we might be a bit behind the bleeding edge, but we're also taking on a lot less risk with random supply chain vulns getting instant global distribution.

Can someone help me understand the copyfail thing and how it relates to NPM packages?

Edit: I think I understand. copyfail is a kernel bug that lets a malicious npm package get root access on your Linux server, right?

So now, while there are unpatched servers, is when it would be the perfect time for attackers to target NPM packages.

And the advice isn't just "update your kernel" because we are still finding new related issues?

I'm holding off on upgrading to Ubuntu 26.04 LTS until we have a few months of experience with the new release. Canonical just had a huge DDOS attack, and there might have been other attacks hidden in all that traffic.

Literally implemented PR guards today to prevent the team merging any dependencies that didn’t have explicit versions pinned (and that matched the resolution in the lock file).

People lamented semver not being trustable but that ship sailed a long time ago, and supply chain attacks are going to get worse before they get better.

Our team is pretty minimal when it comes to enforced hooks (everyone has their own workflow) but no one could come up with an objection to this one.

I wonder whether there is any tool that can prevent npm from downloading any package that has been published in the last month. While I miss out on possible fixes, this would prevent downloading some 3rd level dep that takes over my machine.

What’s interesting here is that the exploit chain itself isn’t especially novel anymore — page cache corruption has become a recurring pattern (Dirty Pipe, Copy Fail, Dirty Frag). The worrying part is how quickly public patches are now being reverse-engineered into weaponized exploits.

The old “quiet patch before disclosure” model may simply not work anymore in the LLM era.

This gets me to ask whether I have been hacked . For a few weeks now, both my main mbp and iPhone have been showing unexpected hangs of 1-30 seconds. I can’t find out what’s causing it - not memory pressure, not cpu load.

I am worried that the sluggishness appeared about the same time on both devices

the lottery of either getting a new supply-chain attack or the fixes from Mythos with every single update

"If it ain't broke, don't fix it" is its own area of risk that people often ignore

It really pisses me off that responsible disclosure timelines are being ignored.

Remember the whole discussion when UNIX was supposed to not need anti-virus and talking down PCs?

Behaviours matter more than OS security primitives.

To mitigate supply chain attacks like this, I've taken to specifying exact versions in my Rust cargo.toml, and when importing new crates, select the previous-to-latest version. Is this a reasonable mitigation? It bugs me that Swift deprecates the concept of specifying exact versions, it actively pushes you towards semver which leaves the door open to this.

The post is about Linux vulnerabilities, but given the recent supply chain attacks, I'd be especially careful with Homebrew: https://x.com/i/status/2052106143271354859

Yes, and, for non-personal machines or anything connected to the internet: now is a great time to get good at rolling out patches and new releases quickly.

The scary part is how many teams still have builds implicitly depending on “whatever was latest 5 minutes ago”.

Containerization improved reproducibility in some ways, but in practice a lot of CI pipelines still behave like live dependency roulette.

I got rid of half of my VSCode extensions a couple days ago, its too risky.

I dislike FUD like this :/

Maybe the new software should not have any errors. I know, I have higher expectations than the average commercial software customer.

> Copy Fail 2: Electric Boogaloo

What are people thinking with these meme style vulnerability names? It's going to be hard to pitch "we need to push back the timeline on this new infrastructure deploy while we mitigate Copy Fail 2: Electric Boogaloo".

I still can’t believe people are ok with software updates every day. Looking at you Claude code

You don't need a kernel LPE to root a Linux developer machine.

Just alias sudo to sudo-but-also-keep-password-and-execute-a-payload in ~/.bashrc and wait up to 24 hours. Maybe also simulate some breakage by intercepting other commands and force the user to run 'sudo systemctl' or something sooner rather than later.

It seems like this round of vulns is going to be significant. What is the right response?

I've been doing alot of that lately

I do a bit wonder what happens as standard practice becomes to lag more and more and more. Who is there left that's looking, that'd finding out?

100% doing this, sadly

Fun fact: You still can't build the vllm container with updated dependencies since llmlite got pwned. Either due to regression bugs, or due to impossible transient dependencies in the dependency tree that are not resolvable. There is just too much slopcode down the line, and too many dependencies relying on pinned outdated (and unpublished) dependencies.

I switched to llama.cpp because of that.

To me it feels more and more that the slopcode world is the opposite philosophy of reproducible builds. It's like the anti methodology of how to work in that regard.

Before, everyone was publishing breaking changes in subminor packages because nobody adhered to any API versioning system standards. Now it's every commit that can break things. That is not an improvement.

[flagged]

[dead]

but we were just last month asking where all that great productivity was coming with the AI wave, and now everyones got some AI bit and bob that was vibe coded with the idea that the cloude providers have an endless stream of capacity for the endless slop trough we're all dying to dine at.

Don't install anything, use an LLM to write everything from scratch. It may have bugs, but no one will know how to exploit them, especially when closed source.

Code is cheap and is becoming cheaper by the day. We need new paradigms.

Fedora upgrades have usually been great, but I jumped the gun on Fedora 44. Sound completely dead with no Pipewire service available. ALSA not responding. Firefox dies immediately if I open a new tab or right click anywhere on the browser itself (inlcuding nightly builds). QEMU refuses to load. Maybe something got completely f'd in the upgrade process.. I never had an issue before having upgraded from Fedora 38 all the way to 43. I am too tired to investigate it all.

I know this is unrelated to the article, but related to the title.