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

621–630 of 894 posts

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

#621

Post by myhf »

wongarsu wrote: post #319
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.

Seconds are also unambiguous. Depending on your chosen definition, "X days" may or may not be influenced by leap seconds and DST changes. I doubt anyone cares about an hour more or less in this context. But if you want multiple implementations to agree talking about seconds on a monotonic timer is a lot simpler

exploiting the ambiguity in date formats by releasing a package during a leap second

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

#623

Post by croemer »

flerchin wrote: post #622

Ok it's bad, but our npm projects are pinned in the package-lock.json, which I imagine most would be? So who would pull this besides security scanners?

`npm install` might be enough to pull it, unless you pin down to the patch?

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

#624

Post by ezekg »

socketcluster wrote: post #616

I've been advocating to minimize the number of dependencies for some time now. Once you've maintained an open source project for several years, you start to understand the true cost of dependencies and you actually start to pay attention to the people behind the libraries. Popularity doesn't necessarily mean reliable or trustworthy or secure.

Agree. This is one of the major takeaways I've had from writing Go over the years -- which is even a Go proverb [0], "a little copying is better than a little dependency." Fortunately, LLMs make writing your own implementations of little dependencies super easy too.

[0]: https://go-proverbs.github.io/

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

#625

Post by diarrhea »

paulddraper wrote: post #611
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…

Everyone has forgotten standard ISO 8601 durations and invented their own syntax.

uv supports it, https://docs.astral.sh/uv/reference/settings/#exclude-newer

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

#626

Post by myhf »

berkes wrote: post #220
friendzis wrote: post #189

Earlier quoted context omitted.

Workdays! Think about it, if you set the delay in regular days/seconds the updated dependency can get pulled in on a weekend with only someone maybe on-call. (Hope your timezones and tzdata correctly identifies Easter bank holiday as non-workdays)

> Workdays! This is java script , not Java. In JavaScript something entirely new would be invented, to solve a problem that has long been solved and is documented in 20+ year old books on common design patterns. So we can all copy-paste `{ or: [{ days: 42, months: 2, hours: "DEFAULT", minutes: "IGNORE", seconds: null, timezone: "defer-by-ip" }, { timestamp: 17749453211*1000, unit: "ms"}]` without any clue as to what…

There's an extra digit in your timestamp.

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

#627

Post by moebrowne »

erikerikson wrote: post #499
staticassertion wrote: post #483

Earlier quoted context omitted.

Yeah, NPM should be enforcing 2FA and likely phishing resistant 2FA for some packages/ this should be a real control, issuing public audit events for email address changes, and publish events should include information how it was published (trusted publishing, manual publish, etc).

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

TOTP isn't phishing resistant

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

#628

Post by binsquare »

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…

yep!

This is exactly the world I'm working towards with packaging tooling with a virtual machine i.e. electron but with virtual machines instead so the isolation aspect comes by default.

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

#629

Post by augusto-moura »

nailer wrote: post #570
augusto-moura wrote: post #476

Earlier quoted context omitted.

Hm, I don't think axios would do much better here. `fetch` is the official replacement for axios. If both are flawed that's another topic

> `fetch` is the official replacement for axios. No. Axios is still maintained. They have not deprecated the project in favor of fetch.

I'm not saying that axios is unmaintained, I'm saying that if you want something like axios from the standard lib, fetch is the closest thing you get to official

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

#630

Post by [deleted] »

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…

[deleted]
Post reply on HN