What Your Browser Can Teach You About Secure Design - Mark Goodwin

are you all having a good day yeah yeah come on okay so I'm Mark um I in a former life was a browser engineer these days I look after technical security for a company called causal and I'm sort of talking a little bit about my my former life because um it's one of these areas that that um I find fantastically interesting how much of what we do day-to-day as Security Professionals comes from browsers and so you know hands up anybody got any ideas on things that you use day to-day that came from the browser World throw things at me not literally TLS anyone use TLS yeah that was a browser thing wasn't it that was

introduced by Netscape um JavaScript that's a browser thing yeah oh moving on from that how about wasm wasm a runtime that came from browser stuff anyone got a bug Bounty program where did B programs start yeah browsers what about um type safe and memory Safe Systems languages rust was literally invented to build a browser yeah how about sandboxing and consumer products browsers right so there's loads of stuff that we use every single day as Security Professionals you know the foundation of lots of the technical parts of our discipline that came from the development of of one family of products right and that's kind of interesting isn't it or or am I you know way off here is it interesting I think

it's interesting you think it's interesting okay and um all of these things didn't come at once right browsers have been around for a long time and if we're honest they didn't start well I'm not really good with clickers and stuff I talk for too long well done Scott help oh there we go we're back we're back in the room okay um they had a pretty in auspicious start and you know it's not surprising because think about what browsers do right imagine you're um going to design a computer system and somebody comes to you with the requirements and says you know I need you to help me secure this thing um I'm going to I'm going to write

it in C++ um the input uh comes over the internet from interested sources um we've got loads of different contexts right you know different things that aren't allowed to influence each other or read each other's data is that all right uh oh by the way the input data it's going to be badly formed and you still got to deal with it you know um and we want it to by Design be able to execute arbitary code um and what point here do you say actually no that building this is just a really really bad idea yeah because you would wouldn't you someone came to you with that and said here here's what I'm going to do

and You' be like no no just go home and so it's not surprising when um people had problems with early browsers this is one of my favorite sentences on Wikipedia about the same origin policy in browsers do you all know what the same origin policy is so same origin policy is the thing that stops one website from being able to read or influence what's going on on another site okay it's you sort of the foundation of the web security model the concept of the same origin policy was introduced by Netscape Navigator version 202 in 1995 shortly after the introduction of JavaScript in Netscape 2 so there's a horror story in two sentences right they built a thing and then they built the

security model right and this tells us something really interesting about browsers they' built these things that are hugely complex they're runtime they're the operating system for for modern distributed applications essentially and they built them basically by trial and error so what I'm talking about now is how could we learn from this right because we all work in messy environments where nothing's perf to start with what can we learn about how they've designed and built these things that helps us in our everyday jobs so that's what this talks about long introduction but that's basically what I'm talking about and I'm talking about it from the perspective of a former browser engineer I worked on one of these two things and if you've used

either you youed my stuff but um they had very different approaches to Security in the last 10 years right actually last 10 last 15 years because when chromium came along the chromium project first first started it was brand new it was a new codebase it was a new product it had its own set of um new users that weren't used to doing things in a particular way and there was a whole new add-on ecosystem right Firefox on the other hand had the problem that there was an old code base some of that code had been in there since um Netscape nav navigated actually know some of the codebase came from NCSA M right so it's

an old code base been around for donkey years loads of people that loved it in particular they loved the add-ons that they used and they were going to be really upset if you broke them and there was a large existing ecosystem where loads of people were heavily invested right and so um when Chrome came along he could do stuff that the other browsers couldn't right and and this was true of safari and Internet Explorer at the time as well so they could do things like sandbox processes they could separate the processes they could have um different Origins isolating their stuff within a particular context um and so um Milla when they looked at this I thought well we can't deal of that

stuff what can we do instead that gives users a similar level of safety but without these head starts and over time they caught up on a few of them but the big thing that that Milla did and this is a brilliant thing and I will go on about this as long as you like another time um they literally invented a systems language to help them safely do a load of these things we'll get to this in a bit more detail in a moment but rust is a thing that they did they said okay if we build things such that we can eliminate a class of security bugs we can provide equivalent safety without some of the stuff that the competitors

are able to do and then they caught up on the other stuff as well and as as inside chromium has now just started accepting um rust code in the chromium tree which is you know good news for everybody um Google are picking it quite hard on on Rust at moment which is good okay so let's talk really briefly about sboxes who's heard of a sunbox before okay so the the the short version here is um the technology varies from platform toat platform but the idea basically is that you can use underlying operating system Primitives to make sure that different things are restricted in what they can do okay so you can restrict access to the file system you

can restrict access to the network and you basically architect your product such that different parts of the product are allowed to do different things okay so you might have a Content process which is allowed to talk to the origin server and get stuff and it can run things but it isn't actually allowed direct access to the screen or to the webgl driver or you know the audio subsystem or printers or or things like that right um and then you can um also like I slight the stuff underneath the technology isn't the whole story right so you know uh I can refresh my memory and go into detail on how load of this stuff works I've done a load of it on

Linux before but the key thing here is that you've got boundaries and that ow things to happen and this is a really nice graphic that I stole from the chromium um documentation which talks about this idea insecurity called the rule of two has anybody heard of this before yeah okay so the rule of two basically says um there are three things right there are um unsafe um IL defined inputs there are unsafe implementation languages like C and C++ for example and then there are high privileged things right and you can pick any two right if you pick three you're doomed now you'll notice that that the middle of that um V diagram there well that's where browsers

live okay so you inherently need to do all three of those things so how do you rearchitecturing

the chicken example I've got some chickens at home and the problem with chickens is that they need to eat and drink and also they get uh eaten um so you don't want your chickens to have um unrestricted access to outside because otherwise the foxes will eat them and the crows eat their food um and you don't want to keep them inside all the time because otherwise they can't eat and they can't drink right so what do you do um well maybe you just let them go outside we'll know CU then they get eaten and it illustrates the point that you know actually you've got requirements here you want to be able to isolate things such the chickens can get

to the food um but that the fox can't get to the chicken right really really dumb example but it's a simple worked example you know we need to satisfy these constraints and in browser land it looks a little bit like this right you think about what you're going to protect from whom so for example your content processes need to not be able to see each other we talked about the same origin policy a moment ago your host system needs to be protected from the stuff that's running in the browser you shouldn't go to example.com and have your system owned um and the browser profile so all the secrets that you keep and your cache and

all that sort of stuff wants to be well protected and you can do this by having various different processes that are isolated and you set up an interprocess communication mechanism between them which allows you to to S side step from the unsafe inputs thing because you've defined the IPC language yeah you can sidestep the whole issue of elevated privilege because only the things that have got access to the important stuff has access to important stuff and you manage the Rest by you know defining the communication between those things right sounds easy actually it's quite hard in practice and you find lots of things like we need to find a safe way of accessing this thing because we need to

be able to expose this functionality um but there's inherent danger there and all that sort of stuff so that's basically what's going on here but it's not the only way to do it okay remember you've got your rule of three and saafe inputs and interested language and high um you can meet your rule of two by getting with another thing and you know going back to the Firefox versus chromium thing the Milla approach was let's make an alternative to the unsafe languages let's say this code has got to be secure let's not use C++ anymore because friends don't let friends use C++ okay so Milla started sponsoring the r project and now like practically everyone is using it for their system

stuff unless they want their stuff to get hacked um one of the really nice things and this is one of the takeaways I want you to have from this talk is that um actually you win in ways that you don't expect right the thing that managed to get rust code into the mainstream code base in Milla was not security it was with the introduction of fir Fox 57 there was a load of The Styling engine came from their experimental browser called Servo uh that was ported from Servo into Firefox and that was written in Rust and the thing that allowed the browser Engineers to do was to have the L engine working um in a parallel um way

rather than sequential which meant that loads of stuff could happen at the same time that previously used to take a long time so the thing that made Firefox a huge amount sa for around 5 57 was a performance thing with security benefits and not the other way around so the lesson there you know what can it teach you about secure design look for aligned incentives you know find the people that can help you in your quest to make a system more secure and help to push those aligned incentives um so I talked about wasm and JS already did you know you can build your native code to run in a wasm run time probably do you might have used

things like ajs and that sort of stuff before you might have used um the clang targets that'll Target a a wasm back end that sort of stuff um turns out you can build the vulnerable bits of your browser to run inside that uh en as well so one of the experimental things that happened a while back was Engineers started building unsafe codecs and stuff such that they ran inside the wasm run time within the browser our lbox was an experimental thing that they did at Milla for a while before they realized that actually probably just rewriting L rust was a more performant way to go um an example of this sort of thing working really

well does anyone remember like the webp vulnerabilities that happened about a year ago maybe six months that yeah um I remember this at the time it was quite funny for two reasons the first was that it's one of these cases where the browser vendors all share the code and despite the fact that they don't have the same code base they all all end up the same vulnerability um because they were all using the same web RC code right um the other thing that really amused me is that literally if you went on to um the Milla developer Network which is what Google and Milla use for documentation the example on compiling C module to web assembly

was web P isn't that brilliant delicious ironing right and so had they been running this within that safe run time they wouldn't have been vulnerable to that particular floor but they didn't so they were but there's an example that they'd already got on how to do that which I thought was just great okay um so that's a little bit about browsers um talk a little bit about chromium talk to a little bit about Firefox where else do you use a tech anyone use slack yeah do does anyone use GitHub desktop anyone use Microsoft teams anyone use uh vs code yeah what are all these things based on what's what's the the common theme Here electron okay so thinking about

that webp thing um I did a bit of research around the time that happened because the browsers sort their stuff you know pretty well these days when there's a zero day reported in the browser you can expect the team to have a fix for it in a few hours the point stuff last week the Firefox team had a fix out in in four hours which I thought was pretty pretty hot okay um when the LI WEP thing happened this is what electron versions um and corresponding chromium versions for stuff that was running just on my Mac were so uh I I think only one of the electron apps I had on my machine was not vulnerable to that floor okay

and one of the issues with electron is that you get all of the attack surface of a browser maintained by people but don't understand that yeah so my advice is if you've ever got the opportunity you ever got the choice between using the browser version of something and using the electron version run like the wind away from the electron version okay so there we go that's what we learned we learned that it's possible toix big problems because like web security didn't exist until after JavaScript which is a terrifying sentence we've learned that uh boundaries are good but you got put in the right places I can't remember what we've learned oh yeah incremental changes add up over time language Choice

matters if you're writing code that needs to be secure please For the Love of All Things good do not use C++ or C okay um look for aligned incentives other people can help you reach your goals and don't trust people that ship browsers and don't put in the work to keep them secure uh thank you very much