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

521–530 of 894 posts

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

#521

Post by jadar »

Tazerenix wrote: post #34
rybosome wrote: post #17

Earlier quoted context omitted.

> it’s got me nervous to use Python or Node.js these days My feelings precisely. Min package age (supported in uv and all JS package managers) is nice but I still feel extremely hesitant to upgrade my deps or start a new project at the moment. I don’t think this is going to stabilize any time soon, so figuring out how to handle potentially compromised deps is something we will all need to think about.

NPM only gained minimum package age in February of this year , and still doesn't support package exclusions for internal packages. https://github.com/npm/cli/pull/8965 https://github.com/npm/cli/issues/8994 Its good that that they finally got there but.... I would be avoiding npm itself on principle in the JS ecosystem. Use a package manager that has a history of actually caring about these issues in a timely manner.

It almost doesn't matter, because you can get pwned by a transitive dependency. If someone doesn't have the same scruples as you have, you're still at risk.

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

#522

Post by roflcopter69 »

6thbit wrote: post #502

I don’t buy the “wait 7 days” being thrown around as a guard. Wouldn’t that just encourage the bad actors to delay the activation of their payloads a few days or even remotely activated on a switch?

Of course the "wait 7 days" are not a silver bullet, but it gives automated scanners plenty of time to do their work. Those automated scanners surely catch this `eval(base64.decode("..."))` stuff that some of those attacks used so in my book this dependency cooldown is a net win. I guess the skilled malicious actors will then up their game but I think it's okay to kick off an arms race between them and the security scanners in the dependency world.

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

#523

Post by woodruffw »

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…

That’s what I mean by calendar units. These aren’t issues if you don’t try to apply durations to the “real” calendar.

(This is all in the context of cooldowns, where I’m not convinced the there’s any real ambiguity risk by allowing the user to specify a duration in day or hour units rather than seconds. In that context a day is exactly 24 hours, regardless of what your local savings time rules are.)

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

#524

Post by pwillia7 »

notpushkin wrote: post #107
friendzis wrote: post #98

Earlier quoted context omitted.

> (Side note, it's wild that npm, bun, and pnpm have all decided to use different time units for this configuration.) First day with javascript?

You mean first 86,400 seconds?

wait what if we start on a day DST starts or ends????

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

#525

Post by jadar »

erikerikson wrote: post #519
arcfour wrote: post #75

Earlier quoted context omitted.

PNPM makes you approve postinstall scripts instead of running them by default, which helps a lot. Whenever I see a prompt to run a postinstall script, unless I know the package normally has one & what it does, I go look it up before approving it. (Of course I could still get bitten if one of the packages I trust has its postinstall script replaced.)

How does this stance work with your CICD?

I suppose you would have to commit your node_modules, or otherwise cache your setup so that all prerequesite modules are built and ready to install without running post-install scripts?

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

#526

Post by s1mn »

superjan wrote: post #88
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…

About the use of different units: next time you choose a property name in a config file, include the unit in the name. So not “timeout” but “timeoutMinutes”.

Yes!! This goes for any time you declare a time interval variable. The number of times I've seen code changes with a comment like "Turns out the delay arg to function foo is in milliseconds, not seconds".

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

#527

Post by rc_mob »

nicce wrote: post #469
xinayder wrote: post #463

Very detailed and props to the security researchers, but the blog post has several indicators that it was written by AI, to which point I suspect their malware analysis was also done by a LLM. I just wish it had more human interaction rather than have a GenAI spit out the blog post. It's very repetitive and includes several EM dashes.

It is harder and harder to trust any blog post anymore, the more AI there is. I used to read blog posts because of the personality and the precision level. Now both have been taken away.

Yeah, 98% of blog posts only exist for SEO purposes and so most of that is of course written by LLM

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

#528

Post by raincole »

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…

Different programmers have very different ideas about what is "all the functionality you typically need."

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

#530

Post by fc417fc802 »

dspillett wrote: post #490
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.

Probably went with the simplest implementation, if starting from the current “seconds since epoch” value. Let the user do any calculations needed to translate three days into that measurement. It also efficiently annoys the most people at once: those what want hours will complain if they set it to days, thought that want days will complain if hours are used. By using minutes or seconds you can wind up both segments w…

The one true unit of time is hexadecimal encoded nanoseconds since the unix epoch. (I'm only half joking because I actually have authored code that used that before.)
Post reply on HN