Live data from Hacker News

You too can run malware from NPM (I mean without consequences)

github.com

91–100 of 122 posts

Re: You too can run malware from NPM (I mean without consequences)

#91

Seems like people already forgot about Jia Tan. By the way why doesn't npm have already a system in place to flag sketchy releases where most of the code looks normal and there is a newly added obfuscated code with hexadecimal variable names and array lookups for execution...

Detecting sketchy-looking hex codes should be pretty straightforward, but then I imagine there are ways to make sketchy code non-sketchy, which would be immediately used. I can imagine a big JS function, that pretends to do legit data manip, but in the process creates the payload.

Feels like a basic light weight 3b AI model could easily spot shit like this on commit

Re: You too can run malware from NPM (I mean without consequences)

#92
post #37

Earlier quoted context omitted.

It's within the same process and realm (window) It has a cost, but it's nothing compared to putting every dependency of a large app in a separate iframe/process and figure out a way for them to communicate.

Have you tried to find ways to break it? Plenty of objects in the browser API contain references to things that could be used to defeat the compartmentalization. If one were to enumerate all properties on window and document, how many would be objects with a reference back to window, document or some API not on the allowed list?

I maintain ses, the compartment primitive LavaMoat relies on. The ses shim for hardenedjs.org creates compartments that deny guest code the ability to inspect the true global object or lexically reference any of its properties. By default, each compartment only sees the transitively frozen intrinsics like Array and Object, and no way to reach the genuine evaluators. The compartment traps the module loader as well, so you can only import modules that are explicitly injected. That leaves a lot of room for the platform to make mistakes and endow the compartment with gadgets, but also gives us a place to stand to mount a defense that is not otherwise prohibitively expensive.

Re: You too can run malware from NPM (I mean without consequences)

#94

Earlier quoted context omitted.

If my grandma had wheels she'd be a bike. You don't need to attack the problem from only one angle.

Your grandma is a bike then. The 2fa is going to solve nothing and any attacker worth their salt knows it.

unphishable 2fa would have prevented this specific case tho... what are you talking about?

Re: You too can run malware from NPM (I mean without consequences)

#95
post #5

Earlier quoted context omitted.

I think malware check should be opt-in for package authors, but provide some kind of 'verified' badge to the package. Edit: typo

I always thought this would be the ideal monetization path for NPM; enterprises pay them, NPM only supplies verified package releases, ideally delayed by hours/days after release so that anything that slips through the cracks has a chance to get caught.

That would put them into liability or be a quite worthless agreement taking no responsibility.

Re: You too can run malware from NPM (I mean without consequences)

#96
In July, packages were loading malicious DLLs (on Windows targets) [1]. It doesn't appear Lavamoat would help in that scenario. Is that right? If so, how do you mitigate this? Run everything in a container?

[1] https://www.crowdstrike.com/en-us/blog/crowdstrike-falcon-pr...

Re: You too can run malware from NPM (I mean without consequences)

#97

In July, packages were loading malicious DLLs (on Windows targets) [1]. It doesn't appear Lavamoat would help in that scenario. Is that right? If so, how do you mitigate this? Run everything in a container? [1] https://www.crowdstrike.com/en-us/blog/crowdstrike-falcon-pr...

https://gitlab.com/grepular/safernode

Re: You too can run malware from NPM (I mean without consequences)

#98

In July, packages were loading malicious DLLs (on Windows targets) [1]. It doesn't appear Lavamoat would help in that scenario. Is that right? If so, how do you mitigate this? Run everything in a container? [1] https://www.crowdstrike.com/en-us/blog/crowdstrike-falcon-pr...

1. Control lifecycle scripts with @lavamoat/allow-scripts

2. Do local dev with https://github.com/lavamoat/kipuka installed (I'm working on it)

3. If you don't permit the APIs used for loading DLLs they won't load themselves, so runtime protections are valid too. But I recall the DLLs were loaded in lifecycle script.

Re: You too can run malware from NPM (I mean without consequences)

#99
post #36

How does one avoid malware in npm specifically? Makes me not want to use the ecosystem, which isn’t always possible.

'npm install' and 'pip install' can both run scripts on your computer. Both ecosystems have this risk and loose monitoring, so there are days where packages are messed up. I don't think you can avoid malware by picking one over the other.

Re: You too can run malware from NPM (I mean without consequences)

#100

Seems like people already forgot about Jia Tan. By the way why doesn't npm have already a system in place to flag sketchy releases where most of the code looks normal and there is a newly added obfuscated code with hexadecimal variable names and array lookups for execution...

> flag sketchy releases Because the malware writers will keep tweaking the code until it passes that check, just like virus writers submit their viruses to VirusTotal until they are undetected.

its Typical that the Virus Writer will use their own service, there is criminal virustotal-clones that run many AV in VM and return the Results, because virustotal will share all binaries, anything upload in Virustotal will be detteceted shortly if it is not.
Post reply on HN