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

631–640 of 894 posts

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

#631

Post by [deleted] »

afavour wrote: post #370
bob1029 wrote: post #241

"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…

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.

[deleted]

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

#632

Post by zadikian »

afavour wrote: post #370
bob1029 wrote: post #241

"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…

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.

Node fetch is relatively new. Wasn't marked stable until 2023, though I've used it since like 2018.

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

#633

Post by squeaky-clean »

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…

SQLite had 6 CVE's last year. FreeType had an RCE bug published last year. libcurl's last CVE reported was 2 weeks ago. Libpng had 4 vulnerabilities published this year....

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

#634

Post by matijs »

dt3ft wrote: post #592
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…

And when you actually need a super hot fix for a 0-day, you will need to revert this and keep it that way for some time to then go back to minimum age. While this works, we stillneed a permanent solution which requires a sort of vetting process, rather than blindly letting everything through.

pnpm since v10.19.0 allows excluding specific dependencies from minReleaseAge by version.

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

#635

Post by brabel »

user34283 wrote: post #511
po1nt wrote: post #303

Earlier quoted context omitted.

That would likely mean same amount of people get the vulnerability, just 7 days later.

The compromised packages were removed from the registry within hours.

Because everyone got updates immediately. If the default was 7 days, almost no one would get updates immediately but after 7 days, and now someone only finds about after 7 days. Unless there is a poor soul checking packages as they are published that can alert the registry before 7 days pass, though I imagine very few do that and hence a dedicated attacker could influence them to not look too hard.

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

#636

Post by robrain »

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…

mise has an option as well (note the caveats though):

https://mise.jdx.dev/configuration/settings.html#install_bef...

And homebrew has discussed it, kinda sorta:

https://github.com/Homebrew/brew/issues/21129

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

#637

Post by reactordev »

hiccuphippo wrote: post #419
zdragnar wrote: post #97

Earlier quoted context omitted.

There are pretty much two usage patterns that come up all the time: 1- automatically add bearer tokens to requests rather than manually specifying them every single time 2- automatically dispatch some event or function when a 401 response is returned to clear the stale user session and return them to a login page. There's no reason to repeat this logic in every single place you make an API call. Likewise, every respo…

One more use case for Axios is it automatically follows redirects, forwarding headers, and more importantly, omiting or rewriting the headers that shouldn't be forwarded for security reasons.

fetch automatically follows redirects, fetch will forward your headers, omitting or rewriting headers is how security breaks… now a scraper got through because it’s masquerading as Chrome.

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

#638

Post by staticassertion »

mayhemducks wrote: post #614
erikerikson wrote: post #499

Earlier quoted context omitted.

Instead they took away TOTP as a factor. Scaling security with the popularity of a repo does seem like a good idea.

Are there downsides to doing this? This was my first thought - though I also recognize that first thoughts are often naive.

You don't want "project had X users so it's less safe" to suddenly transition into "now this software has X*10 users so it has to change things", it's disruptive.

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

#639

Post by x0x0 »

PunchyHamster wrote: post #390
zelphirkalt wrote: post #294

Earlier quoted context omitted.

I actually think it is not too bad a design, because seconds are the SI base unit for time. Putting something like "x days" requires additional parsing steps and therefore complexity in the implementation. Either knowing or calculating how many seconds there are in a day can be expected of anyone touching a project or configuration at this level of detail.

that kind of complexity is always worth it. Every single time. It's user time that you're saving and it also makes config clearer for readers and cuts out on "too many/little zeroes on accident" errors It's just library for handling time that 98% of the time your app will be using for something else.

I find it best when I need a calculator to understand security settings. 604800 here we come

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

#640

Post by mladen5 »

staticassertion wrote: post #387
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…

They're not a failed experiment. No one has ever "experimented" by making a safe package manager for their new language. And it is not that insane to do so. Very basic things will get you very far: 1. Packages should carry a manifest that declares what they do at build time, just like Chrome extensions do. This manifest would then be used to configure its build environment. 2. Publishers to official registries should…

I don't understand commercial aspect of large OSS like package managers but i was wondering for years why this was missing from npm. I think typosquatting was handled by npm last year but only after some popular miss typed packages started stealing developer creds.
Post reply on HN