6 ms·

> if you know what the update contains? I think anyone who thinks they're doing this is fooling themselves. You can review code for accidental vulnerabilities

> if you know what the update contains? I think anyone who thinks they're doing this is fooling themselves. You can review code for accidental vulnerabilities but if someone is trying to slip in a backdoor it shouldn't be hard to do so in a stealthy manner. The reality is that the entire dependency concept is just broken. There is an implicit trust that all dependencies are equally trusted. Your logging package is just as capable of performing file and network operations as your http package, even if you assume it won't. That's silly. It is up to programming languages and package managers to solve these problems. They're also not that hard to solve, in my opinion. "Run arbitrary code on a computer" is a model we've been securing for decades with web browsers, both in terms of web pages and extensions, and now too with mobile. Solving "this code can do X but that code shouldn't be able to" is similarly easy to solve with languages that support effects or capabilities. It just hasn't been done yet.

Gigachad 5y ago
Permissions inside a programs own code seems incredibly difficult without radical change.
- staticassertion 5y ago
  Pony's object capabilities are one example of an existing implementation. I don't think there's any "inventing" To do here, it's all just implementation work.
- naasking 5y ago
  It's actually trivially easy once you remove ambient authority, which is the real source of these security problems. Consider how a program could modify your files if it cannot willy-nilly turn any old string into a file handle.
xg15 5y ago
Adding permissions is a reasonable step, but I don't think it solves the problem. We know, it's very hard to get granularity right with permission systems and there is a strong temptation to just give everything all permissions. Dependencies with dangerous but necessary permissions can still abuse them: Your network library will still be able to add a bitcoin miner. What happened if an update requests a new permission? Also, how would that have prevented the current situation? Infinite loops are famously hard to detect and prevent automatically.
- staticassertion 5y ago
  > Adding permissions is a reasonable step, but I don't think it solves the problem. We know, it's very hard to get granularity right with permission systems and there is a strong temptation to just give everything all permissions. A lot of that stems from permissions systems being implemented outside of the code they constrain. In theory a compiler knows every reachable system call and all points of data input that could reach them, and as such it could constrain the program's capabilities accordingly. In fact, compilers already do this for control flow integrity - it would just be a more advanced system. > What happened if an update requests a new permission? It's going to depend on the system. For browser extensions the new permission means a new prompt, so you'd get a CI failure until a human updated a lockfile. > Also, how would that have prevented the current situation? Infinite loops are famously hard to detect and prevent automatically. It really depends on the system. You could have a CPU capability that restricts cycles or forces preemption, etc. I'm not saying you can solve literally all security problems but you can reduce risk considerably. If "infinite loop" is the scariest thing a dependency can do we're in a pretty good position. An unconditional infinite loop should break your CI tests.
  - michaelt 5y ago
    > In theory a compiler knows every reachable system call and all points of data input that could reach them Sorta yes, sorta no. Imagine I'm making a chat client, and I want users to be able to drag and drop images to share. But the OS doesn't have an "open drag-and-dropped file, extension .png or .jpg" function call, it only has "open file" which lets me open ~/.ssh/id_rsa too. Or if I'm making a web browser and I want to support U2F tokens. But there's no OS "talk to U2F token" call - the browser needs access to the system calls for "talk to arbitrary USB devices". Sandboxing PC software is tough.
    - naasking 5y ago
      > But the OS doesn't have an "open drag-and-dropped file, extension .png or .jpg" function call, it only has "open file" which lets me open ~/.ssh/id_rsa too. A programming language doesn't have to expose system calls directly. It arguably it shouldn't, in fact, for exactly this reason.
ghoward 5y ago
Adding permissions would not have caught this case, though, because there is no need for permissions to run an infinite loop.

Gigachad 5y ago

Permissions inside a programs own code seems incredibly difficult without radical change.

staticassertion 5y ago
Pony's object capabilities are one example of an existing implementation. I don't think there's any "inventing" To do here, it's all just implementation work.
naasking 5y ago
It's actually trivially easy once you remove ambient authority, which is the real source of these security problems. Consider how a program could modify your files if it cannot willy-nilly turn any old string into a file handle.

xg15 5y ago

Adding permissions is a reasonable step, but I don't think it solves the problem. We know, it's very hard to get granularity right with permission systems and there is a strong temptation to just give everything all permissions. Dependencies with dangerous but necessary permissions can still abuse them: Your network library will still be able to add a bitcoin miner. What happened if an update requests a new permission? Also, how would that have prevented the current situation? Infinite loops are famously hard to detect and prevent automatically.

staticassertion 5y ago
> Adding permissions is a reasonable step, but I don't think it solves the problem. We know, it's very hard to get granularity right with permission systems and there is a strong temptation to just give everything all permissions. A lot of that stems from permissions systems being implemented outside of the code they constrain. In theory a compiler knows every reachable system call and all points of data input that could reach them, and as such it could constrain the program's capabilities accordingly. In fact, compilers already do this for control flow integrity - it would just be a more advanced system. > What happened if an update requests a new permission? It's going to depend on the system. For browser extensions the new permission means a new prompt, so you'd get a CI failure until a human updated a lockfile. > Also, how would that have prevented the current situation? Infinite loops are famously hard to detect and prevent automatically. It really depends on the system. You could have a CPU capability that restricts cycles or forces preemption, etc. I'm not saying you can solve literally all security problems but you can reduce risk considerably. If "infinite loop" is the scariest thing a dependency can do we're in a pretty good position. An unconditional infinite loop should break your CI tests.
- michaelt 5y ago
  > In theory a compiler knows every reachable system call and all points of data input that could reach them Sorta yes, sorta no. Imagine I'm making a chat client, and I want users to be able to drag and drop images to share. But the OS doesn't have an "open drag-and-dropped file, extension .png or .jpg" function call, it only has "open file" which lets me open ~/.ssh/id_rsa too. Or if I'm making a web browser and I want to support U2F tokens. But there's no OS "talk to U2F token" call - the browser needs access to the system calls for "talk to arbitrary USB devices". Sandboxing PC software is tough.
  - naasking 5y ago
    > But the OS doesn't have an "open drag-and-dropped file, extension .png or .jpg" function call, it only has "open file" which lets me open ~/.ssh/id_rsa too. A programming language doesn't have to expose system calls directly. It arguably it shouldn't, in fact, for exactly this reason.

ghoward 5y ago

Adding permissions would not have caught this case, though, because there is no need for permissions to run an infinite loop.