Emily is a product manager on the Chrome security team and leads long-term efforts to make the web more secure. Emily has previously worked on Google's Safe Browsing (anti-malware and anti-phishing) and AdWords anti-fraud teams to help protect Google and the internet at large from danger. Emily has degrees in Computer Engineering and Economics from Dartmouth College.View the profile
About the talk
Despite the earthquake of Spectre/Meltdown shaking-up security, there are steps that developers can take to maximize site safety. Come learn about Google's response, lessons learned, and what you can do to build secure sites for today and the future.
Hi everybody. Thanks for coming. I know you have a good selection of entertainment this afternoon. So I'm glad that so many of you chose security. Hopefully, we'll have some good fun little bit of here. Not too much. So today I'm going to talk about lessons that we learn from the Spectre and meltdown vulnerabilities. My name is Chris Palmer and from the Chrome security team and will be giving this talk into parts. I'll talk about Spectre and meltdown and how we defend it against it. And then in the second half my colleague Emily Schecter from chrome Security will talk about what you
develop hers can do to make the most of all the defensive work. We've been doing and Edition not just about Spectre and meltdown, but about other good stuff on the web and for extensions to So we'll talk about what Spectre is and why it hurts the web what we're doing to defend against it in a way that doesn't damage the web platform itself. And we got a little close to that as you some of you may know and I'll talk about what that was about and what we're going to do to get back to good and then as I was saying there's General advances that Emily is also going to talk
about there's some good stuff there. So you may have seen this logo. It's one of those logo to vulnerabilities meltdown is a variant of it that affects the operating system kernel, so we're not going to talk about that cuz we are focused on the web and what we have to do in support of non kernel space to be safe. So our concern is the open web platform. I would encourage all of you to check out the The Spectre attack.com website which describes the both attacks abilities
and also the Google project zero blog where John Horn one of the discoverers of this set of problems goes into a extreme technical depth, which I think you might enjoy I won't get too heavy in this talk will talk about what you need to know to get the impact of it. So these vulnerabilities became public in January of this year and as a whole team of people who discovered it people from Graz University in Austria in University of Adelaide in Randolph and independent researchers have one sort of had an angle on this thing. And these
are Hardware vulnerabilities not software vulnerabilities. So it's a different thing. It is a different situation than usual software patch. So we had to do a lot of work in Chrome to get through it and it was moderately terrifying and buy a moderately. I mean extremely and I extremely terrifying terrifying. I mean Don't Panic it's handled and you can do stuff and we did stuff and it's going to be okay we'll get through it. But you know, it was a little scary. I lost some sleep on the Chrome side. A lot of people did a lot of
work to make this defense happen. I'm sort of the messenger today, but the VA team the project zero team and there's a whole team called the site isolation team and you'll be hearing about them. They did a lot of work to get us through this little adventure and so I'm sort of presenting on their behalf. And I was just sort of the a guy they did all the real work. So the main impact of Spectre and meltdown is the hardware has a bit of a problem where if two programs are running on the same ship
they now have a they can lose confidentiality guarantee from each other one can read the secrets of the other. So that's a bad problem that Hardware supposed to protect against that the way it happens is most Modern Hardware has a feature called speculative execution wear when you're about to like Branch for an if statement, for example, even before you know, if the if conditions going to turn out to be true the computer starts to executing the F block because if it does turn out to be true then by the time you figure that out some of the work is already
done. So it's a form of a small-scale parallelism and it really helps performance a lot is huge advance. So what happens if the instructions if if he if branch is not taken then? Why is that work? You don't see it. It doesn't happen in your program. What happens is the computer never retires those instructions to the work. It's thrown away with no side effects on the registers are memory or anything like that, except. There's one little catch the cache memory in the chip the speed up memory access has side effects of loading
memory that had to be done drink speculation remain and an attacker can observe the side effects on the shared cache resource and that can happen both within and across privilege boundaries like across user to Colonel across from one process to another and on the web across origin. so that's a pretty bad problem and I hear that little snippet of how this might happen. This is what we're calling a speculation Gadget is a snippet of code of it either might appear in a program naturally or the
cause to be loaded some stuff into Cash memory. There's various ways to achieve that previous research showed how and there's an out-of-bounds secret Beyond the Edge of a ray one that will call K that the attacker wants to learn. That's that's the breaking the confidentiality guarantee and to get in cash. So accessing it as fast as opposed to accessing things out of main memory, which is fairly slow relative to the CPU speed. So what happens here is obviously we're going to do a bounced check because of course you would that causes
speculative execution. It might be the case. For example that fetch array one size from Main memory is going to be slow. It's not in cash. Let's say and then the computers going to start doing that y equals array to And then that's when the attack happened because what happens is that causes that memory to bit look to get loaded Into Cash memory and then accessing it later will be fast and that gives the attacker who can control and cara2 the ability to determine if for a guess and for every possible value of x
call, it just keep gassing in a for Loop and eventually the attacker will see that accessing in is fast and then they will know our accessing a and as an index of array one is fast and then they will know that that's the same value as the secret and the scales a sub exponentially. So it's actually practical to do you don't have to guess all possible values of K U get to guess bite by bite and then additively Hey time is so you can just run this in a for Loop and then they learn Secrets out of bounds stuff. It shouldn't be
able to read. So how do we defend against that the hardware doesn't do what we hope or it doesn't ice thing for us with cache memory and speculation but it has this bad side effect. So you might think as a lot of people at first did why don't we just turn off speculation? That would be great and the pain goes away or what if we just didn't have cash memory anymore. Well, that's completely untenable from a performance perspective. We really need speculation. And we really need a large share the cash to have low cost high performance. It's not really negotiable. So we have to use
a smarter approach than this or big dumb Hammer that you might imagine it first. So how does this impact the web it had a huge impact on operating systems and a hypervisors and that's other people that worried about that. I'm worried about the web. So it's the problems for a could generalize but I'm just going to focus on the same origin policy, which is really what we're hoping to achieve. That's our main security principal in the web. So here's a picture of a a typical renderer process. You know
Chrome is a multi-process architecture and it's running various processes to run your various tabs, and in anyone renderer process, there might be several different Origins happening at the same time. In this case. We've got innocent Origins a b and c but there's also a hostile origin running in the same address space. And that origin can either discover or cause to be created speculation gadgets like in the previous slide and then I can start reading data that belong to Origins a b and c inside the same process.
So that's a loss of confidentiality across Origins, which is extremely bad for the web. Like I said, I lost some sleep but we don't worry. We're going to take care of it. So the new Baseline that we Now operate and is just we assume that any any code running in a given address space in a given process can read the whole address space and that's a significant change from the previous status quo. So did you do the attack though? It's not automatically detect her needs a couple things. They need a CPU that does do
speculation which turns out to be not to use a certain low-end arm processors don't so those are actually safe but pretty much every other machine does every Intel Desktop. You've got every iPhone high-end Android the attacker gets that you need to see if you if I shared cash in again, every machine has that the attacker has that you need a high-resolution clock so that the attacker can time the difference between accessing stuff out of cash versus accessing stuff out of main memory the better the resolution of that clock the easier to achieve
turns out to be not really feasible. Unfortunately, the web platform has a whole bunch of clocks apis that our clocks on purpose like performance. Now and then there are apis that you're not to be clocked by accident or implicit clocks. Such as chair to REI puffer fish are the rainbow fairies some hands a few. All right. Well, it's a thing. It's a way to let you share data between a co-worker and your main thread for example, and that turns out to be a nanosecond scale clock cuz the worker can just increment the
counter in the shared array buffer. And then the main thread consejo. Hey, what's R value now? That's about how many milliseconds are sorry nanoseconds have passed. So it's a clock. So in order to make exploitation not be too easy. We actually did turn off shared array buffer even shortly after shipping it which was a real bummer for us. We did not want to do that because people need it to make cool applications on the way and we want the web to be cool and Powerful in to enable interesting applications. So we've had a big old argument about whether not we're really
going to do that, but we did and we're bringing it back. Explain how but unfortunately I think that did gain us something. I think the easiest route to exploitation was avoided in that by doing that and other browsers did similar things and we all collaborated just want to figure out how we're going to do this in a way that doesn't hurt the web. And so that we're all on the same page. That's actually another I should mention that it's kind of a happy story that comes out of this is a really good collaboration between the security teams of a lot of different browser vendors
and it's been a great experience for all of us and I think we're going to come out with a much better web. Thanks for the help of everyone. So and we're going to bring the shirt off your back once we have made the web safe for which sounds like a funny thing to say. So as I was going to getting that we don't want to a lightly toy with the web platform. It has to be stable so that you can build stuff on it if we're taking apis away or changing how they behave that's not a good developer experience. And that's therefore not a good user experience obviously, so we can't
do that too much and we did not do it lightly and going forward. Our goal is to be very very careful and ship was even more careful than before and ship things that we believe that we won't ever have to unship that's a tall order but Superbad emergencies like Spectre has her recalibrated. Our thinking is to what kinds of things are possible? And that's kind of been fun a good Adventure frightening form of fun that I kind of enjoy. So other things we can do like think back about that that
Gadget what if we could turn off speculation not across the board because that's not tenable for performance reasons, but what if we could just like for this if check when checking the Ray-Bans definitely make sure you fully checked it before you then speculate further you can do that actually different CPU architectures have different instructions to let you say don't go past this point until you loaded this thing for memory and so on you can turn off speculation on a micro-scale and the VA team heroic leave work to do as much of that as they can to get
rid of speculation Gadgets in the runtime and to change how they compile code to not generate any gadgets and that is a very Difficult thing and they had to do a lot of work and unfortunately, it doesn't get us all the way across the finish line. But it definitely again like turning off shoulder a buffer. You got us a little breathing room to get through to this point to where we now can do more long-term thing. So there's the low-level defenses but the web needs more than just that we've got to do something about the origin boundary per say we got to uphold that
thing directly. So that's what we're trying to do. So think about Malicious site that can take over a renderer such as by memory corruption neurologic bug. That's something that we call Universal cross-site scripting and that's a bad bug and they can cause other Origins that they want to attack to be loaded in the renderer. And so we knew we knew all along that we needed a good way to defend against that and so years ago. He started cooking one up and we call it site isolation
and it turns out that site isolation is super useful for Spectre also pretty much for the same reason because what it does is it's a rethinking of how we apportion Origins 2 processes in the past. It was based on like resource consumption and how busy is this random word? We need a new one. What can we reuse one? That's got a light load. So now we are going to instead lineup sites. Their processes there dedicated to them and that gets hostile Origins out of our address space
of innocent Origins. So here's a picture of the status quo sort of a a block diagram of the technology stack. You got your Hardware you got kernel-mode or ring zero you got user mode or ring 3 you got your Colonel, there's other usable and processes. There's the browser and the browser is spawning a renderer or maybe 10 to run Origins a b c and d or whatever else you got going. So that's the status quo in a way that seems simple when you draw a picture but it's an incredible amount of work. We had been fundamentally rethink
safely isolated from the good friends ab&c. So this is a great solution. We think it's the way forward for a variety of reasons not just Specter like I was saying it's also a good defense against Universal process good thing but it's not perfect. There's some limitations for one thing. I've been saying site not origin a site is going to be defined as being the effective top level domain plus one label below that so like NHS. Gov. UK. Gov. UK is the effective. Top level
domain NHS one level below similarly calm and then one level below Bing or Google or whatever. So that's very different than the definition of An Origin, which is a whole host name and the port number and of course for both of these scheme matters to you can't be the same site if your HTTP as the HTTP version of your site you can't have that. So excited is the skiing in the effect of TLD + 1 or e t l d and as you can imagine we're going to be loading or launching more processes that uses more memory. So
unfortunately a little more RAM is going to be required and then last there's a thing called cross origin read blocking which is a crucial part of site isolation that requires you to do a little bit of work not it's not a heavy lift. Don't worry too much and Emily will explain how you Get the most of it and why it's important, but it's it's a crucial thing that you all want to take a look at the final thing that we're changing how we do for a specter is before we give super important information to a renderer like autofill form data
your passwords payment instruments. We were going to get that on some indication that the user the person really wants to do it. There won't be any sort of automatic giving of super sensitive information to renderers to the person's going to be maybe a little more in the loop on some things than they have in the past and I really everything that's important. Especially given the fact that a site being more broadly defined in An Origin a site may contain some potentially hostile origins in its same site instance
and therefore the same process. for example Super important thing that example.com and forgotten old WordPress installation. Example.com. Those are in the same site currently, so obviously in a long-term. We'd like to get back to something closer to the origin definition. We're going to make sure people want to do things before we give information to render us. So there's things you can do about this including cross origin reblocking and that's where Emily comes in from chrome security team, and she's got
some good information for you. So, please give her a warm welcome. All right. So thanks so much Chris for enlightening us about Spector and 4 / viewing ways that were making Chrome and the web platform sneaker with site isolation there. Now. I know all of you make you wondering what you can do about all of this and it turns out that they're actually lots of things that you as web developers can do to best amp up your defenses. So I'll go over some steps that you should take to keep your web project secure.
First I'll talk about steps that you should take to get the most of Spectre defenses and then I'll talk about some General Security recommendations for website developers and four extension Developers. The first let's talk about the Spectre specific defenses. And there are two specific areas that you'll want to think about as a web developer getting the most out of cross origin read blocking and cookie help and about how you should think about them. So first, we'll talk about the future that Chris mentioned called cross origin
with some sense of information like maybe your bank balance without site isolation? The contents of the Json file would make it to the renderer processes memory at which point the renter notices that it's not a valid image format and doesn't run to the image, but now we have Spectre and so now there's a way to potentially read that chunk of memory. So cross origin read blocking would actually prevent the contents of this file from ever entering the memory of the process that the runner is running because the mine pipe is blocked by a cross origin read Baki. So let's
break down how this works. Website can request two types of URLs from a server data resources and media resources to hear data resources include text or code life resources. So HTML XML Json files in a website is able to receive data resources from its own domain or from other domains with permissive Coors headers. Do Crossfade out of resources come from a different sites in the page that request them and they do not have cores headers that would make them accessible. Media resources could include things like images or
here's an example for random sites.com or we have to process of resources from your bank. Calm. Right which might be some pretty sensitive information. So the first looks like an image but it actually includes Jason and it does not include a corset Ur So it will be blocked and in the second request. It's fetching Json, but it does include course. So if there is a legal access-control-allow-origin header on the response, it will be allowed. So what this means is that to benefit from crossword Henry blocking you need to send the right content type letters.
So that cross origin read blocking can recognize the resources sensitive and block it. You should also tell the browser not to mind sniff. So when no step is missing Chrome does do a quick content analysis to try to confirm that a type is wreck is correct, but you're definitely better off affirmatively doing the right thing yourself. So that's cross origin read blocking. So now let's move on to cookie health. So if we go back to our previous example where the attacker created in image tag, that includes a Json file with sensitive data. This actually only
data from entering the renderer process. You can set the HTTP only cookie attribute which explicitly prevents the cookie from being accessed through client-side script on supported browsers like Chrome and if setting HTC only is impossible. You can help limit the exposure of loading cookie data to the renter process by not reading document. Cookie unless it's absolutely necessary. So that wraps up how you as a web developer should make changes to best mitigate Spectre. We have this information posted online on our web fundamentals article. So definitely check back there
for more updates. So now that we've talked about ways to mitigate Spectre. Let's talk about other ways that you can keep your web project space and I say projects here because many of these methods are applicable for both websites and Chrome extensions. So there are three overall categories to think about improving security for your site or extension. No persons using web security standards. GPS is one of our favorite topics on the Chrome security team. So I would definitely be remiss if I didn't remind you that when sending or requesting
data, you should always avoid HDPE at least important for website developers and it's also important for extension developers to write you should never be using a playing HTTP in your extension. HTTP is just the bare minimum web users today expect in terms of site security and at 4 p.m. Today right after this talk, but over on stage 6 Adrienne Porter felt and then we'll be talking about amazing adoption trends that we're seeing and also the latest and greatest updates in HTTPS URI changes in Chrome. So be sure to go check out that talk and of course
if you aren't using HTTP, you can check out our set-up guide to figure out how to get started. The content security policy provides a rich set of directives that enable granular control over the resources that are Pages aloud to load and rather loaded from this is an awesome way to help prevent prostate scripting attacks. And there a lot of ways that you can use the different directives and the policy violation reporting tools that you might not know about it. So I recommend that you go check out our website of Mendel's article to learn more and extension developers CSP is for you too, and
you should definitely include an explicit CSP for the extension in the Manifest. So if you're using content security policy in your extension, it might look something like this if the extension is only loading resources from itself. You can register is CSP and if the extension need to include scripts from specific host, they could be included here as well. So it's a quick primer about what you should know in terms of web security standards, and now let's move on to protecting developer account. So it this one is actually a particularly important for developers of Chrome
extensions. Your developer of a Chrome extension, you might not realize it but you actually now have a lot of power because your code is running on a lot of users browsers. Right? So if your developer account is compromised in attacker could just push Melissa malicious code directly to a lot of users. So this means that you've actually become a pretty juicy Target for attackers and what this means is that you should definitely take extra care to protect your developer account. The Google release the advanced Protection Program to safeguard the Google accounts of those most at risk of
targeted attacks and includes fishing protection with a physical security key starting your emails and files by limiting access to non Google services and blocking fraudulent account access with extra steps to verify that it's you. But if the advanced protection program is not for you, you should definitely still take other measures to protect your account. For example, you should enable two-factor authentication and preferably with a security key. Define Ali I'll talk about privacy protections and hear all
focused on permissions. The first I'll talk about permissions best practices for web developers, and then I'll talk about permissions best practices for extension Developers. On the way up when you use certain powerful apis like your location or push notifications Chrome won't ask the user for permission to use that powerful API and it's important for you as a developer to consider how you'll be asking you users for this information in particular its users understand the value that permission brings at the time when you asked for it.
Don't freak sample here. We have a hypothetical Airline by bad and you can see there's a Chuck box at the bottom of the screen for user to indicate that they want notifications for flight delays. And so after a user Texas box is a really great time to ask for the person notification permission because the value was getting notifications for flight delays is really clear. How much worse user experience would be for example just spamming the user on page load all the time for a bunch of permissions that might seem random at that point. Turn off alarm system permissions best
practices for extension developers required permissions and using optimal permissions. so first reduce required permissions Baby eyes and extension can access as specified in the permissions field of the Manifest and the more permissions are granted. The more Avenues an attacker has The Intercept information. So only apis that extension depends on should be listed. Extensions that are using host permissions to inject scripts can often substitute active tab instead. The active side permission will grant an
extension temporary access to the currently active have only when the user invokes the extension and access is cut off when the user navigate to way from forecloses. The current tab is a good alternative for many uses of all urls. You should also Empower users to choose which features and permissions. They need from an extension by including optional permissions. It's a feature is not essential to the core functionality of an extension make an optional and Lucy API or domain into the optimal permissions field.
Here's what using Optimus Optimus optional permissions looks like in our manifest. Okay, so we just covered a lot of best practices be covered how you can take advantage of for protection from Spectre and we covered other best practices keep your website or your extension space using web security Standards Developer account protection and permissions best practices. I chrome, we believe in creating a web that's easy to use securely by default and we continue to work on security protections that makes the entire web safer. So it developers go out there and take advantage of these
Buy this talk
Access to all the recordings of the event
Buy this video
With ConferenceCast.tv, you get access to our library of the world's best conference talks.