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

841–850 of 894 posts

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

#841

Post by nazcan »

Groxx wrote: post #687
rhdunn wrote: 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…

100% to libraries having permissions. If I'm using some code to say compute a hash of a byte array, it should not have access to say the filesystem nor network.

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

#842

Post by lokar »

Groxx wrote: post #801
lokar wrote: post #797

Earlier quoted context omitted.

Golang seems to do a good job of keeping the standard library up to date and clean

Largely, yes. But also everyone sane avoids the built-in http client in any production setting because it has rather severe footguns and complicated (and limited) ability to control it. It can't be fixed in-place due to its API design... and there is no replacement at this point. The closest we got was adding some support for using a Context, with a rather obtuse API (which is now part of the footgunnery). There's al…

For me, the v2 re-writes, as well as the "x" semi-official repo are a major strength. They tell me there is a trustworthy team working on this stuff, but obviously not everything will always be as great as you might want, but the floor is rising.

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

#843

Post by lokar »

Groxx wrote: post #831
hu3 wrote: post #826

Earlier quoted context omitted.

This looks like an ad for batteries included to me. Libraries also don't get it right the first time so they increment minor and major versions. Then why is it not okay for built-in standard libraries to version their functionality also? Just like Go did with JSON? The benefits are worth it judging by how ubiquitous Go, Java and .NET are. I'd rather leverage billions of support paid by the likes of Google, Oracle and…

Third party libraries have been avoiding those json footguns (and significantly improving performance) for well over a decade before stdlib got it. Same with logging. And it's looking like it will be over two decades for an even slightly reasonable http client. Stuff outside stdlib can, and almost always does, improve at an incomparably faster rate.

And I think the Go people seem to do a fairly good job of picking out the best and most universal ideas from these outside efforts and folding them in.

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

#844

Post by robshippr »

Three hours between the malicious publish and npm pulling the versions. If your CI ran an install during that window, this went straight to prod. Most teams I've worked with still have loose version ranges somewhere in their dependency tree even if they think they've locked everything down.

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

#845

Post by 12_throw_away »

jcgl wrote: post #574
tliltocatl wrote: post #539

Earlier quoted context omitted.

I agree that dependencies are a liability, but, sadly, "batteries included" didn't work out for Python in practice (i. e. how do I even live without numpy? No, array aren't enough).

To the extend that Python is indeed "batteries included," that seems true. But just how "batteries included" is it? I'd argue that its batteries are pretty limited. Exhibit A: everybody uses the third-party requests instead of the stdlib urllib . Exhibit B: http.server isn't a production-ready webserver, so people use Flask or something beefier. I'd contrast Python with Go, which has an amazing stdlib for the domains…

> http.server isn't a production-ready webserver, so people use Flask [...]

Nit, but relevant nit: Flask is also not a production-grade webserver. You could say it is also missing batteries ... and those batteries are often missing batteries too. Which is why you don't deploy flask, you deploy flask on top of gunicorn on top of nginx. It's missing batteries all the way down (or at least 3 levels down).

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

#846

Post by lokar »

Yokohiii wrote: post #827
Groxx wrote: post #801

Earlier quoted context omitted.

Largely, yes. But also everyone sane avoids the built-in http client in any production setting because it has rather severe footguns and complicated (and limited) ability to control it. It can't be fixed in-place due to its API design... and there is no replacement at this point. The closest we got was adding some support for using a Context, with a rather obtuse API (which is now part of the footgunnery). There's al…

Another downside of a large stdlib, is that it can be very confusing. Took my a while how unicode is supposed to work in go, as you have to track down throughout the APIs what are the right things to use. Which is even more annoying because the support is strictly binary and buried everywhere without being super explicit or discoverable.

I'm not sure I understand. Why would a standard library, a collection of what would otherwise be a bunch of independent libraries, bundled together, be more confusing than the same (or probably more) independent libraries published on their own?

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

#847

Post by staticassertion »

erikerikson wrote: post #830
staticassertion wrote: post #825

Earlier quoted context omitted.

It's not much better than nothing. It basically solves "I reused my password across sites" exclusively, that's it. If you're going to go through the effort of TOTP, it seems odd that you wouldn't just use a unique password. If you use a unique password it's questionable if it adds any value at all. Perhaps in very niche situations like "password authentication is itself vulnerable due to a timing attack/ bug" or some…

I disagree. I use a password manager and systemically use long random passwords. An attacker would need to compromise my password manager, phish me, wrench me, or compromise the site the credential is associated with to get that. Using local only TOTP (no cloud storage or portability for me, by choice) they would have to additionally phish me, wrench me, compromise my phone, or compromise my physical security to get…

I'm confused. All an attacker has to do is phish you to get your password and TOTP.

TOTP would cover cases like a compromised password manager or a reused password. That's it, right?

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

#848

Post by WorldMaker »

cyco130 wrote: post #459
afavour wrote: post #370

Earlier quoted context omitted.

Irony is that Node has no need for Axios, native fetch support has been there for years, so in terms of network requests it is batteries included.

I'm not sure fetch is a good server-side API. The typical fetch-based code snippet `fetch(API_URL).then(r => r.json())` has no response body size limit and can potentially bring down a server due to memory exhaustion if the endpoint at API_URL malfunctions for some reason. Fine in the browser but to me it should be a no-no on the server.

You can pass to `fetch` an `AbortSignal` like `AbortSignal.timeout(5000)` as a simple and easy guard.

If you also want to guard on size, iterating the `response.body` stream with for/await/of and adding a counter that can `abort()` a manual `AbortSignal` is relatively straightforward, though sounds complicated. You can even do that as a custom `ReadableStream` implementation so that you can wrap it back into `Response` and still use the `response.json()` shortcut. I'm surprised I'm not seeing a standard implementation of that, but it also looks straightforward from MDN documentation [1].

[1] https://developer.mozilla.org/en-US/docs/Web/API/Streams_API...

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

#849

Post by erikerikson »

staticassertion wrote: post #847
erikerikson wrote: post #830

Earlier quoted context omitted.

I disagree. I use a password manager and systemically use long random passwords. An attacker would need to compromise my password manager, phish me, wrench me, or compromise the site the credential is associated with to get that. Using local only TOTP (no cloud storage or portability for me, by choice) they would have to additionally phish me, wrench me, compromise my phone, or compromise my physical security to get…

I'm confused. All an attacker has to do is phish you to get your password and TOTP. TOTP would cover cases like a compromised password manager or a reused password. That's it, right?

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.

Maybe you can be more specific about the attack flow you are imagining and how it will work technically to bypass my controls.

To answer your question, no and I provided details. It literally provides a second, non portable factor with a different vulnerability surface.

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

#850

Post by melroy89 »

postalcoder wrote: post #26

PSA: npm/bun/pnpm/uv now all support setting a minimum release age for packages. I also have `ignore-scripts=true` in my ~/.npmrc. Based on the analysis, that alone would have mitigated the vulnerability. bun and pnpm do not execute lifecycle scripts by default. Here's how to set global configs to set min release age to 7 days: ~/.config/uv/uv.toml exclude-newer = "7 days" ~/.npmrc min-release-age=7 # days ignore-scr…

`~/Library/Preferences/pnpm/rc` reads like is MacOS.. I'm using Linux...?
Post reply on HN