Live data from Hacker News

Axios compromised on NPM – Malicious versions drop remote access trojan

stepsecurity.io

871–880 of 894 posts

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

#872

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 wrote a Docker-based sandbox [1] for myself last year to control the blast radius of such malicious packages. https://github.com/ashishb/amazing-sandbox

^ Vibe-coded slop spam ^

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

#873

Earlier quoted context omitted.

I wrote a Docker-based sandbox [1] for myself last year to control the blast radius of such malicious packages. https://github.com/ashishb/amazing-sandbox

^ Vibe-coded slop spam ^

What makes you think that? Your can see the commit history Rest was all written by me.

Unlike other criticisms of the project, this one feels personal as it is objectively incorrect.

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

#874
post #687
post #674

Earlier quoted context omitted.

There are several issues with "Batteries Included" ecosystems (like Python, C#/.NET, and Java): 1. They are not going to include everything. This includes things like new file formats. 2. They are going to be out of date whenever a standard changes (HTML, etc.), application changes (e.g. SQLite/PostgreSQL/etc. for SQL/ORM bindings), or API changes (DirectX, Vulcan, etc.). 3. Things like data structures, graphics APIs…

"Batteries included" means "ossification is guaranteed", yah. "stdlib is where code goes to die" is a fairly common phrase for a reason. There's clearly merit to both sides, but personally I think a major underlying cause is that libraries are trusted . Obviously that doesn't match reality. We desperately need a permission system for libraries, it's far harder to sneak stuff in when doing so requires an "adds dangero…

> "Batteries included" means "ossification is guaranteed", yah. "stdlib is where code goes to die" is a fairly common phrase for a reason.

Except I rather have ossified batteries that solve my problem, even if not as convinient as more modern alternatives, than not having them at all on a given platform.

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

#875

Earlier quoted context omitted.

Good points. But what do you mean with 3: "lockfile poisoning attacks, by making them more complicated" — making the lockfiles more complicated ? Also, 4) Simpler to `git diff` the changes, when you have the source locally already :- )

> making the lockfiles more complicated? Poor phrasing; I meant the attacks. Now you don’t just have a lockfile you need to sneakily modify, and the diff grows. As to your second point, yes. It’s really a different feeling when you add one more package and suddenly have 215 new files to check in!

> suddenly have 215 new files to check in!

How big is your repo, if I may ask?

Personally I store vendored dependencies in a submodule, where I can squash history, if it grows too large.

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

#877

Earlier quoted context omitted.

> My password manager, as is standard for most of them, will not fill or show a password if the URL bring visited doesn't match the credential. Thus, a credential not showing is a huge red flag. The workflow is pretty standardized so any deviation is a big red flag. I agree. > Maybe you can be more specific about the attack flow you are imagining and how it will work technically to bypass my controls. Can you be more…

I've believe I've already written that but it is that my password manager gets compromised. It is not perfectly secure and has failure points. Given that it is separate from the second factor a successful attack against the password manager still leaves an attacker unable to login without a separate compromise of my TOTP code. Of course that can also be compromised but two compromises is strictly more difficult than…

Right, so it's "password manager is compromised" or "password is reused", right? I'm pretty skeptical of these mattering relative to phishing, which is radically more common.

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

#878

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 wrote a Docker-based sandbox [1] for myself last year to control the blast radius of such malicious packages. https://github.com/ashishb/amazing-sandbox

Very useful, thanks
Post reply on HN