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

361–370 of 894 posts

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

#361

Post by skydhash »

victorbjorklund wrote: post #278
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…

I think you can do copy paste in most languages. But it will be a pain to update when there are improvements / security fixes. You got a project with 1-2 depencies? Sure. But if you need to bring in 100 different libs (because you bring in 10 libs which in turn brings in 10 libs) good luck.

> But if you need to bring in 100 different libs (because you bring in 10 libs which in turn brings in 10 libs

So don’t?

With manual deps management, everyone soon gravitates to a core set of deps. And libraries developer tends to reduce their deps needs, That’s why you see most C libraries deals with file formats, protocols, and broad concerns. Smaller algorithms can be shared with gists and blog articles.

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

#362

Post by inbx0 »

strogonoff wrote: post #245
inbx0 wrote: post #209

Earlier quoted context omitted.

> Run Yarn in zero-installs mode (or equivalent for your package manager). Every new or changed dependency gets checked in. Idk, lockfiles provide almost as good protection without putting the binaries in git. At least with `--frozen-lockfile` option.

Zero-installs mode does not replace the lockfile. Your lockfile is still the source of truth regarding integrity hashes. However, it’s an extra line of defence against 1) your registry being down (preventing you from pushing a security hotfix when you find out another package compromised your product), 2) package unpublishing attacks (your install step fails or asks you to pick a replacement version, what do you do a…

Number 1 would only be a win for zero-installs if it happened that registry was up when you made the security hotfix, since you'd need to install the depdencency the first time to get it in VC, but then suddenly down when doing a deploy. Seems like a highly unlikely scenario to me. Also, cases where npm CVEs must be patched with such urgency or bad things will happen are luckily very rare, in my experience.

Most npm CVEs are stuff like DDoS vulnerabilities, and you should have mitigations for those in place for at the infra-level anyway (e.g. request timeouts, rate limits, etc), or you are pretty much guaranteed to be cooked sooner or later anyway. The really dangerous stuff like arbitrary command execution from a library that takes end user input is much much more rare. The most recent big one I remember is React2shell.

Number 2 hasn't been much of an issue for a long time. npm doesn't allow unpublishing package after 72 hours (apart from under certain rare conditions).

Don't know about number 3. Would feel to me that if you have something running that can modify lockfile, they can probably also modify the chekced-in tars.

I can see how zero-installs are useful under some specific constraints where you want to minimize dependencies to external services, e.g. when your CI runs under strict firewalls. But for most, nah, not worth it.

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

#363

Post by rolux »

zelphirkalt wrote: post #294
x0x0 wrote: post #158

Earlier quoted context omitted.

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.

> seconds are the SI base unit for time

True. But seconds are not the base unit for package compromises coming to light. The appropriate unit for that is almost certainly days.

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

#364

Post by gedy »

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…

> "Batteries included" ecosystems are the only persistent solution to the package manager problem.

The irony in this case is that axios is not really needed now given that fetch is part of the JS std lib.

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

#365

Post by skydhash »

fluxist wrote: post #215

A command to recursively check for the compromised axios package version: find / -path '*/node_modules/axios/package.json' -type f 2>/dev/null | while read -l f; set -l v (grep -oP '"version"\s*:\s\*"\K(1\.14\.1|0\.30\.4)' $f 2>/dev/null); if test -n "$v"; printf '\a\n\033[1;31m FOUND v%s\033[0m \033[1;33m%s\033[0m\n' $v (string replace '/package.json' '' -- $f); else; printf '\r\033[2m scanning: %s\033[K\033[0m' (st…

What’s with all those escapes codes?

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

#366

Post by silverwind »

woeirua wrote: post #52

Supply chain attacks are so scary that I think most companies are going to use agents to hard fork their own versions of a lot of these core libraries instead. It wasn’t practical before. It’s definitely much more doable today.

Even better would be to not use so many libs. Most use cases will do fine with native `fetch`.

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

#367

Post by silverwind »

Levitating wrote: post #282
woeirua wrote: post #52

Supply chain attacks are so scary that I think most companies are going to use agents to hard fork their own versions of a lot of these core libraries instead. It wasn’t practical before. It’s definitely much more doable today.

Or just lock to a specific version?

Eventually you will want to update it, every update is a risk.

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

#369

Post by anthk »

Guix saves you from this. You can import NPM packages in a container (not even touching $HOME) and giving you a shell on the spot with just the dependencies and nothing more.

Learn about 'guix import'.

Oh, and you can install Guix on any GNU/Linux distro.

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

#370

Post by afavour »

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.
Post reply on HN