Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

111–120 of 122 posts

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

#111

Post by jay_kyburz »

chatmasta wrote: post #109
Izkata wrote: post #107

Earlier quoted context omitted.

Lockfiles use exact hashes, not versions/version ranges. Javascript projects use two files, a package file with version ranges (used when upgrading) and a lockfile with the exact version (used in general when installing in an existing project).

Sure, but a lockfile with a hash doesn’t mean that next time it will fail if it tries to install a version of the package without that hash. If your package.json specifies a semver range then it’ll pull the latest minor or patch version (which is what happened in this case with e.g. duckdb@1.3.3) and ignore any hash differences if the version has changed. Hence why I say you need to go out of your way to specify an e…

I think at some point you would be better off vendoring them in.

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

#112

Post by chatmasta »

jay_kyburz wrote: post #111
chatmasta wrote: post #109

Earlier quoted context omitted.

Sure, but a lockfile with a hash doesn’t mean that next time it will fail if it tries to install a version of the package without that hash. If your package.json specifies a semver range then it’ll pull the latest minor or patch version (which is what happened in this case with e.g. duckdb@1.3.3) and ignore any hash differences if the version has changed. Hence why I say you need to go out of your way to specify an e…

I think at some point you would be better off vendoring them in.

That’s effectively what I did in a very roundabout way with docker images and caching that ended up abusing the GitLab free tier for image hosting. When you put it like that it does make me think there was a simpler solution, lol.

When I’m hacking on a C project and it’s got a bunch of code ripped out of another project, I’m like “heh, look at these primordial dependency management practices.” But five years later that thing is gonna compile no problem…

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

#113

Post by 47282847 »

galaxy_gas wrote: post #100
dist-epoch wrote: post #44

Earlier quoted context omitted.

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

Isn’t it still that when signatures are added at some point it turns out that the malware code has been uploaded months before, or did that change?

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

#114

Post by cluckindan »

chatmasta wrote: post #85
cluckindan wrote: post #76

Earlier quoted context omitted.

A complexity per line check would have flagged it. Even a max line length check would have flagged it.

That would flag a huge percentage of JS packages that ship with minified code.

Why would you be including minified code in a build? That’s just bad practice and makes development-time debugging more difficult.

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

#115

Post by cluckindan »

jay_kyburz wrote: post #111
chatmasta wrote: post #109

Earlier quoted context omitted.

Sure, but a lockfile with a hash doesn’t mean that next time it will fail if it tries to install a version of the package without that hash. If your package.json specifies a semver range then it’ll pull the latest minor or patch version (which is what happened in this case with e.g. duckdb@1.3.3) and ignore any hash differences if the version has changed. Hence why I say you need to go out of your way to specify an e…

I think at some point you would be better off vendoring them in.

There’s even a command for that: npm pack

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

#116

Post by AtNightWeCode »

phil294 wrote: post #93
AtNightWeCode wrote: post #70

I think JS should be all source and no packages at all.

What about complex SPAs? Database drivers? Polyfills? TypeScript?

Pulling the source and compiling the package instead of pulling the package. Not much difference. Maybe slower build times but more secure and better builds.

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

#117

Post by saghm »

chatmasta wrote: post #85
cluckindan wrote: post #76

Earlier quoted context omitted.

A complexity per line check would have flagged it. Even a max line length check would have flagged it.

That would flag a huge percentage of JS packages that ship with minified code.

It's not like minified JS can't be parsed and processed as AST. You could still pretty easily split up each statement/assignment to check the length of each one individually.

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

#118

Post by hulitu »

jefozabuss wrote: post #34

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

> By the way why doesn't npm have already a system in place to flag sketchy releases

Because nobody gives a fsck. Normally, after npm was filled with malware, people would avoid it. But it seems that nobody (distro maintainers) cares. People get what they asked for (malware).

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

#119

Post by withinrafael »

naugtur wrote: post #98
withinrafael wrote: post #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...

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.

Thanks will check both out!

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

#120

Post by withinrafael »

mike-cardwell wrote: post #97
withinrafael wrote: post #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...

https://gitlab.com/grepular/safernode

Thanks will check it out!
Post reply on HN