5 ms·

> There is nothing special about computer that allows us to put complete trust into any piece of code, and that is okay. Instead, we strive to build trust among

> There is nothing special about computer that allows us to put complete trust into any piece of code, and that is okay. Instead, we strive to build trust among developers so that we don't have to read every line of code in every level of abstraction to make sure our files won't be deleted. I don't understand why this is so often treated as a dichotomy, where either you trust every single author to not delete your files, or you review every line of code to make sure it doesn't delete your files. Both seem unsustainable. I think we need to look at the problem from a different perspective: why is every single transitive dependency able to delete your files? Take a look at the node-ipc method reference: https://www.npmjs.com/package/node-ipc#ipc-methods https://www.npmjs.com/package/node-ipc#ipc-methods What functionality does node-ipc have that requires it to have unfettered access to the filesystem? Well, with its current implementation, it needs to be able to create a unix socket for e.g. 'serve()'. But if you changed the API a bit, you could conceivably pass it a file handle to a unix socket that you've just created, instead. Now that module doesn't need any arbitrary filesystem access at all! You could make similar changes to those methods responsible for making outbound network connections, etc. At that point, you could almost completely sandbox this module, because all it needs is what you've given it. In other words: let's apply the principle of least authority for real. https://medium.com/agoric/pola-would-have-prevented-the-event-stream-incident-45653ecbda99 https://medium.com/agoric/pola-would-have-prevented-the-even...

eyelidlessness 5y ago
There are a lot of people who think subdeps should be able to just assert that they’re not vulnerable at all. It’s a popular idea, enough so it might be implemented in Node. Even though the originator of the idea was receptive to my many objections, the RFC authors were not. Here’s a thought that’s been living in my head rent free ever since: what if we don’t have transitive dependencies at all? What if we just… package them all up together? That sounds absurd, but we are almost all using a build system, we who are all have sourcemaps and dead code elimination baked in. We can standardize this. The package NPM delivers is already different from the published thing. We can define “this is how you reproduce my build”, and distributors can say “this is what is present in this package” with high confidence. Sourcemaps can deduplicate.
- vladvasiliu 5y ago
  I'm not very familiar with how Node dependencies work, but isn't this just reshuffling the same card deck? If package M is malicious, what difference does it make if it's required directly by your app, or through a sub-dependency chain, like A -> B -> C -> M? If you have an approach that allows you to vet all your direct dependencies, why wouldn't that allow you to vet sub-dependencies as well?
  - eyelidlessness 5y ago
    What I’m proposing is specifically in cases where sub-dependencies may have a known vulnerability but that isn’t in any of the call paths of your direct dependency. It’s an alternative to the “audit assertions”[1] proposal, which I find problematic for reasons I discussed there before I bowed out. My idea is that you can be confident you’re not affected by a vulnerability in a dependency (at any depth), if that vulnerability is no longer in the code in the first place. It also reduces the surface area to vet in the first place. It’s highly likely many dependencies will be stripped down considerably, if not outright deduplicated or eliminated. The “npm installs thousands of dependencies” thing is a real problem, but it’s also partly because it’s installing stuff you’ll never actually execute in any way. You can pare down sub-dependencies with confidence, because you already know what code paths are hit by the parent dependency at packaging time. You can’t do that with direct dependencies until you go to package/deploy, because of course you may expand your usage of their APIs during development. 1: https://github.com/npm/rfcs/pull/422 https://github.com/npm/rfcs/pull/422
    - vladvasiliu 5y ago
      This sounds like a good idea to me. My shallow understating of the Node ecosystem makes me think of tree-shaking. Is that something else? I was under the impression that it allowed not shipping pieces of the dependencies which are unused, which should help with limiting the surface area to vet. From my superficial understanding of how this works, couldn't the "build" phase take note which parts of dependencies are loaded, and then compare those with where the known vulnerabilities are? I realize some issues may be bigger or harder to narrow down, but it still looks like it would be a step in the right direction.
weq 5y ago
Totally agree with this. People think because your code is popular it means its good. API surface area stuff like this causes crypto heists everyday.
Legogris 5y ago
If you find this resonates, Lavamoat is basically the continuation of that 2018 blog post. Hopefully it catches on to get enough traction that SES (or something similar enough providing an API for controlling capabilities) makes it into runtimes. https://github.com/LavaMoat/LavaMoat https://github.com/LavaMoat/LavaMoat https://news.ycombinator.com/item?id=30707096 https://news.ycombinator.com/item?id=30707096
klabb3 5y ago
Sure, but languages aren't designed to provide secure isolation on a module-by-module level. The encapsulation that exists (e.g. private fields) isn't for security. Or is there some security feature of node or JS that I'm missing?
- ryukafalz 5y ago
  You’re right that in most languages, encapsulation isn’t strong enough to be used for security in this way. However, there are languages in which it is; scheme I believe has strict enough lexical scope and encapsulation to be used like this. (And of course there are languages designed specifically for this purpose, though they’re not often used: E and Monte come to mind.) Of the popular languages, though, JavaScript is the closest to being strict enough for this style of programming, and there’s been active work for a while towards that goal: https://agoric.com/blog/technology/ses-securing-javascript/ https://agoric.com/blog/technology/ses-securing-javascript/
zarzavat 5y ago
Sandboxed components are good at mitigating attacks from the outside. However they don’t help much against a malicious package author who has a multitude of different ways of causing havoc: while(1); for example. Playing this game of cat and mouse will add so much red tape that nobody will want to use that package manager anymore. Ultimately package repos run on trust and a low level of risk is tolerated because of the benefits of being able to get stuff done.
- nindalf 5y ago
  Mitigation strategies while(1) - kill -9 / Task Manager / Activity Monitor All files deleted - cry.
- vladvasiliu 5y ago
  > Playing this game of cat and mouse will add so much red tape that nobody will want to use that package manager anymore. Of course. But your comment still reads as "we can't make it perfect, so might as well not try at all". I think there can still be value in limiting the blast radius. Your while(1), if present, is likely to be intentionally malicious. But I've seen many naïve libraries implement "accidentally quadratic" algorithms, which is basically a disguised while(1), but unintentional. The point is that the end result of `rm -rf /` is painful. It doesn't matter if someone managed to maliciously sneak that into your supply chain, or if it rises from some funky corner case of some package whose only goal is to bring world peace. So being able to prevent some leftpad lib from accessing the file system at all makes a lot of sense.
- Legogris 5y ago
  > while(1) In SES, that is controlled by allowing assignment of a budget and failing if it's exceeded. Similar to how gas works in the EVM.
pabs3 5y ago
Distributed code review might tradeoff between trusting authors vs reviewing everything yourself. https://github.com/crev-dev/ https://github.com/crev-dev/
deleted 5y ago
[deleted]
broken8ball 5y ago
AFAIK, Deno seeks to solve the most severe case of this problem in Node[0]. At the very least, you start from a place where permission surprises are more readily caught. Would be really great to be able to specify on a per-import basis. [0] https://deno.land/manual/getting_started/permissions https://deno.land/manual/getting_started/permissions

eyelidlessness 5y ago

There are a lot of people who think subdeps should be able to just assert that they’re not vulnerable at all. It’s a popular idea, enough so it might be implemented in Node. Even though the originator of the idea was receptive to my many objections, the RFC authors were not. Here’s a thought that’s been living in my head rent free ever since: what if we don’t have transitive dependencies at all? What if we just… package them all up together? That sounds absurd, but we are almost all using a build system, we who are all have sourcemaps and dead code elimination baked in. We can standardize this. The package NPM delivers is already different from the published thing. We can define “this is how you reproduce my build”, and distributors can say “this is what is present in this package” with high confidence. Sourcemaps can deduplicate.

vladvasiliu 5y ago
I'm not very familiar with how Node dependencies work, but isn't this just reshuffling the same card deck? If package M is malicious, what difference does it make if it's required directly by your app, or through a sub-dependency chain, like A -> B -> C -> M? If you have an approach that allows you to vet all your direct dependencies, why wouldn't that allow you to vet sub-dependencies as well?
- eyelidlessness 5y ago
  What I’m proposing is specifically in cases where sub-dependencies may have a known vulnerability but that isn’t in any of the call paths of your direct dependency. It’s an alternative to the “audit assertions”[1] proposal, which I find problematic for reasons I discussed there before I bowed out. My idea is that you can be confident you’re not affected by a vulnerability in a dependency (at any depth), if that vulnerability is no longer in the code in the first place. It also reduces the surface area to vet in the first place. It’s highly likely many dependencies will be stripped down considerably, if not outright deduplicated or eliminated. The “npm installs thousands of dependencies” thing is a real problem, but it’s also partly because it’s installing stuff you’ll never actually execute in any way. You can pare down sub-dependencies with confidence, because you already know what code paths are hit by the parent dependency at packaging time. You can’t do that with direct dependencies until you go to package/deploy, because of course you may expand your usage of their APIs during development. 1: https://github.com/npm/rfcs/pull/422 https://github.com/npm/rfcs/pull/422
  - vladvasiliu 5y ago
    This sounds like a good idea to me. My shallow understating of the Node ecosystem makes me think of tree-shaking. Is that something else? I was under the impression that it allowed not shipping pieces of the dependencies which are unused, which should help with limiting the surface area to vet. From my superficial understanding of how this works, couldn't the "build" phase take note which parts of dependencies are loaded, and then compare those with where the known vulnerabilities are? I realize some issues may be bigger or harder to narrow down, but it still looks like it would be a step in the right direction.

weq 5y ago

Totally agree with this. People think because your code is popular it means its good. API surface area stuff like this causes crypto heists everyday.

Legogris 5y ago

If you find this resonates, Lavamoat is basically the continuation of that 2018 blog post. Hopefully it catches on to get enough traction that SES (or something similar enough providing an API for controlling capabilities) makes it into runtimes. https://github.com/LavaMoat/LavaMoat https://github.com/LavaMoat/LavaMoat https://news.ycombinator.com/item?id=30707096 https://news.ycombinator.com/item?id=30707096

klabb3 5y ago

Sure, but languages aren't designed to provide secure isolation on a module-by-module level. The encapsulation that exists (e.g. private fields) isn't for security. Or is there some security feature of node or JS that I'm missing?

ryukafalz 5y ago
You’re right that in most languages, encapsulation isn’t strong enough to be used for security in this way. However, there are languages in which it is; scheme I believe has strict enough lexical scope and encapsulation to be used like this. (And of course there are languages designed specifically for this purpose, though they’re not often used: E and Monte come to mind.) Of the popular languages, though, JavaScript is the closest to being strict enough for this style of programming, and there’s been active work for a while towards that goal: https://agoric.com/blog/technology/ses-securing-javascript/ https://agoric.com/blog/technology/ses-securing-javascript/

zarzavat 5y ago

Sandboxed components are good at mitigating attacks from the outside. However they don’t help much against a malicious package author who has a multitude of different ways of causing havoc: while(1); for example. Playing this game of cat and mouse will add so much red tape that nobody will want to use that package manager anymore. Ultimately package repos run on trust and a low level of risk is tolerated because of the benefits of being able to get stuff done.

nindalf 5y ago
Mitigation strategies while(1) - kill -9 / Task Manager / Activity Monitor All files deleted - cry.
vladvasiliu 5y ago
> Playing this game of cat and mouse will add so much red tape that nobody will want to use that package manager anymore. Of course. But your comment still reads as "we can't make it perfect, so might as well not try at all". I think there can still be value in limiting the blast radius. Your while(1), if present, is likely to be intentionally malicious. But I've seen many naïve libraries implement "accidentally quadratic" algorithms, which is basically a disguised while(1), but unintentional. The point is that the end result of `rm -rf /` is painful. It doesn't matter if someone managed to maliciously sneak that into your supply chain, or if it rises from some funky corner case of some package whose only goal is to bring world peace. So being able to prevent some leftpad lib from accessing the file system at all makes a lot of sense.
Legogris 5y ago
> while(1) In SES, that is controlled by allowing assignment of a budget and failing if it's exceeded. Similar to how gas works in the EVM.

pabs3 5y ago

Distributed code review might tradeoff between trusting authors vs reviewing everything yourself. https://github.com/crev-dev/ https://github.com/crev-dev/

deleted 5y ago

[deleted]

broken8ball 5y ago

AFAIK, Deno seeks to solve the most severe case of this problem in Node[0]. At the very least, you start from a place where permission surprises are more readily caught. Would be really great to be able to specify on a per-import basis. [0] https://deno.land/manual/getting_started/permissions https://deno.land/manual/getting_started/permissions