Supply chain attacks on developer tools are getting more sophisticated. This hits every project using these plugins.
The scary part is how long malicious packages can sit undetected. Your CI/CD pipeline could be compromised for months before anyone notices.
This is why I always say to scan all dependencies in your compliance checks - not just for known vulnerabilities, but for unexpected changes in package behavior. When a routine update starts making network calls it never made before, that's a red flag.
Malicious versions of Nx and some supporting plugins were published
451–460 of 460 posts
Re: Malicious versions of Nx and some supporting plugins were published
#452Any practical tips for hardened security when programming? Don't want to be exposed to npm/pip/cargo installing password/browser cookie stealers. What worries me is the little to no isolation between the dev environment and the rest of the OS for day to day use.
Use as few deps as possible, and run your projects in containers, or even better, VMs.
That doesn't guarantee anything still, that's the beauty of Javascript ;)
Re: Malicious versions of Nx and some supporting plugins were published
#453Earlier quoted context omitted.
> People really need to start thinking twice when adding a new dependency. So many supply chain attacks this year. I was really nervous when "language package managers" started to catch on. I work in the systems programming world, not the web world, so for the past decade, I looked from a distance at stuff like pip and npm and whatever with kind of a questionable side-eye. But when I did a Rust project and saw how tr…
Remember the pre package manager days was ossified, archaic, insecure installations because self managing dependencies is hard, and people didn't keep them up to date. You need to get your deps from somewhere, so in the pre-package manager days you still just downloaded it from somewhere - a vendor's web site, or sourceforge, or whatever, and probably didn't audit it, and hoped it was secure. It's still work to keep…
If most of your deps are coming from the distro, they are audited already. Typically, I never had to add more than a handful of extra deps in any projects I ever worked on. That's a no brainer to manage.
Re: Malicious versions of Nx and some supporting plugins were published
#454Earlier quoted context omitted.
Whenever I read this well-meaning advice I have to ask: Do you actually read hundreds of thousands of lines of code (or more) that NPM installed? Because the workflow for 99.99% of developers is something resembling: 1. git clone 2. npm install (which pulls in a malicious dependency but disabling post-install scripts saved you for now!) 3. npm run (executing your malicious dependency, you're now infected) The only wa…
Yeah I guess it probably helps you specifically , because most malware is going to do the lazy thing and use install scripts. But it doesn't help everyone in general because if e.g. NPM disabled those scripts entirely (or made them opt-in) then the malware authors would just put their malware into the `npm run` as you say.
Indeed it may save you in case the malware is being particularly lazy but I think it may do more harm than good by giving people a false sense of security and it can also break packages that use post-install scrips for legitimate reasons.
For anyone who actually cares about supply chain attacks, the minimum you should be doing is running untrusted code in some sort of a sandbox that doesn't have access to important credentials like SSH keys, like a dev container of some sort.
You would still need to audit the code otherwise you might ship a backdoor to production but it would at least protect you against a developer machine compromise... unless you get particularly unlucky and it also leverages a container escape 0-day, but that's secure enough for me personally.
Re: Malicious versions of Nx and some supporting plugins were published
#455Earlier quoted context omitted.
Indeed, it seems insane that we're pining for the days of autotools, configure scripts and the cleanly inspectable dependency structure. But... We absolutely are.
Disagree. And why wouldn't dep structure be cleanly inspectable.
Decades ago, you'd type "configure" and be told you need to install libfoobar version 9, and you would, and it would work.
Now you get npm whining at you about an unsatisfiable dependency cycle because some three-level-removed transitive dependency you've never heard of put a hard lock file in that reference a version that got pulled for a security flaw.
Re: Malicious versions of Nx and some supporting plugins were published
#456Periodic reminder to disable npm install scripts. npm config set ignore-scripts true [--global] It's easy to do both at project level and globally, and these days there are quite few legit packages that don't work without them. For those that don't, you can create a separate installation script to your project that cds into that folder and runs their install-script. I know this isn't a silver bullet solution to suppl…
I also use bubblewrap to isolate npm/pnpm/yarn (and everything started by them) from the rest of the system. Let's say all your source code resides in ~/code; put this somewhere in the beginning of your $PATH and name it `npm`; create symlinks/hardlinks to it for other package managers: #!/usr/bin/bash bin=$(basename "$0") exec bwrap \ --bind ~/.cache/nodejs ~/.cache \ --bind ~/code ~/code \ --dev /dev \ --die-with-p…
Very cool idea. Thanks for sharing. I made some minor tweaks based on feedback to your comment:
#!/usr/bin/env bash
#
# See: https://news.ycombinator.com/item?id=45034496
bin=$(basename "$0")
echo "==========================="
echo "Wrapping $bin in bubblewrap"
echo "==========================="
exec bwrap \
--bind ~/.cache ~/.cache \
--bind "${PWD}" "${PWD}" \
--dev /dev \
--die-with-parent \
--disable-userns \
--new-session \
--proc /proc \
--ro-bind /etc/ca-certificates /etc/ca-certificates \
--ro-bind /etc/resolv.conf /etc/resolv.conf \
--ro-bind /etc/ssl /etc/ssl \
--ro-bind /usr /usr \
--setenv PATH /usr/bin \
--symlink /usr/bin /bin \
--symlink /usr/bin /sbin \
--symlink /usr/lib /lib \
--symlink /usr/lib64 /lib64 \
--tmpfs /tmp \
--unshare-all \
--unshare-user \
--share-net \
/usr/bin/env "$bin" "$@"
Re: Malicious versions of Nx and some supporting plugins were published
#457There is a low hanging fruit in making GitHub Actions more secure (anyone from GitHub here?):
- Forbid (or at least warn about) shell interpolation in composite actions and guide to using environment variables instead
- Warn unless all external actions are pinned by git commit (with customizable exceptions)
- Warn unless all used docker images are pinned by digestsRe: Malicious versions of Nx and some supporting plugins were published
#458Earlier quoted context omitted.
malware isn't remote. therefore it isn't remote code execution
If you can execute code on some machine without having access to that machine, then it's RCE. Whether you gain RCE through an exploit in a bad network protocol or through tricking the user into running your code (i.e. this attack) is merely a delivery mechanism. It's still RCE
A user executing malware on their local machine is not remote.
Re: Malicious versions of Nx and some supporting plugins were published
#459Earlier quoted context omitted.
As a linux admin, I refuse to install npm or anything that requires it as a dep. It's been bad since the start. At least some people are starting to see it.
> As a linux admin, I refuse to install npm or anything that requires it as a dep. It's been bad since the start. As a front-end web developer, I need a node package manager; and npm comes bundled with node.
How in the world did we survive before node?
Re: Malicious versions of Nx and some supporting plugins were published
#460Earlier quoted context omitted.
Or use pnpm. The latest versions have all dependency lifecycle scripts ignored by default. You must whitelist each package.
Same for bun, which I find faster than pnpm
Bun still executes the scripts of a certain hardcoded list of 500 packages, it's not exactly the same.