[dead]
You too can run malware from NPM (I mean without consequences)
71–80 of 122 posts
Re: You too can run malware from NPM (I mean without consequences)
#72Earlier quoted context omitted.
Original author could be evil. 2fa does nothing.
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)
#73Seems 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...
The problem is that it is even possible to push builds from dev machines.
Re: You too can run malware from NPM (I mean without consequences)
#74I’ve been out of the loop with npm for a while, but are there still no package namespaces?
Namespaces have existed since ~2016 at least in npm, but since it's not enforced and people want "nice looking" package names, the ecosystem still hasn't fully embraced it. It seems like more and more projects are using them (probably because all "good" names are already taken), but probably way less than half of all popular packages are scoped/namespaced.
Well there is jsr now....
Re: You too can run malware from NPM (I mean without consequences)
#75Earlier quoted context omitted.
You're using HMR in your app's production bundle? How?
If you mean during development - you can opt out of using lavamoat in development for your webpack bundle (I'm assuming you're not running your untested code on valuable data)
Well, that’s not exactly reassuring. Having a very different runtime environment in production is grounds for hard to debug issues.
Is it possible to generate the allowlist at development time without having the webpack plugin loaded? If it’s only generated at build time, it won’t protect against malicious packages getting installed in CI just before the build happens.
Re: You too can run malware from NPM (I mean without consequences)
#76Seems 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.
A complexity per line check would have flagged it.
Even a max line length check would have flagged it.
Re: You too can run malware from NPM (I mean without consequences)
#77I’m intrigued but is that compartmentalization not incredibly expensive?
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)
#78Earlier quoted context omitted.
The package-lock.json includes a hash of the package, not just a version number which should be immutable.
To add to this: the hash in the lock file is the checksum of the published tarball, not the commit hash.
And then someone runs `npm install` on their CI
Re: You too can run malware from NPM (I mean without consequences)
#79Earlier quoted context omitted.
Yes, I am. I came up with the first successful attempt at integrating the Principle of Least Authority software in LavaMoat with Webpack and wrote the LavaMoat Webpack Plugin. Also, together with a bunch of great folks at TC39 we're trying to get enough building blocks for the same-realm isolation primitives into the language. see hardenedjs.org too I'm doing the rounds promoting the project today because at this poi…
I'm often curious about how effective runtime quasi-sandboxing is in practice (at least until support at the TC39 level lands). My understanding is that if you can run with a CSP that prevents unsafe-eval, and you lock a utility package down to not be able to access the `window` object, you can prevent it from messing with, say, window.fetch. But what about a package that does assume the existence of window or global…
It's based on HardenedJS.org
The sandbox itself is tight, there's a bug bounty even.
The same technology is behind metamask snaps - plugins in a browser extension.
And Moddable has their own implementation
The biggest problem is endowing too powerful capabilities.
We've got ambitious plans for isolating DOM, but that already failed once before.
Re: You too can run malware from NPM (I mean without consequences)
#80[deleted]