What Your Browser Can Teach You About Secure Design

okay so who who uses a web browser here easy question yeah um do you use one on your phone yeah and on a laptop or a desktop device yeah they're kind of ubiquitous aren't they like they're pretty much everywhere we use them for all sorts of stuff these days and they're really interesting from a security point of view for a bunch of reasons not least because there's loads of stuff that as security people people we rely on every day and if it wasn't for browser development we' never have them so little things like hello screen save

this don't know what happened there little things like um bug bounties do you know the first bug Bounty for a consumer product was for a web browser the Netscape 2 believe it or not um little things like transport layer security again Netscape invented transport layer security or SSL as I called it then um little things like application sandboxing in consumer operating systems not a thing that existed before um browsers things like um wasm the runtime that we use for web assembly things like um memory safe both temporarily and spatially um systems languages for for writing software in so rust was built because of browser design so there's all sorts of stuff that we take for granted

every day even outside of browser land you know if we're writing native applications for our phone we're going to be using a lot of the same Technologies as we would use in a browser and they came from this world and and so if we look at browsers both in terms of a product on on their own um and in terms of the technology that goes into them and why those things developed I think they're really interesting they're really instructive for us when we're building other systems so before we go any further I'll introduce myself um I'm Mark um I spent um about half of my security career working as a security engineer for one of the browser vendors

and I worked for Milla and I worked on Firefox and um as part of my work on browsers I did a bit of working standards so um pretty much every HTTP request any of your device makes um will go through stuff that I specified so I've got my grubby little Ms all over all your internet traffic um and some of the code in a couple of the browsers I worked on as well so um that's not to say that you should believe what I have to say Obviously verify any point that I'm making but I know a little bit about the the subject matter so let's think about um a browser from a sort of abstract let's build a

new product point of view imagine somebody your organization comes to you and they say we're going to build an application in C++ um we're going to load a load of untrusted information over the Internet um and uh it's going to have to handle a bunch of different security contexts where we need to make sure they can't um observe or interfere with each other and the input data is really complicated like there's all sorts of of non-trivial grammars that we're using to Define these data and by the way we want it to be able to execute arbitrary code by Design uh and it's going to be able to support images and video and and audio and fonts and all sorts of stuff right

imagine that Security review LS on your desk what are you going to say are you going to feel good about this no okay not seeing anyone nodding there like if somebody described what a web browser has to do to you as a to to as a potential new product you'd think they were mad like why would you build this thing it's doing all this stuff intentionally that is just mad and yet you know that's what we've ended up with and of course um not all of this came in one time you know this is the result of 30 odd years of development and um these features have evolved over time but the place we're in now with a modern browser

is incredible in terms of what ships it's incredible in terms of what it achieves from security perspective and again there's loads we can learn from that so just have a little think about some of these things start throwing out the first things that you'd think of as being worrying about this what's what's first on your list feel free to just shout something out untrusted source is an arbitary code okay untrusted source is an arbitary code yeah I'll tell you the thing that makes me most nervous you know 30 million lines of C+ plus you know how many how many defects per line of code for you to have a very very bad situation yeah there's all sorts going on here that is

really really really hard and it's incredible that the browser vendors can manage this um now I mentioned you know obviously this has been going on for a very long time and browser vendors haven't always done a very good job and one of my favorite web pages is the Wikipedia article on the origin policy because it contains a one sentence horror story Can you spot the one sentence horror story the same origin policy was introduced by Netscape Navigator 2 in 1995 shortly after the introduction of JavaScript what does that mean about what was possible in a browser between release 2 and 2.02 any script loaded from any origin can do anything with anything right and incidentally this is after they had

introduced SSL so there was this notion of secure traffic so you could carry out transactions and they didn't have a security model they Shi the feature and they're like oh yeah yeah we should probably secure this right and and it's not just the issues that happened by Design you know if you ship a feature like JavaScript and you don't have a security model um that's one thing it's quite another if you're dealing with lots and lots of code written in an unsafe language on an unsafe runtime okay and so you know think about the the early days of the web and how awful many of the security vulnerabilities that existed in the browsers that were coming at the time

you know think about the early versions of Internet Explorer um terrible terrible situation from a security point of view but it improved a lot over time now there's one really interesting thing that I was a little bit involved with in terms of where I was working that is quite instructive in in some of the things that we can do and how we can prioritize them and what constraints um lead us to make particular decisions and that was the introduction of of chrome the chromium project and what that meant for the development of Firefox which is the product that I used to work on um because when Chrome landed in when was it 2007 is um it was free from a lot of

the constraints that were plaguing the other browser vendors you know you had Microsoft with it's an expor you had Milla with Firefox um Apple were shipping um with webkit and um Apple were free of a bunch of constraints that the other people had um but if the point I'm trying to make here is that Google when they started the chromium project had a bunch of different constraints whereas Firefox had an old code base it inherited load from from um Netscape so some of the code was really really old while it had an older product while it had existing users Chrome had a new code base they fought from webkit and they were able to do a bunch of stuff with it

they had a new product they had new users and most importantly um Chrome didn't really have an add-on ecosystem at the time right Firefox had a lot of users that were very very invested in the customizations that they had applied and it meant that um a lot of the stuff that was possible in the chromium code base wasn't possible in the Firefox one so for example Chrome lands in 2007 and out of the box it's got a massive security innovation it's got um sandbo right they've got this notion of different processes where you've got the the main browser process and you've got content processes and those processes that manage content can be separated from each other right so you've got site

and origin isolation and um Milla couldn't do any of those things it couldn't do any of those things because Firefox users used their add-ons they loved them and they were very very tightly Bound in with the guts of the browser okay and so you couldn't separate the process and you couldn't separate the origins from each other but one thing that Firefox did have going for it was that the entire front end of the product was already written in a safe language but the browser engine itself was written in C++ but the browser front end was written in JavaScript um and then over time Milla did some work to first of all separate the processes there's a project called

electrolysis that separated the various processes um the browser to different processes following on from that there able to implement sandboxing it actually uses the chromium sandbox it's exactly the same code um and then they were able to introduce s and origin isolation so probably for um the past five years there's been decent feature par in terms of the security architecture between the two products but then Milla did another thing which was that they doubled down on the safe language thing and said right javascripts find for the front end what about all that really dangerous system code and that's where rust came in we'll talk about that in a moment and that's something that chromium is

still sort of thinking about they announced in January this year that you can now use um rust libraries within chromium but the core chromium codebase um is still written in C++ even though Google Now use rust for things like uh future OS and that sort of stuff okay so different constraints give you different opportunities and um the way Google chose to solve the problem they had was through some un boxing the proc process isolation so let's have a look at how this works um the technology varies depending on which platform you're using but um common among all of them is that a Sandbox achieves two things the first is that it restricts access to F system

resources so commonly there'll be something like separate users or separate user groups or something to allow you to do that and you also want to limit interaction with the underlying file system so system calls and that sort of stuff um the actual implementation is very very different um on Windows there are some um frankly inspired um subversive uses of um system internals that allow sunand Bing to happen it's mostly an accident of implementation it's certainly not by Microsoft's design but the the windows s box is a thing of um of of hackery and Engineering Beauty definitely worth looking at and on Linux you tend to make use of uh that exposed by the operating system and similarly with with Mac OS so

um for example both chromium and Firefox on Linux have one layer that um prevents access to resources that uses username spaces on recent versions of the sandbox and recent versions of the kernel and then you make use of set comp filter or set comp BPF it's sometimes called which allows you to um uh essentially restrict the use of the system calls that the browser has access to or that process but the key point I want to make here is the technology is only part of the story right a Sandbox can ensure that you've got the right boundaries you've got um strong primitiv for preventing isolated things from getting out but you need those boundaries in the right place

okay um so let's talk about that in a little bit more detail um there's a a really nice thing that came out of the the Google documentation on this stuff called the rule of two has anyone heard of rule of two before um rule of two is really simple it's says uh pick two of untrustworthy inputs unsafe implementation language and high privilege um any more than that you've got a problem okay so you can have an interest worthy input and and high privilege but it has to be in a safe language you know I'm not going to do all the permutations to get the idea right now the constraint that you have in the browser is that most of your

existing code base is going to be in C++ so you already know that b is true so you have no choice choice you have to have either trustworthy inputs or um you sorry you can only have untrustworthy inputs sorry you can only have um unsafe implementation language on one of the others as conditions that you've got right so you must separate A and C you must separate situations where you've got untrustworthy inputs and um high privilege um so I'm known for I think a couple of things in in the security scene one is for building robots another is ABX stuff and another is that I always have chickens in my demos and slides um so the energy

I'm going to use here is um think about your um environment and how you're going to protect the stuff that you need to protect so the naive approach is to say well we're just going to sandbox the stuff that we want to protect and everything's going to be fine um because you know the fox and the crows can't get the chickens in their eggs and that's all good except the problem you then got is that um your chickens can't get at what they need to get at they can't get at their food and they can't get at their water and you've got a problem so you can't just put your chickens in a box um well what if you

put um your boundary around the whole field um well the chickens can get their water and they can get to their food but unfortunately the fox and the crow can get to the chickens so that doesn't work so well think about this in um the browser context and think about what you're protecting and from whom so you're protecting the origins the um sites that your browser has access to from each other those have got to be um mutually um private and um free from interference you've got to separate the host system from everything the browser dealing with and you need to separate the browser profile from everything that the browser is dealing with as well and so the way

that tends to work is you have a a main process um it's broker in chromium speak it's called the parent process Firefox speak and then you have different sandboxes um which might be for uh different uh low privileged parts of the browser um implementation or they might be for origin or site processes um and these do the job of taking stuff that's untrusted and um uh potentially in forms that are difficult to deal with safely and translating them into something that's predictable and safe okay and then you provide a constrained interface between those things and the broker or the parent process and by doing that you can make sure that you can um satisfy your your

rule of two in each case so here we have um high privilege and trusted input um and an unsafe language here we have um low privilege and an unsafe language an uned input and say here so on and so forth right so that's what's going on there and and so the lesson here really is that you've got to think really carefully about your boundaries you got to think not only about the technology but also that you've got the right things in place now I put an asterisk next to unsafe implementation language earlier on the reason I put an asterisk next to it is because actually um it's a safe runtime that you need yeah so C and C++ running on bare metal

is not um safe because it's unsafe language on an unsafe run time um but there are other ways of of meeting the requirement of having um safe code um now going back to the constraints Milla didn't have the luxury of a clean slate they couldn't do what Google did with chromium and and just re architect everything but what Milla saw was that if you can't make fundamental changes you can still make um incremental changes that make a big difference over time and so what Milla did was quite a bold bet they said well we're probably going to have a Sandbox in a couple of years time and they did but in the meantime why don't

we start getting rid of the unsafe bits of code in the dangerous bits of attack surface in the browser and so um there was a project that had been started by a Milla employee at the time CH called Gren in about 2006 um Milla started sponsorship of this from 2009 and started building an entirely new browser experiment browser called Servo um in Rust and by 2017 um bits of that were good enough to start pulling into the Firefox code base so Stylo which was the style engine from that Servo browser made its way into the Firefox code base um in 2017 interestingly as I said earlier on chromium has started to make use of rust

in the Chrome code base as well chromium Chrome Edge Etc and but one really nice thing about the the implementation of Silo in Firefox was that it got rid of huge suedes of C++ code and made it load safer but that isn't even why they did it right the reason why they decided to move the style engine from Servo into Firefox was because um there was a really nice Innovation which was that the Stylo engine allowed for concurrent styling parallelism in The Styling engine which was made possible because rust is not only um spatially memory safe but also temporarily memory safe right you can WR multi-threaded code and have guarantees over the safety of that

code which means that you can make use of concurrency in a way that would be a real problem in CN C++ code so they actually did that because they wanted the performance and the responsiveness as a side effect it eliminated an entire class of security bugs from that part of the code base which I think is quite cool and I think a really good lesson you can learn but there's another way of getting to safety and and again it comes back to the difference between a safe language and a safe runtime which is that actually browsers have got a safe way of executing code built in because of that requirement you had at the start of

being able to execute in trusted code right the um JavaScript engine um yeah that there are flaws in implementation from time to time but it's intended to do that job right um it is built for that use case and so by making use of technologies that are built on top of the um JavaScript um environment and the jit that JavaScript uses so for example WM you can actually make use of that to do interesting things with your code base so um one thing that Milla did was a a project called RL boox which is where you take um libraries that you don't know whether or not you can trust um you build them from their um unsafe

language to a wasm Target and then you run that that wasm Target within the browser and then if you've got a bug in that code um it can't own the browser because it's sat in a wasm engine right and firef actually shipped with a bunch of these and there's a delicious irony here which I'll get to in a moment but that's a cool thing so let's move on to recent news um lib webp anyone been following that story okay um it comes back to the fact that like no matter how how hard you try with a code base that's written in anafe language you're going to have problems from time to time okay in the last week we've had

two really really serious issues where some of the best engineers in the world have failed to write safe code so Li webp is one example webp comes from where Google research right Google is a pretty darn good programmers I know a few of them they're smart um and then um vpa one of the codecs that ships with webc again it comes from Google Google is pretty darn smart right and if some of the sarst programs in the world can't write C++ code what hope do the rest of us have and the answer to that is absolutely n right um and um over time you're going to have problems um we can take steps to replace

the um visible attack surface with stuff like rust but that's going to take time and so there's a really really important thing here around how well you respond to the problems that you have okay and webp is one example I'll talk about a bp8 thing in a moment because I heard something this morning which I thought was absolutely incredible and was a good story okay um so my delicious I on you early on with that RL box thing if you go to mdn which is the Milla developer Network and you look at wasm look what library they use to illustrate how cool wasm is so wouldn't it be cool if they' actually used a RL boox version of lib

webp instead of the Native one they wouldn't have had to do one of their two chem spills last week I just thought that was quite funny like what are the chances because that article is years old brilliant anyway the other thing I wanted to talk about was this obviously the browsers were affected by the web PE thing um electrons affected by the webp thing as well who uses anything that uses electron so what we got Visual Studio code signal whatsa uh one password um a Sana Miro loads of stuff like basically half of the desktop applications out there these days are using um electron and electron is a um it's a crime against chromium is my

joke um like let's take chrom let's remove half of the security features and then let's ship it to everyone's desktops without good update mechanisms and to illustrate this what I've done is you know I've um deliberately chosen a script here which doesn't give away who I'm you know I'm not going to shame any individual company but I updated all of the electron apps on my laptop yesterday and then I ran a little script I'd written to pull the electron version out of the binary um thinking about the web P vulnerability these are the three versions of electron that are safe from the live web P floor and this is what's installed on my machine now Chrome 83 is

ancient yeah and only one of these sorry only two of these are not vulnerable to the web P floor and only one of them isn't vulnerable to the vpa floor okay so again on horror stories that's a horror story in one screenshot okay now going back to my earlier Point there's always going to be vulnerabilities you're always going to have problems and this is kind of the point I want to make about this um when the vp8 floor was announced there was um a bit of embargo work that went on between the browser vendors and people that consumed that library to make sure they've got a response for it um the the team working on this at

Milla were given a reproducible test case in chromium and they had to extrapolate whether it was exploitable and what the relevant fix was in Firefox they they did that they developed a fix and they're done an an emergency release within 17 hours of hearing about the problem okay how old is Chrome 83 how old is Chrome 100 how old is Chrome 102 um this version of electron is 4 days old and only has one of the two critical vulnerabilities that released this week um yeah so one out of the eight applications isn't vulnerable to Li web P okay so to to finish up hope you've learned something the first thing I hope you learn is that it's possible to fix

big problems um I'm presenting this from my browser I'm glad that it has the same origin policy um it's a shame it was bolted on after the fact when they invented JavaScript but there have been bigger problems since the second thing is that a really important part of secure design secure architecture is thinking about your boundaries not just what the boundaries are but having them in the right places um the next lesson is incremental changes add up over time the next is that language Choice matters please please please stop writing safety critical code in unsafe languages if you have to write safy critical code in unsafe languages please try and find a way of protecting it and look for

aligned incentives very often the biggest security wins you get are by riding on someone else's coattails so if a security win is also a performance win rewriting this in Rust will make it 10 times faster it might uh do that and finally don't trust people that ship browsers and don't put in the security work electron is a crime against chromium and you can quote me on that so there go I'm Markin I talked about browser stuff and you can find me there thank you