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

571–580 of 894 posts

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

#571

Post by pianoben »

waterTanuki wrote: post #152
pianoben wrote: post #84

Earlier quoted context omitted.

Log4Shell was hardly a supply-chain attack - just a latent bug in a widely-used library. That can happen anywhere. Maven to this day represents my ideal of package distribution. Immutable versions save so much trouble and I really don't understand why, in the age of left-pad, other people looked at that and said, "nah, I'm good with this."

The semantics are irrelevant. The effect is what's important: Hijacking widely used software to exploit systems. The OC is somehow under the illusion that avoiding JS altogether is a silver bullet for avoiding this. Forest > Trees

The semantics are very relevant, since you presented it as a supply-chain attack. If you call a library vulnerability a supply-chain attack, then your argument has lost coherence.

> The OC is somehow under the illusion...

Avoiding package managers with shitty policies is the silver bullet for this attack vector. I get that it can be useful in the moment to retract published artifacts, or update them in-place, or run some code after your artifact is downloaded, but all of these are false economies in our hostile environment.

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

#572

Post by nailer »

bbkane wrote: post #406
junon wrote: post #262

Earlier quoted context omitted.

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

> 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.

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

#574

Post by jcgl »

tliltocatl wrote: post #539
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…

I agree that dependencies are a liability, but, sadly, "batteries included" didn't work out for Python in practice (i. e. how do I even live without numpy? No, array aren't enough).

To the extend that Python is indeed "batteries included," that seems true. But just how "batteries included" is it? I'd argue that its batteries are pretty limited. Exhibit A: everybody uses the third-party requests instead of the stdlib urllib. Exhibit B: http.server isn't a production-ready webserver, so people use Flask or something beefier.

I'd contrast Python with Go, which has an amazing stdlib for the domains that Go targets. This last part is key--Go has a more focused scope than Python, and that makes it easier for its stdlib to succeed.

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

#575

Post by wongarsu »

woodruffw wrote: post #523
nightpool wrote: post #514

Earlier quoted context omitted.

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.)

"exactly 24 hours" could still be anywhere between 86399 and 86401 seconds, depending on leap seconds. At least if by an hour you mean an interval of 60 minutes, because a minute that contains a leap second will have either 59 or 61 seconds.

You could specify that for the purposes of cooldowns you want "hour" to mean an interval of 3600 seconds. But that you have to specify that should illustrate how ambiguous the concept of an hour is. It's not a useless concept by any means and I far prefer to specify duration in hours and days, but you have to spend a sentence or two on defining which definition of hours and days you are using. Or you don't and just hope nobody cares enough about the exact cooldown duration

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

#576

Post by MetaWhirledPeas »

cozzyd wrote: post #64
XYen0n wrote: post #58

Earlier quoted context omitted.

If everyone avoids using packages released within the last 7 days, malicious code is more likely to remain dormant for 7 days.

that's why people are telling others to use 7 days but using 8 days themselves :)

You don't have to be faster than the bear, you just have to be faster than the other guy.

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

#577

Post by pcblues »

hluska wrote: post #425
berkes wrote: post #320

Earlier quoted context omitted.

... and since it was architectured to allow runtime injection-patching of events before they hit the enterprise-service-bus, everyone using this library must first set fourteen ENV vars in their profile, and provide a /etc/java/springtime/enterprise-workday-handling/parse-event-mismatch.jar.patch. Which should fix the bug for you. You can find the patch files for your OSs by registering at Oracle with a J3EE8.4-Patch…

This isn’t even remotely funny.

I am laughing. I'm not even near the end of this thread.

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

#579

Post by 0xbadcafebee »

We're going to see this more and more and more. And it's not going to stop. Because nobody in the industry will use the simplest, industry-standard security practices. Because they don't feel like it. A software building code is the only thing that'll fix it.

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

#580

Post by cyco130 »

augusto-moura wrote: post #476
cyco130 wrote: post #459

Earlier quoted context omitted.

I'm not sure fetch is a good server-side API. The typical fetch-based code snippet `fetch(API_URL).then(r => r.json())` has no response body size limit and can potentially bring down a server due to memory exhaustion if the endpoint at API_URL malfunctions for some reason. Fine in the browser but to me it should be a no-no on the server.

Hm, I don't think axios would do much better here. `fetch` is the official replacement for axios. If both are flawed that's another topic

Axios has maxContentLength and maxBodyLength options. I would probably go with undici nowadays though (it also has maxResponseSize).
Post reply on HN