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.
You too can run malware from NPM (I mean without consequences)
91–100 of 122 posts
Re: You too can run malware from NPM (I mean without consequences)
#92Earlier 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?
Re: You too can run malware from NPM (I mean without consequences)
#93I think JS should be all source and no packages at all.
Re: You too can run malware from NPM (I mean without consequences)
#94Earlier 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.
Re: You too can run malware from NPM (I mean without consequences)
#95Earlier 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.
Re: You too can run malware from NPM (I mean without consequences)
#96[1] https://www.crowdstrike.com/en-us/blog/crowdstrike-falcon-pr...
Re: You too can run malware from NPM (I mean without consequences)
#97In 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)
#98In 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...
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)
#99How does one avoid malware in npm specifically? Makes me not want to use the ecosystem, which isn’t always possible.
Re: You too can run malware from NPM (I mean without consequences)
#100Seems 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.