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

401–410 of 894 posts

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

#401

Post by PunchyHamster »

mike_hearn wrote: post #229
semi-extrinsic wrote: post #181

Earlier quoted context omitted.

We run everything NPM related inside Apple containers, and are looking to do the same with Python and Rust soon. Bwrap on Linux does the same. I like to think of it like working with dangerous chemicals in the lab. Back in the days, people were sloppy and eventually got cancer. Then dangers were recognized and PPE was developed and became a requirement. We are now at the stage in software development where we are beg…

The problem is that package managers are a distraction. You have to sandbox everything or else it doesn't work. These attacks use post-install hooks for convenience but nothing would have stopped them patching axios itself and just waiting for devs to run the app on their local workstation. So you end up needing to develop in a fully sandboxed environment.

Yeah the whole rush on "post-run hooks bad" isn't really adding all that much to security.

Like congratulations, your dev was compromised whole 10 minutes later after he ran code.

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

#402

Post by crimsonnoodle58 »

Setting min-release age to 7 days is great, but the only true way to protect from supply chain attacks is restricting network access.

This needs to be done (as we've seen from these recent attacks) in your devenv, ci/cd and prod environments. Not one, or two, but all of these environments.

The easiest way is via using something like kubernetes network policies + a squid proxy to allow limited trusted domains through, and those domains must not be publicly controllable by attackers. ie. github.com is not safe to allow, but raw.githubusercontent.com would be as it doesn't allow data to be submitted to it.

Network firewalls that perform SSL interception and restrict DNS queries are an option also, though more complicated or expensive than the above.

This stops both DNS exfil and HTTP exfil. For your devenv, software like Little Snitch may protect your from these (I'm not 100% on DNS exfil here though). Otherwise run your devenv (ie vscode) as a web server, or containerised + vnc, a VM, etc, with the same restrictions.

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

#403

Post by PunchyHamster »

charcircuit wrote: post #310
hu3 wrote: post #306

Earlier quoted context omitted.

Linux is not making anything less secure than other OSs. In fact it even gives the user more security tools. So I fail to reason on you singling out Linux here.

Take for example iOS and Android. All apps are sandboxed by default. You can't make a program that just steals all of your credentials like you can on desktop Linux. Having security tools means nothing if they aren't being used.

Android is running Linux...

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

#405

Post by PunchyHamster »

waterTanuki wrote: post #249
slopinthebag wrote: post #105

Earlier quoted context omitted.

Come on dude. The issue is the frequency and magnitude of these attacks. Log4Shell was also not a supply chain attack. I looked at the Rust one for example, which is literally just a malicious crate someone uploaded with a similar name as a popular one: > The crate had less than 500 downloads since its first release on 2022-03-25, and no crates on the crates.io registry depended on it. Compared to Axios, which gets 8…

What exactly do you think the argument is? The issues have everything to do with npm as a platform and nothing with JS as a language. You can use JS without npm. Saying you'll escape supply chain attacks by not using JS is like saying you'll be saved from an car crash with a parachute.

Well, this particular case could be wholly avoided if it didn't take 2 decades to get competent HTTP(S) client into core language

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

#406

Post by bbkane »

junon wrote: post #262
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…

This is a rather superlative and tunnel vision, "everything is a nail because I'm a hammer" approach. The truth is this is an exceedingly difficult problem nobody has adequately solved yet.

I think the AI tooling is, if not completely solving sandboxing, at least making the default much better by asking you every time they want to do something and providing files to auto-approve certain actions.

Package managers should do the same thing

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

#407

Post by bbkane »

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)

Go is well known for its large and high quality std lib

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

#408

Post by inopinatus »

ghurtado wrote: post #210
gib444 wrote: post #140

Earlier quoted context omitted.

OP should be glad a new time unit wasn't invented

If we're taking suggestions, I'd like to propose "parsec" (not to be confused with the unit of distance of the same name) That way Han Solo can make sense in the infamous quote. EDIT: even Gemini gets this wrong: > In Star Wars, a parsec is a unit of distance, not time, representing approximately 3.26 light-years

It was already fine, because it’s a metric defined on a submanifold of relativistic spacetime.

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

#409

Post by n_e »

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

I haven't checked, but it would be surprising that the min-release-age applies to npm audit and equivalent commands

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

#410

Post by bbkane »

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…

Love these ideas!
Post reply on HN