This is very true, but execution at install time (sometimes with root privileges) is a bad idea from a security perspective, especially when it happens with dependencies, which makes it very hard to check all packages that you're installing...
One of the problems is that npm (and others) put their credentials or some form of API token into dotfiles in the developers home directory, meaning that if you can execute code as the user (via social engineering or malware) you can push new packages.
In some cases it's even accepted practice to put the actual username/password in the clear in a dotfile, which means anyone who can even read a file from the users home directory, can gain persistent access to push packages as them...
Kind of amusing that this is considered to need a new vuln. report, I kind of assumed it was common knowledge.
Most of the programming language package repositories (e.g. npm, rubygems, PyPi, NuGet) have this kind of installation process and limited/no checks for malicious content.
Also as there's no consistent use of package signing by the developer (it's either unsupported or not very used) there is also a risk of the repository itself being compromised.
What a great link: topical and well-reasoned! The concluding sentence is interesting: "My biggest hope is that we’ll get a solution where the end user has the relationship with the source of trust and not the package author." If one runs one's own npm registry and audits everything that goes into it, one can have that already with npm.
Yes, that closing remark is very interesting. It would essentially be formalising what we somehow do manually/instinctively today: "Installing numpy/react/etc.? Yes, everyone I know trusts that, so I do too." "Installing random small non-popular package? I better have a bit of a look at the code first."
Indeed package signing is not the holy grail and won't solve all problems, but it is a part of a secure system.
For the problem this blog post talks about, I personally think that keybase is the right solution. You can tie a key to a github repository amongst others and then validate that the package you're installing came from the person who put the code on github in the first place...
He has lots of nice links, too. Hope you can factor some of it into your talks to get it to mainstream audience. I've saved the vid to check it out later. Will be interesting to see an experienced perspective with the modern tooling.
However, I admit I've always thought updating Shapiro's OpenCM or Aegis to distributed style with plugins for modern tooling gets us 90+% percent of the way. Without the problems of 90+% of build and package mgmt systems. ;)
Unfortunately I don't think that many/any of the Programming language package repositories have manual review processes, or even automated checking for things like known malware...
Linux package managers are a different story of course.
Firefox has automated "malware checking" for extensions, the Mozilla AMO Validator, and it's been basically torn to pieces by the community for being not actually secure [1] plus a major hassle for developers [2], to the point that large extensions with hundreds of thousands of users have stopped using the official Firefox extensions repository.
Yep it's a really nasty problem for any package manager that operates at scale.
The problem is that without any centralized validation of packages, it leaves checking to each developer who uses the libraries and obviously from an effort standpoint that just makes it worse (i.e. if it's hard for the repo owner to do validation it's hard x number_of_users for it to be done by end users)
The problem is basically how the centralized validation is supposed to work. For e.g. the Linux kernel, it's doable because all code in the kernel must (almost by definition) interact with some other part of the kernel. Thus someone else than the code owner, being responsible for those other parts of the kernel, can be tasked with signing off on the new code being good and non-malicious.
But for NPM or PyPI, where anyone can upload anything, how's that supposed to work? It's perfectly fine for someone to put a package called "removeallfiles" on PyPI which executes "sudo rm -rf /". This isn't (by itself) malicious code. The same code, but obfuscated and put in the package name "isarray", is perhaps obviously malicious. But what about something in the middle, e.g. some form of practical joke package? What central authority decides what is allowed and what is not on PyPI?
Signing is a tangential issue. As long as you're trusting the dev who uploaded the code, what difference does it make whether they used password or public key auth (effectively)?
Well if there's no central validation, that leaves all individual users to validate packages before use (which is a huge amount of work)...
The problem is that companies are using these packages as though they are trusted (i.e. not validating them when using them), and that's part of the value proposition in the first place (i.e. it's easier to use this package than write it myself), but it's missing the cost of validation.
On signing I'm not sure we're talking about the same thing. I'm referring to developers cryptographically signing packages before pushing to the repository, with a key that the end-user can validate. the idea is to protect against a comrpomise of the repository. There's a good discussion of the risks and potential solutions on The update framework's site (https://theupdateframework.github.io/)
Wrt. signing: I'm assuming we are talking about PyPI and NPM here. Also I'm assuming the major threat vector for a repository compromise is that (some of) the dev's accounts on some other services (most likely email) are somehow compromised. In which case it's down to that dev's OPSEC practices whether the repository can be compromised using the data from $OTHER_SERVICE. If the dev has poor OPSEC and would reuse the password for multiple accounts in a user/pass repo auth scenario, it's reasonable that this person would also have emailed themself the keys for signing packages, e.g. for transferring to another location behind a firewall. In either case, you're down to trusting the dev's OPSEC.
IMO, the threat models for other kinds of compromises which signing protects against are much more far fetched. AFAICT neither PyPI nor NPM use third-party mirrors, which basically leaves MitM attacks. If an attacker is capable of successfully MitM-ing the connections you make to PyPI/NPM over https, you have much bigger problems.
Ah yes, so the threat model for developer signing is compromise of the repository. So here we're looking at the OpSec of the repository owner (e.g. PyPI, npm, Rubygems etc), and also the risk of deliberate compromise by the repo. owner (for example where a state with authority over the repository compels them to modify a package)
In terms of compromise there's already been the attack on Rubygems in 2013, but in general the thought here is that these repositories are extremely tempting targets for well-funded attackers. A compromise of npm for example would give an attacker direct access to a very wide range of targets.
Combine this with the very limited resources of the repository owners (most are free resources, likely constraining the money available for defence) and you get a realistic risk of attack, which is mitigated by an appropriate use of signing by the developer.
Docker hub has deployed an implementation of the Update Framework to address this, although the interesting point now is whether people actually use it as it's not compulsory...
Unfortunately I don't think that many/any of the Programming language package repositories have manual review processes, or even automated checking for things like known malware...
It depends on what kind of repository you're trying to build.
If you're talking about something like NPM, PyPI or CPAN, then sure, these are relatively open systems where anyone can contribute but that includes bad people.
An example from the other end of the spectrum would be Boost for C++, which is heavily curated and peer reviewed, good enough in quality that its libraries sometimes become part of the full C++ standard at a later date, and tiny compared to the others I mentioned before.
I don't think this is unfortunate at all. I shouldn't have to wait for someone to review my code before publishing an important bugfix. This is the primary thing that drove me away from mobile apps.
On the flip-side how is someone who's using a package from one of these repository meant to validate that it's secure and non-malicious?
without central validation, each user would have to do it, and that's frankly impractical...
The alternative is that no-one actually does the validation and runs the risk of insecure or malicious packages. To me, that's totally fine as long as they're doing it knowingly, however I'd suggest that most companies making use of NPM, PyPI, Rubygems etc are not doing it knowingly...
I must admit I don't really see this products major benefits over other ways of achieving the same thing (a secondary phone with call forwarding from the main smartphone).
Their price is $100 and with that there's the usual risks of kickstarter delays/cancellations. But as an alternative things like the nokia 130 (http://www.microsoft.com/en/mobile/phone/130/specifications/) are already available cheaper have a longer battery life and proven track record...
That said the kickstarter already has £250k so they've obviously convinced some people!
I don't think EV SSL certificates have been a big success (though that's just a personal opinion rather something backed with specific data)
For me the differentiation in the browser presentation of EV against ordinary SSL doesn't provide much additional security. Most users don't notice the difference and even if they do, wouldn't remember which sites had an EV certificate, such that they would notice it changing back to non-EV
I wouldn't login to my bank's website if it didn't present me with green EV url bar. Same with paypal, amazon and basically anything to do with money has to have EV for me. I might be slightly paranoid, but I thought the point of ssl was EV.
on your second point, I'd be careful before making that assumption. Without evidence there's no reason to believe that a supplier company will have better security than your own and it's entirely possible they don't.
Also should a supplier suffer a breach they have powerful incentives not to disclose that breach to you, and where intellectual property is involved (e.g. code) the theft may well not become immediately apparent.
The provider has a specific set expertise that's probably better aligned with hosting this service. Since it's a revenue center for them, versus a cost center, they're better equipped to make the case to hire specialists.
The your second point - legalese is very beneficial for that. In the US at least, as long as it's not a protected (by FISA, etc..) organization breaking into your provider's systems, contract law covering compromises is a fairly well developed area.
However, Micropayments are not the only alternative to Advertising, subscriptions are another choice which only need to be done once rather than repeatedly.
I'd like to see more site offer an ad-free subscription, in the way that Ars Technica or reddit do, to allow for an alternative to using ads to support content I'm interested in.
Patreon has an interesting model for creative content and one which I think will work for content producers who already have a good fan base.
