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

291–300 of 894 posts

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

#291

Post by ksnssjsjsj »

cowl wrote: post #277
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…

min release age to 7 days about patch releases exposes you to the other side of the coin, you have an open 7 days window on zero-day exploits that might be fixed in a security release

Out of the frying pan and into the frier.....

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

#292

Post by Imustaskforhelp »

mrsmrtss wrote: post #265
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…

Fully agree with this! I think today .NET is probably the most batteries included platform you can get. This means that even if you use third-party libraries, these typically depend only on first-party dependencies, making it much less likely for something shady to sneak in.

To me, I really like Golang's batteries included platform. I am not sure about .NET though

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

#293

Post by torben-friis »

cozzyd wrote: post #139
weird-eye-issue wrote: post #108

Earlier quoted context omitted.

timeoutMs is shorter ;) You guys can't appreciate a bad joke

Megaseconds are about the right timescale anyway

What megaseconds? They clearly meant the Microsoft-defined timeout.

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

#294

Post by zelphirkalt »

x0x0 wrote: post #158
notpushkin wrote: post #107

Earlier quoted context omitted.

You mean first 86,400 seconds?

You have to admire the person who designed the flexibility to have 87239 seconds not be old enough, but 87240 to be fine.

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.

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

#295

Post by christophilus »

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…

Honestly, you can get pretty far with just Bun and a very small number of dependencies. It’s what I love most about Bun. But, I do agree with you generally. .NET is about as good as I’ve ever seen for being batteries included. I just hate the enterprisey culture that always seems to pervade .NET shops.

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

#296

Post by whywhywhywhy »

PhilipRoman wrote: post #164
wps wrote: post #50

Genuinely how are you supposed to make sure that none of the software you have on your system pulls this in? It’s things like this that make me want to swap to Qubes permanently, simply as to not have my password manager in the same context as compiling software ever.

This sounds like satire but isn't - I just make sure the nodejs/npm packages don't exist on my system. I've yet to find a crucial piece of software that requires it. As much as I love that cute utility that turns maps into ascii art, it's not exactly sqlite in terms of usefulness.

Bit ridiculous to dismiss the most popular programming languages packaging repo as silly toys.

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

#297

Post by Ciantic »

Levitating wrote: post #280
Ciantic wrote: post #263

NPM should learn from Linux distribution package managers. Have a branch called testing, and packages stay in testing for few weeks, after which they go to stable. That is how many Linux distributions handle packages. It would have prevented many of these. Advising every user of npm/pnpm to change their settings and set their own cooldown periods is not a real choice.

Not all distributions work with a staging repository, and it's not really intended for this purpose either. Besides there's always a way to immediately push a new version to stable repositories. You have to in order to deal with regressions and security fixes.

I know not all, but Debian/Ubuntu/Fedora does, and while the intended purpose of multi-stage releases is not necessarily security but stability, it still does help up with security too. Because third parties can look and scan the dependencies while they are still not in stable.

Most of the supply chain vulnerabilities that ended up in the NPM would have been mitigated with having mandatory testing / stable branches, of course there needs to be some sort of way to skip the testing but that would be rather rare and cumbersome and audited, like it is in Linux distributions too.

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

#298

Post by Tarraq »

vincnetas wrote: post #161
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…

no no, please we don't want to get back to dragging files to your project to make them work.

And manual FTP uploads, while we're at it.

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

#299

Post by christophilus »

indy wrote: post #199
layer8 wrote: post #157

Earlier quoted context omitted.

For some reason, NPM is the only ecosystem with substantial issues with supply-chain attacks.

The culture within the npm/js community has mainly been one of using the package manager rather than "re-inventing the wheel", as such the blast radius of a compromised package is much greater

It’s not just NPM, though. Every Rails project and every Rust project I’ve seen ended up with massive numbers of dependencies vs what an equivalent project in Go or C# would have needed.

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

#300

Post by someguyornotidk »

wolvesechoes wrote: post #175

I am glad I don't need to touch JS or web dev at all. Now, I tend to use Python, Rust and Julia. With Python I am constantly using few same packages like numpy and matplotlib. With Rust and Julia, I try as much as possible to not use any packages at all, because it always scares me when something that should be pretty simple downloads half of the Internet to my PC. Julia is even worse than Rust in that regard - for e…

Isn't Rust just as susceptible to this issue? For example, how do you deal with Rust's lack of support for HTTP in the standard library? Importing hyper pulls in a couple dozen transitive libraries which exposes you to the exact same kind of threats that compromised axios.

Given how HTTP is now what TCP was during the 90s and almost all modern networked applications needing to communicate in it one way or another, most rust projects come with an inherent security risk.

These days, I score the usability of programming languages by how complete their standard library is. By that measure, Rust and Javascript get an automatic F.

Post reply on HN