Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Axios compromised on NPM – Malicious versions drop remote access trojan

stepsecurity.io

Post reply on HN
Print view View original

241–250 of 894 posts

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#241

Post by bob1029 »

"Batteries included" ecosystems are the only persistent solution to the package manager problem.

If your first party tooling contains all the functionality you typically need, it's possible you can be productive with zero 3rd party dependencies. In practice you will tend to have a few, but you won't be vendoring out critical things like HTTP, TCP, JSON, string sanitation, cryptography. These are beacons for attackers. Everything depends on this stuff so the motivation for attacking these common surfaces is high.

I can literally count on one hand the number of 3rd party dependencies I've used in the last year. Dapper is the only regular thing I can come up with. Sometimes ScottPlot. Both of my SQL providers (MSSQL and SQLite) are first party as well. This is a major reason why they're the only sql providers I use.

Maybe I am just so traumatized from compliance and auditing in regulated software business, but this feels like a happier way to build software too. My tools tend to stay right where I left them the previous day. I don't have to worry about my hammer or screw drivers stealing all my bitcoin in the middle of the night.

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#242

Post by monarchwadia »

hyperadvanced wrote: post #147

Just sanity checking - if I only ever install axios in a container that has no secrets mounted in to its env, is there any real way I can get pwned by this kind of thing?

Yes. Docker breakout is a class of vulnerabilities into itself.

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#243

Post by zdc1 »

rolandog wrote: post #228
yohannesk wrote: post #206

Earlier quoted context omitted.

And we also need localization. Each country can have their own holidays

And we need groups of locales for teams that are split across multiple locations; e.g.: new_date = add_workdays( workdays=1.5, start=datetime.now(), regions=["es", "mx", "nl", "us"], )

Might be better to calculate them separately for each locale and then tie-break with your own approach (min/max/avg/median/etc.)

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#244

Post by mxmlnkn »

himata4113 wrote: post #30

I recommend everyone to use bwrap if you're on linux and alias all package managers / anything that has post build logic with it. I have bwrap configured to override: npm, pip, cargo, mvn, gradle, everything you can think of and I only give it the access it needs, strip anything that is useless to it anyway, deny dbus, sockets, everything. SSH is forwarded via socket (ssh-add). This limits the blast radius to your CW…

I like the idea of bubblewrap, but my pain point is that it is work to set it up correctly with bind mounts and forwarding necessary environment variables to make the program actually work usefully. Could you share your pip bwrap configuration? It sounds useful.

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#245

Post by strogonoff »

inbx0 wrote: post #209
strogonoff wrote: post #148

Essential steps to minimise your exposure to NPM supply chain attacks: — Run Yarn in zero-installs mode (or equivalent for your package manager). Every new or changed dependency gets checked in. — Disable post-install scripts. If you don’t, at least make sure your package manager prompts for scripts during install, in which case you stop and look at what it’s going to run. — If third-party code runs in development, i…

> Run Yarn in zero-installs mode (or equivalent for your package manager). Every new or changed dependency gets checked in. Idk, lockfiles provide almost as good protection without putting the binaries in git. At least with `--frozen-lockfile` option.

Zero-installs mode does not replace the lockfile. Your lockfile is still the source of truth regarding integrity hashes.

However, it’s an extra line of defence against

1) your registry being down (preventing you from pushing a security hotfix when you find out another package compromised your product),

2) package unpublishing attacks (your install step fails or asks you to pick a replacement version, what do you do at 5pm on a Friday?), and

3) possibly (but haven’t looked in depth) lockfile poisoning attacks, by making them more complicated.

Also, it makes the size of your dependency graph (or changes therein) much more tangible and obvious, compared to some lines in a lockfile.

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#247

Post by charcircuit »

hu3 wrote: post #207
charcircuit wrote: post #193

Hopefully desktop Linux users will start to understand that malware actually does exist for Linux and that their operating system is doing nothing to protect them from getting RATed.

What do you mean? Linux has the most powerful native process isolation arsenal at the user disposal. And some distros use even more isolation mechanisms on top of the ones provided by the kernel like snap and flatpak. And then you can recreate the entire thing like a spellbook with nix. Docker works natively in it. Do I need to say more? Linux is a decade ahead here with regards for security options available to the…

Yet npm isn't using them allowing this RAT to work. It is not secure by default. It requires every app to manually opt in to being secure. This opt in approach to security puts desktop Linux decades behind in regards to security. Not ahead.

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#248

Post by regularfry »

voidfunc wrote: post #135
nananana9 wrote: post #114

Package managers are a failed experiment. We have libraries like SQLite, which is a single .c file that you drag into your project and it immediately does a ton of incredibly useful, non-trivial work for you, while barely increasing your executable's size. The issue is not dependencies themselves, it's transitive ones. Nobody installs left-pad or is-even-number directly, and "libraries" like these are the vast majori…

I'd really like to see package managers organized around rings where a very small core of incredibly important stuff is kept in ring 0, ring 1 gets a slightly wider amount of stuff and can only depend on ring 0 dependencies and then ring 2+ is the crapware libraries that infect most ecosystems. But maybe that's not the right fit either. The world where package managers are just open to whatever needs to die. It's no…

The OS distro model is actually the right one here. Upstream authors hate it, but having a layer that's responsible for picking versions out of the ecosystem and compiling an internally consistent grouping of known mutually-compatible versions that you can subscribe to means that a lot of the random churn just falls away. Once you've got that layer, you only need to be aware of security problems in the specific versions you care about, you can specifically patch only them, and you've got a distribution channel for the fixes where it's far more feasible to say "just auto-apply anything that comes via this route".

That model effectively becomes your ring 1. Ring 0 is the stdlib and the package manager itself, and - because you would always need to be able to step outside the distribution for either freshness or "that's not been picked up by the distro yet" reasons - the ecosystem package repositories are the wild west ring 2.

In the language ecosystems I'm only aware of Quicklisp/Ultralisp and Haskell's Stackage that work like this. Everything else is effectively a rolling distro that hasn't realised that's what it is yet.

Re: Axios compromised on NPM – Malicious versions drop remote access trojan

#249

Post by waterTanuki »

slopinthebag wrote: post #105
waterTanuki wrote: post #31

Earlier quoted context omitted.

Because no other language has ever had supply chain attacks ever, in history. Nope. https://blog.rust-lang.org/2022/05/10/malicious-crate-rustde... https://en.wikipedia.org/wiki/Log4Shell https://blog.pypi.org/posts/2024-12-11-ultralytics-attack-an... https://about.gitlab.com/blog/gitlab-catches-mongodb-go-modu... https://www.reversinglabs.com/blog/packagist-php-repo-supply...

Come on dude. The issue is the frequency and magnitude of these attacks. Log4Shell was also not a supply chain attack. I looked at the Rust one for example, which is literally just a malicious crate someone uploaded with a similar name as a popular one: > The crate had less than 500 downloads since its first release on 2022-03-25, and no crates on the crates.io registry depended on it. Compared to Axios, which gets 8…

What exactly do you think the argument is?

The issues have everything to do with npm as a platform and nothing with JS as a language. You can use JS without npm. Saying you'll escape supply chain attacks by not using JS is like saying you'll be saved from an car crash with a parachute.

Post reply on HN