Presentation: Making 'npm install' Safe

Track: 21st Century Languages

Location: Majestic Complex, 6th fl.

Duration: 10:35am - 11:25am

Day of week: Wednesday

Share this on:

What You’ll Learn

  1. Find out about some of the security issues using NPM packages.
  2. Hear about the EventStream incident that created a security breach in a package.
  3. Learn about Realms and SES as possible solutions to NPM package security vulnerabilities

Abstract

There’s a JavaScript package for everything. But installing a random package is a security nightmare: the installed package can access your data and send it over the network without anyone ever knowing.

But there’s hope! This talk will discuss how to minimize the risks of running third-party JavaScript. We’ll go over POLA, the Principle of Least Authority, and how object capabilities can help us grant specific, limited resources to third-party code. We’ll also cover the current efforts to enforce security boundaries in JavaScript: SES (Secure ECMAScript) and Realms.

Question: 

What is the focus of your work today?

Answer: 

At Agoric our focus has been allowing developers to be less vulnerable when they're writing code. By that I mean that a lot of the times when we're writing code these days we use packages and libraries from other people. But in many cases when we install those packages we're leaving ourselves completely vulnerable to whatever it is that those packages want to do, whether it's access to the network, access to the file system. At Agoric, one of our primary focuses is trying to figure out how we can write our code in such a way that both reduces the attack surface and makes it safe for us to reuse other people's code.

Question: 

Would you like to elaborate a little bit on the motivation for your talk and the specific technologies you're focusing on?

Answer: 

I think there was actually an incident that set the talk really well. You might have heard of the EventStream incident where EventStream is a very popular NPM package. It was taken over by a new maintainer who through a series of events managed to import a malicious dependency and use the EventStream package to attack a bitcoin wallet with the goal of stealing Bitcoin private keys. This created a huge uproar. It was very concerning because all of these developers are completely vulnerable to all these different packages. And it's really hard to know what package is going to be the next EventStream.

The motivation for this talk is to say, so we have this huge problem as JavaScript developers. But when you look at the specific instance of EventStream, why on earth does this random JavaScript package need access to the file system and access to the network? Shouldn't there be some way that we know whether it's actually getting access to those resources? If you look at NodeJS all code has access to these sorts of resources by default. There's a movement to try to make it so that code doesn't have access by default. This principle is called POLA, or the principle of least authority. So part of the motivation for this talk is to explain how we can use POLA to only give packages and modules access to the resources that they actually need to do their job and no other access. It allows us to design our programs in a way that protects us from unintended consequences and really limits the attack surface. One thing that really helps in enforcing POLA is an approach called Object Capabilities which is a specific kind of access control model. And in addition to that I also go over some tools that can be used to apply POLA, Realms and SES.

Question: 

How do you describe the target persona?

Answer: 

I would say that the primary persona for this audience is a JavaScript developer who wants to improve their craft. And this can be in several ways, by protecting themselves from attackers and also just making it easier to reason about their own code. So this persona it may be a front-end developer, it may be a back-end developer. They may be using Node, they may not be using Node, but they're probably unsatisfied with their current package manager systems. This talk is primarily for JavaScript developers but other languages like Ruby and Python have similar problems with their package manager systems. So I can see that also being helpful. But in all cases they probably want to find a way to use third party code without having to worry as much about its security.

Question: 

What do you want this persona to walk away from your talk with?

Answer: 

I think the first thing that I want this persona to walk away with is the idea that security isn't impossible. I think sometimes it just seems so difficult. People think, why even try? But the real takeaway that I want people to walk away with is that security is worth pursuing. And it may actually even be easy if people have done the work and they're putting things in the JavaScript standard to make this possible. In the future it may actually be easy. The second thing is that I think as one of the reactions to something like the EventsStream incident has been, oh, we need to stop relying on other people's code. Why do we have so many packages? That sort of thing. So the second thing that I want people to walk away with is that we should really encourage the reuse of code, not discourage it. There's nothing wrong with it; t's just that our security model is wrong. And two last things are just coming away with real actionable ways to enforce POLA in their systems. That would include Realms and SES as tools to actually enforce POLA.

Speaker: Kate Sills

Software Engineer @agoric

Kate Sills is a software engineer at Agoric, building composable smart contract components in a secure subset of JavaScript. Previously, Kate has researched and written on the potential uses of smart contracts to enforce agreements and create institutions orthogonal to legal jurisdictions. Kate earned her degree in CS from UC Berkeley, and is building a tiny house in her spare time.

Find Kate Sills at

Tracks

Monday, 24 June

Tuesday, 25 June

Wednesday, 26 June