4 ms·

None of this solves the referenced social engineering attack, except possibly "run everything in containers". > Run everything in containers This only works i

None of this solves the referenced social engineering attack, except possibly "run everything in containers". > Run everything in containers This only works if you can split up your app into micro-services that can be adequately sandboxed, and even then only if the malicious dependency is in a locked-down service. But for example if your service needs to be able to make outgoing network requests to arbitrary hosts then you can't prevent a malicious dependency from sending your private data to its own server. > Don't install anything that is less than 7/14/X days old If everyone followed this advice, then the advice won't change anything. This advice only helps you if other people ignore it, at which it's just "let the suckers try the new versions first". And even then it won't solve the referenced social engineering attack, because that attack was targeting one specific user, and it doesn't matter how many other users test the dependency. > Sign all packages published with a private key and Complain if the package you dependent on have changed signing key This doesn't help either. The malicious package was published by an authorized maintainer of the project. Presumably if the package was signed with a private key, that private key would have been given to the maintainer to use in deploying (or alternatively the maintainer would have simply asked the original author to deploy the new version). > Install only packages from authors you have marked as trusted The malicious package was published under the name of a trusted author already. > Only install packages that have been signed by 2/3/X other people This isn't particularly scalable. It's hard enough as it is to get other people to even review the source of your open source library; asking them to stake their reputation on signing it too would be an even higher bar. Very few packages would end up cross-signed like this.

kazinator 8y ago
The advice not to install anything too new helps if there is a group of people beating up in new things specifically to find flaws. They are not "suckers", but "suck(urity resear)kers". :)
kevinsimper 8y ago
Hi eridius, thank you for your awesome comment, I really appreciate it! > But for example if your service needs to be able to make outgoing network requests to arbitrary hosts then you can't prevent a malicious dependency from sending your private data to its own server. Ideally you would know exactly which hosts you would want to talk to, but I know and understand that is a huge amount of work, but I know companies that are by default locking down everything and only opening up for things that are asked for by the app. > If everyone followed this advice, then the advice won't change anything. This advice only helps you if other people ignore it, at which it's just "let the suckers try the new versions first". And even then it won't solve the referenced social engineering attack, because that attack was targeting one specific user, and it doesn't matter how many other users test the dependency. That you can install something that is only 1 hour old without explicitly saying yes to that, exposes you to something where even outsiders wouldn't have time to even contact npmjs.com to take down the package. And alpha and beta software is quite common, it is just now common in the node.js/npm sphere. > This doesn't help either. The malicious package was published by an authorized maintainer of the project. Presumably if the package was signed with a private key, that private key would have been given to the maintainer to use in deploying (or alternatively the maintainer would have simply asked the original author to deploy the new version). I trust Dominictarr and you would not give others your private key, so I would know that it was not signed by dominic, but by a new author, and that could be raised as a issue. The same thing happends with SSH, first time you connect to a server it generates a host key, if the ip of the server suddenly change, you have to explicitly regenerate the host again to be allowed to connect to it again. It does that so you don't connect to random servers if they were hacked. > The malicious package was published under the name of a trusted author already. The publishing rights were moved, but the new author was not a trusted author. The npm publishing model is not based on trust but based on permissions. > This isn't particularly scalable. It's hard enough as it is to get other people to even review the source of your open source library; asking them to stake their reputation on signing it too would be an even higher bar. Very few packages would end up cross-signed like this. Yes, but you could put a price on people verifying packages for you, you could make an incentive for people to verify. This is like reviews on Foursquare and all these things, were people make their buying decisions based on reviews.

kazinator 8y ago

The advice not to install anything too new helps if there is a group of people beating up in new things specifically to find flaws. They are not "suckers", but "suck(urity resear)kers". :)

kevinsimper 8y ago

Hi eridius, thank you for your awesome comment, I really appreciate it! > But for example if your service needs to be able to make outgoing network requests to arbitrary hosts then you can't prevent a malicious dependency from sending your private data to its own server. Ideally you would know exactly which hosts you would want to talk to, but I know and understand that is a huge amount of work, but I know companies that are by default locking down everything and only opening up for things that are asked for by the app. > If everyone followed this advice, then the advice won't change anything. This advice only helps you if other people ignore it, at which it's just "let the suckers try the new versions first". And even then it won't solve the referenced social engineering attack, because that attack was targeting one specific user, and it doesn't matter how many other users test the dependency. That you can install something that is only 1 hour old without explicitly saying yes to that, exposes you to something where even outsiders wouldn't have time to even contact npmjs.com to take down the package. And alpha and beta software is quite common, it is just now common in the node.js/npm sphere. > This doesn't help either. The malicious package was published by an authorized maintainer of the project. Presumably if the package was signed with a private key, that private key would have been given to the maintainer to use in deploying (or alternatively the maintainer would have simply asked the original author to deploy the new version). I trust Dominictarr and you would not give others your private key, so I would know that it was not signed by dominic, but by a new author, and that could be raised as a issue. The same thing happends with SSH, first time you connect to a server it generates a host key, if the ip of the server suddenly change, you have to explicitly regenerate the host again to be allowed to connect to it again. It does that so you don't connect to random servers if they were hacked. > The malicious package was published under the name of a trusted author already. The publishing rights were moved, but the new author was not a trusted author. The npm publishing model is not based on trust but based on permissions. > This isn't particularly scalable. It's hard enough as it is to get other people to even review the source of your open source library; asking them to stake their reputation on signing it too would be an even higher bar. Very few packages would end up cross-signed like this. Yes, but you could put a price on people verifying packages for you, you could make an incentive for people to verify. This is like reviews on Foursquare and all these things, were people make their buying decisions based on reviews.