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

351–360 of 894 posts

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

#351

Post by wolvesechoes »

someguyornotidk wrote: post #300
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, mo…

It is, therefore I have stated I avoid any dependencies while writing Rust, unless they are self-contained. And I said I am glad I don't do web, so I don't have need for HTTP implementations.

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

#352

Post by layer8 »

mort96 wrote: post #176
layer8 wrote: post #149

Earlier quoted context omitted.

Or require the value to specify a unit.

At that point, you're making all your configuration fields strings and adding another parsing step after the json/toml/yaml parser is done with it. That's not ideal either; either you write a bunch of parsing code (not terribly difficult but not something I wanna do when I can just not), or you use some time library to parse a duration string, in which case the programming language and time library you happen to use…

Another parsing step is the common case. Few parameters represent untyped strings where all characters and values are valid. For numbers as well, you often have a limited admissible range that you have to validate for. In the present case, you wouldn’t allow negative numbers, and maybe wouldn’t allow fractional numbers. Checking for a valid number isn’t inherently different from checking for a regex match. A number plus unit suffix is a straightforward regex.

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

#353

Post by progmetaldev »

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 more to do with the standard library being so barren of common application needs, and looking for a solution that the community has gotten behind. Axios has been a common dependency in many codebases, because it is a solid solution that many have already used. Every developer could try building all the libraries that they would reach for themselves, but then each company has now taken on the task of ensuring their own (much larger) codebase is free from security issues, on top of taking care of their own issues and bugs.

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

#354

Post by hresvelgr »

PedroBatista wrote: post #287
hresvelgr wrote: post #211

Earlier quoted context omitted.

> Package managers are now basically a requirement for language adoption. Doing it manually is not a solution, in an automated world. Absolute nonsense. What does automated world even mean? Even if one could infer reasonably, it's no justification. Appealing to "the real world" in lieu of any further consideration is exactly the kind of mindlessness that has led to the present state of affairs. Automation of dependen…

Relax, while mentioning the real world without any criticism for the soundness of the solution is absolute nonsense, some would say idiotic, thinking only in the absolute best solution given your narrow world view is not any better.

While I agree that my view is narrow, the "best solution" in question is what we used to do, and it was fine. There are still many places that manually manage dependencies. Fundamentally automatic software versioning is an under-developed area in need of attention, and technologies like semantic versioning which are ubiquitous are closer to suggestions, and not true indicators of breaking changes. My personal view is that fully automatic dependency version management is an ongoing experiment and should be treated as such.

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

#355

Post by rk06 »

> This creates a secondary deception layer. After infection, running npm list in the project directory will report plain-crypto-js@4.2.0 — because npm list reads the version field from the installed package.json, which now says 4.2.0. An incident responder checking installed packages would see a version number that does not match the malicious 4.2.1 version they were told to look for, potentially leading them to conclude the system was not compromised.

WTF!!!! gaslighting your victims into believing they are not victims. the ingenuity of this is truly mindblowing. I am shocked at such thing is even allowed. like packages should not be able to modify their contents while they are being instaleld.

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

#356

Post by stratos123 »

mixedbit wrote: post #159
himata4113 wrote: post #30

I recommend everyone to use bwrap if you're on linux and alias all package managers / anything that has post build logic with it. I have bwrap configured to override: npm, pip, cargo, mvn, gradle, everything you can think of and I only give it the access it needs, strip anything that is useless to it anyway, deny dbus, sockets, everything. SSH is forwarded via socket (ssh-add). This limits the blast radius to your CW…

Check also https://github.com/wrr/drop which is a higher-level tool than bwrap. It allows you to make such isolated sandboxes with minimal configuration.

This looks nice but I wouldn't trust a very fresh tool to do security correctly.

As a higher-level alternative to bwrap, I sometimes use `flatpak run --filesystem=$PWD --command=bash org.freedesktop.Platform`. This is kind of an abuse of flatpaks but works just fine to make a sandbox. And unlike bwrap, it has sane defaults (no extra permissions, not even network, though it does allow xdg-desktop-portal).

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

#357

Post by [deleted] »

christophilus wrote: post #299
indy wrote: post #199

Earlier quoted context omitted.

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.

[deleted]

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

#358

Post by rvz »

layer8 wrote: post #157
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…

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

It is because it has the lowest barrier to entry with no quality control. Ever.

This is what happens when there is no barrier to entry and it includes everyone who has no idea what they are doing in charge of the NPM community.

When you see a single package having +25 dependencies, that is a bad practice and increases the risk of supply chain attacks.

Most of them don't even pin their dependencies and I called this out just yesterday on OneCLI. [0]

It just happens that NPM is the worst out of all of the rest of the ecosystems due to the above.

[0] https://news.ycombinator.com/item?id=47577183

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

#359

Post by pyjarrett »

troad wrote: post #350
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…

What are some examples of batteries-included languages that folk around here really feel productive in and/or love? What makes them so great, in your opinion? (Leaving aside thoughts on language syntax, compile times, tooling etc - just interested in people's experiences with / thoughts on healthy stdlibs)

These are the big ones I use, specifically because of the standard libraries:

Python (decent standard library) - It's pretty much everywhere. There's so many hidden gems in that standard library (difflib, argparse, shlex, subprocess, cmd)

C#/F# (.NET)

C# feels so productive because of how much is available in .NET Core, and F# gets to tag along and get it all for free too. With C# you can compile executables down to bundle the runtime and strip it down so your executables are in the 15 MiB range. If you have dotnet installed, you can run F# as scripts.

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

#360

Post by wolvesechoes »

hypeatei wrote: post #311
a-french-anon wrote: post #258

Earlier quoted context omitted.

Why wouldn't the "fat std" thing work? Yes it's hard to design properly, both in scope and actual design (especially for an unstandardized language still moving fast), but throwing the towel and punting the problem to the "free market" of uncurated public repos is even worse. It's what we call in France "la fête du slip". PS: that's one reason I try to use git submodules in my Common Lisp projects instead of QuickLis…

Fat std library mistakes/warts would likely result in third party packages being used anyway.

So it provides another option, and in worst case it doesn't make situation worse than it is right now?

Yeah, pretty bad idea.

Post reply on HN