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

581–590 of 894 posts

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

#581

Post by robertfw »

CGamesPlay wrote: post #492
cowl wrote: post #277

Earlier quoted context omitted.

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

The packages that are actually compromised are yanked, but I assume you're talking about a scenario more like log4shell. In that case, you can just disable the config to install the update, then re-enable in 7 days. Given that compromised packages are uploaded all the time and zero-day vulnerabilities are comparatively less common, I'd say it's the right call.

`uv` has per-package overrides, I imagine there may be similar in other managers

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

#582

Post by majorbugger »

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

Because fat std is rigid, impractical, and annoying.

Yeah, it's annoying to have good support for dates in Java since 2014, instead of only getting it now like in JS.

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

#583

Post by tonymet »

1/5 of your CLI and 1/3 of your gui apps are npm based. Each one has 400+ dependencies , none notable enough to go viral when they are breached. And who knows what other packages are currently compromised. We all have 30+ node_modules on our disks, and 2/3 of them were shipped by outside vendors , packaged in an archive.

“I’m smart I use fetch instead of axios”. “I pin my versions” – sure but certainly one of your npx or Electron apps uses axios or another less notably compromised package.

Let’s

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

#584

Post by estebank »

physicsguy wrote: post #221
pie_flavor wrote: post #182

Earlier quoted context omitted.

Rust libraries are infrequently used outside of Rust because if you have the option, you'd just use Rust, not the ancient featureless language intrinsically responsible for 70% of all security issues. C libraries are infrequently used in Rust outside of system libc, for the same reason; I go and toggle the reqwest switch to use rustls every time, because OpenSSL is horrendous . This is also why you say 'rarely' inste…

Rust is terrible for pulling in hundreds of dependencies though. Add tokio as a dependency and you'll get well over 100 packages added to your project.

Even side stepping that tokio no longer pulls multiple packages, it used to be split into multiple packages, in the same way that KDE in Rust would be hundreds of packages.

Rust projects tend to take their project and split it into many smaller packages, for ease of development, faster compiles through parallelization, ensuring proper splitting of concerns, and allowing code reuse by others. But the packages are equivalent to a single big package. The people that write it are the same. They get developed in tandem and published at the same time. You can take a look at the del tree for ripgrep, and the split of different parts of that app allows me to reuse the regex engine without dealing with APIs that only make sense in the context of a CLI app or pulling in code I won't ever use (which might be hiding an exploit too).

Counting 100 100 line long crates all by the same authors as inherently more dangerous than 1 10000 line long crate makes no sense to me.

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

#585

Post by MBCook »

afavour wrote: post #370
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.

Browsers too.

It’s not needed anymore.

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

#587

Post by dec0dedab0de »

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 systems are still susceptible to supply chain attacks, they just move slower so it’s not as attractive of a target.

I think packages of a certain size need to be held to higher standards by the repositories. Multiple users should have to approve changes. Maybe enforced scans (though with trivy’s recent compromise that wont be likely any time soon)

Basically anything besides lone developer can decide to send something out on a whim that will run on millions of machines.

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

#589

Post by bbkane »

nailer wrote: post #572
bbkane wrote: post #406

Earlier quoted context omitted.

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

> at least making the default much better by asking you every time they want to do something Really? I thought 'asking you every time they want to do something' was called 'security fatigue' and generally considered to be a bad thing. Yes you can concatenate files in the current project, Claude.

Yes it has to be combined with a robust way to allowlist actions you trust

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

#590

Post by _alternator_ »

nightpool wrote: post #514
woodruffw wrote: post #500

Earlier quoted context omitted.

Could you explain what you mean re: ambiguity? I understand why “calendar units” like months are ambiguous, but minutes, hours, days, and weeks all have fixed durations (which is why APIs like Python’s `timedelta` allows them).

The minute between December 31, 2016 23:59 and January 1st 2017 is 61 seconds, not 60 seconds. The hour that contains that minute is 3601 seconds, the day that contains that hour is 43201 seconds, etc. If you assume a fixed duration and simply multiply by 43200, your math will be wrong compared to the rest of the world. Daylight savings time makes a day take 23 hours or 25 hours. That makes a week take 7254000 second…

Leap seconds are their own nightmare. UNIX time ignores them, btw, so that the unix epoch is 86400*number of days since 1/1/1970 + number of seconds since midnight. The behavior at the instance of a leap second is undefined.
Post reply on HN