Attacking Chrome IPC

Video thumbnail (Frame 0) Video thumbnail (Frame 1418) Video thumbnail (Frame 2578) Video thumbnail (Frame 3728) Video thumbnail (Frame 4764) Video thumbnail (Frame 6420) Video thumbnail (Frame 9175) Video thumbnail (Frame 12175) Video thumbnail (Frame 13759) Video thumbnail (Frame 15114) Video thumbnail (Frame 16806) Video thumbnail (Frame 18659) Video thumbnail (Frame 20017) Video thumbnail (Frame 23036) Video thumbnail (Frame 28279) Video thumbnail (Frame 32198) Video thumbnail (Frame 34640) Video thumbnail (Frame 38088) Video thumbnail (Frame 39136) Video thumbnail (Frame 41286) Video thumbnail (Frame 42331) Video thumbnail (Frame 50905) Video thumbnail (Frame 57201) Video thumbnail (Frame 59505) Video thumbnail (Frame 74292) Video thumbnail (Frame 76111) Video thumbnail (Frame 77311) Video thumbnail (Frame 79157) Video thumbnail (Frame 80386)
Video in TIB AV-Portal: Attacking Chrome IPC

Formal Metadata

Title
Attacking Chrome IPC
Subtitle
Reliably finding bugs to escape the Chrome sandbox
Title of Series
Author
License
CC Attribution 4.0 International:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
2018
Language
English

Content Metadata

Subject Area
Abstract
In this talk, I discuss how to reliably find bugs in the Chrome IPC system with the goal of escaping the sandbox. I show how to enumerate the attack surface, how to identify the weak areas, and how to fuzz those areas efficiently to consistently produce bugs.
Keywords Security

Related Material

The following resource is accompanying material for the video
Video is cited by the following resource
Mobile Web Graphical user interface Process (computing) Roundness (object) Computer file Weight Surface Order (biology) Musical ensemble Interprozesskommunikation Vulnerability (computing)
Graphical user interface Graphical user interface Interprozesskommunikation Power (physics)
Nintendo Co. Ltd. Graphical user interface Vulnerability (computing) Graphical user interface Multiplication sign Sound effect Energy level Mereology Focus (optics) Exploit (computer security) Software bug Vulnerability (computing)
Statistics Touchscreen Link (knot theory) Software developer Projective plane Plastikkarte Graphical user interface Emulator Chain Hacker (term) Kernel (computing) Computer hardware Internet forum Videoconferencing Website Website YouTube YouTube Surjective function
Presentation of a group Slide rule Expert system Mereology Expert system Exploit (computer security) Interprozesskommunikation Software bug Number Graphical user interface Process (computing) Strategy game Chain Fuzzy logic Information security
Observational study Feedback Projective plane Feedback Expert system Expert system Software bug Number Wave packet Arithmetic mean Order (biology) Process (computing) Pairwise comparison
Scale (map) Graphical user interface Sign (mathematics) Graphical user interface Multiplication sign Right angle Disk read-and-write head Software bug
Code Software developer Code Expert system Mereology Login Software bug Wave packet Component-based software engineering Crash (computing) Strategy game Blog Library (computing)
Pattern recognition Computer file Block (periodic table) Wage labour Range (statistics) Code Wave packet Software bug Component-based software engineering Process (computing) Blog Revision control Process (computing) Traffic reporting
Functional (mathematics) Slide rule Quantum state Strategy game Mixed reality Multiplication sign Blog Integer Buffer overflow Software bug Vulnerability (computing) God
Metric system Computer chess Perfect group Process (computing) Mapping Connectivity (graph theory) Binary code Social class Binary file Game theory Software bug Wave packet
Computer chess Slide rule Perfect group Observational study Multiplication sign Mereology Software bug Chain Graphical user interface Population density Strategy game Read-only memory Interpreter (computing) Kernel (computing) Library (computing) Operations research Computer chess Surface Code Maxima and minima Binary file Graphical user interface Personal digital assistant System programming Fuzzy logic Social class
Complex (psychology) Code Feedback Multiplication sign Real number Connectivity (graph theory) Disintegration Compiler Mereology Computer programming Area Software bug Revision control Natural number Software testing output Implementation Address space Vulnerability (computing) Execution unit Meta element Projective plane Feedback Code Unit testing Exploit (computer security) Parsing Process (computing) Logic Personal digital assistant Formal grammar Normal (geometry) Fuzzy logic output Software testing Escape character Electric current Library (computing)
Code Multiplication sign View (database) Equaliser (mathematics) Stack (abstract data type) Mereology Database transaction Software bug Mechanism design Graphical user interface Strategy game Semiconductor memory Kernel (computing) Information security Block (periodic table) Open set 10 (number) Web application Process (computing) Volumenvisualisierung Website Escape character Information security Sinc function Reading (process) Mobile app Computer file Similarity (geometry) Cursor (computers) Canonical ensemble Web browser Graph coloring Interprozesskommunikation Touch typing Authorization Software testing Integer Traffic reporting YouTube Exploit (computer security) Inclusion map Graphical user interface Cache (computing) Kernel (computing) Software Personal digital assistant Fuzzy logic HTTP cookie Buffer overflow
Email Functional programming Randomization Group action Parsing Serial port State of matter Code Multiplication sign File format Parsing Mereology Software bug Formal language Telephone number mapping Uniform resource locator Type theory Strategy game Kernel (computing) Logic Fuzzy logic Formal grammar Physical system Source code File format Computer file Abstract syntax tree Type theory Googol Sample (statistics) System programming output Pattern language Problemorientierte Programmiersprache Encryption Dependent and independent variables Variety (linguistics) Interprozesskommunikation Latent heat Software testing Data structure output Communications protocol Message passing Traffic reporting Server (computing) Interactive television Code Computer network Web browser Kernel (computing) Software Personal digital assistant Function (mathematics) Network topology Communications protocol Abstraction Library (computing)
Execution unit Trail Feedback Disintegration Code Bit Expert system Graphical user interface Mechanism design Latent heat Graphical user interface Encryption Fuzzy logic Physical system
Source code Context awareness Code Code Web browser Content (media) Coprocessor System call Web browser Interprozesskommunikation Cartesian coordinate system Software bug Graphical user interface Graphical user interface Process (computing) Kernel (computing) Volumenvisualisierung Iteration Process (computing) Endliche Modelltheorie Information security Hydraulic jump Physical system
Email User interface Code Parameter (computer programming) Client (computing) Mereology Software bug Uniform resource locator Mechanism design Graphical user interface Bit rate Strategy game Process (computing) Fuzzy logic Information security Physical system Source code Software developer Computer file Bit Type theory Message passing Process (computing) Oval Volumenvisualisierung Thumbnail Escape character Physical system Resultant Asynchronous Transfer Mode Filter <Stochastik> Point (geometry) Surface Digital filter Mobile app Functional (mathematics) Implementation Inheritance (object-oriented programming) Computer file Open source Line (geometry) Letterpress printing Maxima and minima Web browser Content (media) Interprozesskommunikation Term (mathematics) Implementation Message passing Traffic reporting Computing platform Dean number User interface Execution unit Surface Content (media) Code Web browser Graphical user interface Cache (computing) Fuzzy logic Object (grammar) Library (computing)
Polar coordinate system User interface State of matter Multiplication sign Execution unit Source code Open set Disk read-and-write head Mereology Software bug Graphical user interface Semiconductor memory Different (Kate Ryan album) Process (computing) Fuzzy logic Presentation of a group Email Streaming media Message passing Process (computing) Oval Order (biology) output Arithmetic progression Physical system Surface Random number Server (computing) Dependent and independent variables Codierung <Programmierung> Disintegration Web browser Code Interprozesskommunikation Chain Cache (computing) Iteration Software testing Implementation output Message passing Traffic reporting Noise (electronics) Dependent and independent variables Server (computing) Computer network Interprozesskommunikation Web browser Cache (computing) Pointer (computer programming) Software Fuzzy logic Social class Iteration Object (grammar)
Server (computing) Dependent and independent variables File format Interprozesskommunikation Sequence Revision control Latent heat Cache (computing) Root Queue (abstract data type) Energy level Fuzzy logic Message passing Loop (music) International Date Line Condition number Fundamental theorem of algebra Dependent and independent variables Server (computing) Interprozesskommunikation Sequence Abstract syntax tree Logic synthesis Type theory Message passing Network topology Synchronization Task (computing)
Email Greatest element Parsing State of matter Code Multiplication sign Source code Execution unit Determinism Set (mathematics) Primitive (album) Parameter (computer programming) Mereology Software bug Leak Uniform resource locator Duality (mathematics) Pointer (computer programming) Semiconductor memory Fuzzy logic Descriptive statistics Physical system Covering space Source code Email Software developer Computer file Open source Bit Unit testing Thread (computing) Type theory Message passing Chain Volumenvisualisierung Freeware Booting Mobile app Game controller Server (computing) Functional (mathematics) Service (economics) Computer file Open source Dependent and independent variables Control flow Web browser Code Metadata Interprozesskommunikation String (computer science) Intrusion detection system Energy level Data structure output Message passing Booting Address space User interface Context awareness Execution unit Dependent and independent variables Standard deviation Slide rule Server (computing) Interactive television Memory management Code Operator (mathematics) Counting Field (computer science) Computer network Line (geometry) Interprozesskommunikation Leak Exploit (computer security) Web browser Cache (computing) Graphical user interface Uniform resource locator Word Pointer (computer programming) Moment of inertia Software String (computer science) Factory (trading post) Network topology Synchronization HTTP cookie Object (grammar) Table (information) Fingerprint
Multiplication sign Code Process (computing) Resultant
Line (geometry) Streaming media Number
Graphical user interface Code Internetworking Projective plane Web browser Library (computing) Software bug Wave packet
Graphical user interface Code Cartesian closed category Energy level Musical ensemble Semiconductor memory Cartesian coordinate system Software bug
[Music] and now net williams talk at checking chrome inter-process communication reliably finding bikes to escape the chrome sandbox he will be talking about finding books in the chrome and process communication in order to escape from sandbox using a filing method to enumerate the attack surface of the chrome in the process communication net is a vulnerability researcher he likes CNC plasters vulnerabilities did research for consoles and browsers and now started to work on mobile devices please welcome huge round of applause
all right hello everyone
yeah my name is Ned and today I'll be talking about chrome IPC and actually as I was writing this talk I kind of camp with this idea to make it more useful to everyone and the way I ended up doing this was by trying to start really general and then kind of going more and more specific all the way down to the chrome eyes i pc fuzzing so if you're really technical the end will be still interesting and then if you're new to this stuff hopefully the beginning power will show some of how to get started so just a quick overview about me if mostly
been spending the last several years on a low level vulnerability research and my particular interest is on any kind of critical bugs meaning kind of the more severe the individual bug like the more interesting to me so I'm trying to kind of solve this problem of you know how do we make the bug finding process effective enough to bring out needs like really rare hidden bugs and you will see an example of how to do that by the end but just an overview like I've basically worked on four things the first being CTF then went to 3ds and chrome now I'm starting on xnu but just a month ago so not too much yet before we get into it I just
wanted to give a little recap of what happened since last time so I was part of the Nintendo hacking talk two years ago here and I presented two exploits
called sound hacks and fast acts and not to go into it too much but I did want to share like what happened here because I was actually surprised I put Google Analytics on the sound hacks website and I thought like you know maybe a thousand people use it or something but I just looked at the stats like a couple weeks ago and then turned
out like 800 K people use it or something and then I searched YouTube
and found like these huge videos where they were copy so like I want to have a screen shot but it's copyrighted so didn't do that but basically it looks like you know something on the order of about a million users which is crazy because this is one of my intro projects really so I think like you know this should show you that you don't have to be all the way up onto Chrome or whatever it is to get into this and do some huge fun project and then I just wanted to publicly talk about the donations because I had a donation link on the sonnax website and we fortunately received about a thousand dollars in donations and then half of that went to the emulator people because they that's how I eventually wrote my exploit for that asan hacks so it made sense to repay that and then the other half went to buying switches for like the toolchain developers who couldn't afford it and so just wanted to thank
everyone who used this or whoever donated just shout out so we'll get into the actual meat of the talk so basically I want to focus on the bug finding
process not exploitation necessarily because this topic is pretty well explored I think and I think the bug hunting aspect is kind of what's the most prohibitive for people to join in and when I look at the number of people who I play CTF with who are really good at exploitation and then a number of like these prolific bug hunters it just seems like from what I see from how smart people are there should be more people doing the bug hunting and I hope that if I can talk about it more people can come over so with that the agenda will be just you know overall how do you make a process to achieve any goal then next how do you apply this kind of some kind of strategy to bug hunting then this new fuzzing style I've been kind of developing some other people out in the industry I've been working on and then finally how does this all tie back to crow my PC also just to mention I should mention that the the bug I'll be showing in this presentation was used in a full chain exploit that I developed with a couple other people and the details of the exploitation of that will be discussed at offensive cons so that's also here in Germany and hopefully people check it out so how do you become an expert at anything and I kind of was thinking this before I even started anything and I was like in the CTF stage and I was just kind of curious like if I approach this with the mindset of there's this arbitrary skill I want to learn and if I
approach it strategically like what's gonna happen so I looked into this expert research and then there's kind of this idea of pop psych like you need to
study something deliberately for 10,000 hours to get good at it and you know there's some debate about you know this number it's kind of made-up I guess but the essential idea of deliberate practice I think is very useful and it's exactly how I structured my my studying and so what deliberate means is when you're learning you want to be thinking like purposefully like I want to make sure that the project that I'm doing is making me get better I want to be actually thinking about how I'm structuring my training and then you want to make sure that you're kind of always struggling because that's just how you're growing so essentially to do this you just need to keep picking projects that have some like success and failure feedback mechanism that's tied to the real world and you know with bug hunting like this is very obvious you know you're either finding a bug or not and like as I mentioned you want something difficult but achievable and so this kind of order that I did the different projects I mentioned the beginning was like specifically chosen so that each stage would be achievable to me but also like really really stretching what I could do and there's a funny antidote there's this guy named Ben Franklin from American history and I read the story that he used to be really bad at writing and wanted to get better so the way he did it was he took an essay that looked perfect to him and then he took notes on it and then a week later he rewrote the essay from the notes and then he would just compare the goal versus what he had done and basically saw all the shortcomings and so that kind of just
stuck in my head and so I'll show like how do you apply this kind of trick to bug finding practice and then just another thing with setting goals for bug
hunting a lot of it is psychological I think it's almost psychological more than intelligence like for sure and basically you want to iteratively pick harder and harder projects so that your tolerance for failure goes up and up and so by the time I was working on Chrome I worked on it every day for six months like right home from work until 1:00 a.m. sleep up and then all day every weekend and found nothing the whole time and then just one day I found something and then from there all that accumulated like struggle and effort when the bug precipitated it was just like a sign that all these like necessary skills were there and then I was able to repeat it and so so now I'll talk about what
that actually looked like for bug hunting so when you think about how to
train the skill I think there's kind of two constituent skills that are important and those are knowing where to look and then recognizing the bug when you're looking at it and this first part
is just from my own experience it seemed like just being a developer it's pretty easy to get a sense for you know you can look at the get logs like I'm mentioning here you know Arthur crash is happening somewhere in the library our bugs getting reported you know publicly does the code look bad you know it's not hard to tell that something looks sketchy but I think what's really hard is getting the bug to kind of come out and so that's where I'll talk about strategy kind of directly and so I kind of have
this training idea where essentially once you have this kind of target in
mind where it's a little bit out of your skill range but you think it's doable you try to enumerate all the existing bug reports and then look through each of them and then this is this like Ben Franklin idea like you take the bug and then you look at usually there'll be like you know this block of text and they're mentioning like the file where it's happening and stuff and you can kind of skim it and sense like where the bug is and so we know without actually looking at what it is and so then you go over and you try to find it yourself and you know it's really important that you actively try to look for the bug yourself and kind of strain yourself and when you've given up essentially then you look at you know what was the bug and then through that struggle it's usually pretty clear like what was the fundamental thing you were missing and you know just by repeating this process constantly this is how you train and so this is actually how I first ever
started on bug hunting was you know some
of you may know you he's this like really talented researcher he's been at it for a long time and I remember seeing this blog post from him showing all these ida pro bugs and it just kind of blew my mind like wow someone took ida and found like security vulnerabilities in it and then when I looked at the bug reports they're pretty small so I thought okay how do I practice and how could I have done this myself so basically the first day you know they're all like integer overflow bugs I could barely even like I knew what inter integer overflow was but I hadn't like
actively looked for it before and so I was looking at the function and I couldn't find it and basically I went to sleep feeling like oh god like I'll never be able to do this stuff and then the next day I looked it again I was like oh yeah that's actually easy and then kind of filled the second one and then kind of by the third day I was like able to just see where they were once you know I knew where to look so that kind of made me think okay I'll just keep doing this for a long time and keep doing harder and harder so this is essentially the strategy like I think
you know I'm probably the perfect example of someone who's like an intermediate CTF player really like insecure whatever like and just you know wanted to get into this but I had no idea what I was doing and I just kept thinking if I just believe in this kind of process you know hopefully it works out and so here's just like a little really basic road map if you want to try to replicate what I did which is to focus on CTF because if you can do CTF binary problems these are perfect examples of the kind of training where you try to do something yourself there's a write-up and like once you can do these problems you know all the kind of low-level details that are needed you know you know what a bug is things like that and then from there you just kind of progressively do harder and harder targets and so there's kind of this
component where like you know I don't you can't really assess your own ability like how much of this is innate or something and it just seemed to me that
regardless of that you know this like I'm staying here you know this isn't chess where you have people like trained from birth with like perfect study and like decades of you know like we're barely figuring this stuff out and it's just kind of a huge mess and so there's plenty of room for new people to join in and then also like there's a lot of these kind of stories about people who are just insanely naturally gifted and stuff and I tried it really hard to like look into what these people are actually doing and I haven't found a case where someone wasn't working extremely hard and so you know just keep that in mind so just for the sake of time I won't go into this too much but if you're looking at the slides later I just kind of give more detail on like how pick the mini-projects and got down to chrome so now let's talk about fuzzing and so before I get into it I should emphasize that you should really know how to do auditing and the first couple of years and like not until into that six months of failure on Chrome you know I was doing auditing the whole time and I think fuzzing gets a bad rap because people think that these are unrelated strategies and people are only a fuzzer person or an auditor person and really I think these things are extremely like they work really well together but you can't really know why fuzzing is failing or how does it even apply it or where to apply it without being able to audit yourself and part of this was like I noticed on chrome that I could audit things but they're essentially the bug density was so low in the sandbox attack
surface that I needed a way to kind of automate what I was looking for in each each subsystem was looking at so you know you have like 20 subsystems that you want to read well you know it takes about a week each minimum to learn it's a lot faster to try to fuzz for like a day or two each thing and then I don't know like it's I I can't explain that it just did random things and then this is what worked so so how would you practice fuzzing it's really the same idea that I
had about all I thing where you take a bug and just ask yourself like how would I have written a fuzzer in the first place to write to hit the bug how could how could I have known to write the fuzzer that would have triggered this you know am i lacking something in auditing ability am I not able to write fuzzers well enough and it actually took me probably like a year of of fuzzer writing to get good enough where I could actually act on my ideas like just it's it's kind of tricky and so we'll get back to it later but this exact idea of practicing fuzzing on something that looks on possible is how I found this real exploitable sandbox escape so really quick just for those of you who don't know too much about fuzzing at least in like the current meta essentially there's this tool that called AFL that came out in 2014 which I think really shifted how well fuzzing worked and the ideas essentially that you have some corpus of inputs that you want to fuzz and then as you're mutating them you're looking for coverage feedback which is compiled into your code and then as you're mutating and running new test cases when you find new coverage you take that input and put in your corpus and over time your corpus kind of grows and grows as more coverages hit and so there's this just seems to work really well and then there's another version of this basically called Lib buzzer and this is just written by the LOV n project and the same people who wrote address sanitizer also wrote Lib buzzer and just in my experience it's written in a way that's a lot more extensible and like easy to understand and play with and so it makes it kind of easier to audit and fuzz together and so you know if you want to think about what fuzzing is essentially you're trying to replicate the normal testing process but kind of parameterizing like what a unit tests would be doing with some input bytes that you're just feeding into something and saying if it crashes and so what's interesting is there's kind of this gap in the middle of like an end-to-end test which if I will give you just freedom binary or like the unit test which live buzzer will give you where you just keep stuffing bytes into a parser and real security vulnerabilities are kind of logical in nature and I think that's why people think that fuzzing isn't applicable and I think there's actually kind of this part in the middle where if you see a few components that look suspicious and
then you can integrate them and fuzz of them in isolation but have the complexity that you'd kind of see in the real program that's where a lot of bugs come out and so how we do this is using grammar and so essentially it's combining generative fuzzing with
coverage guided fuzzing and so we'll touch on how that works in a minute but just for some more evidence on you know why does this work well like I'm not the only person who is doing this kind of simultaneously myself and to two other people I guess seem to have stumbled across this idea last year two years ago and those are says collar and loci heart so says color is a kind of fully automated Linux kernel fuzzer and if you guys haven't seen this it's kind of hilarious like essentially they are automatically generating zero-day bugs like tens per month at least and they automatically generate the test case like submit the report when the commit comes in it's like automatically tracks it's basically the zero day generator sitting there and yeah I know I see this I'm like okay there's 3000 the bugs that are being found there's a web app for it and you can just download it away you know and I saw the Linux talk from the author of this collar and the YouTube videos like 100 views and stuff I'm just like okay so people need to got a reiterate how important this stuff is so then there's Loki hard as well who's like a famous extremely talented kind of canonical auditing Buzzard person and he seems to be doing a very similar thing with chakra and v8 and he's finding like tens of interesting exploitable bugs and then there's me who applied this on the chrome sandbox and found over 30 bugs about half of which for security relevant and then five of which were like sandbox escape without render code execution so you know this is just emphasized like we're finding really important things with this technique and since I discussed this the first time a couple months ago at PSC conference it's been used by someone in the chrome security team to fuzz equal light and they're already finding new bugs like in the first week so just more of the
evidence like here's the kind of the breakdown of some of the bugs I found with this strategy so just to highlight a couple of them or maybe three of them so the first one was like an out-of-bounds read just an integer overflow in blobs and this lets you you could make a blob and then ask to read part of it and then the offset could have been negative and there's an integer overflow they got the check wrong so it was a full like memory disclosure from the browser process there's also this like app cashews after free which is what I used in the exploit this year and then finally I guess the critical bugs are pretty interesting so two of these I guess the first pair are in quick and the first one is a stack buffer overflow with just a bad packet that comes in over the network so you just browse to an attacker site and they stack buffer overflow Chrome browser process which is outside the sandbox and it jumped over the the stack cookie so that was bad and then then the these block file cache problems these were in the HTTP caching mechanism which is also in the privileged process and deeds were actually crashing in the wild for three years and the they didn't know how to I guess I don't know if they didn't have resources or they didn't know how to address the problem or something but I
sent them the test case and then they closed like for bug reports and you know ancient bugs so you know it just goes to show that this kind of technique works in the variety of really interesting places that are really important and so now let's get to the boring stuff
so what's protobuf well protobuf is this data serialization format from google and it doesn't really matter that this protobuf just this idea is you want some kind of you want to encode like a little language for yourself that expresses what you want to fuzz a kind of a higher abstraction layer than just fuzzing bytes randomly and so if any of you have done functional programming like I had been doing stuff with oh camel and like a quick check for a couple of years and then when I saw this we just immediately recognized the pattern essentially what you can do is you can create this little tree structure of just basic types like inu you create these messages and like you can just kind of specify actions you want your fuzzer to take and then what this next full Lib protobuf mutator will do is it will take the specification you've written and link it into Lib buzzer so that it will automatically fuzz and create these like trees that are you know these kind of random ast s from this little language you wrote and then you can kind of parse this language which sounds crazy or more hard than it is but you essentially you can generate this highly structured input which makes it a lot easier to explore like a logical type of bugs so yeah just really want to emphasize that this strategy can be used to fuzz anything and so kind of just the same exact ideas being used to find bugs and like caching API is encrypted networking protocols kernels sandbox like serialization code stateful systems that have IPC and network interaction and timing as part of it which is what we'll show at the end and so like what's what's common here you
know we just fuzz all of these different systems in the same way the idea is like as an auditor with what you do is you kind of notice like okay there's some subsystem like some caching mechanism with a simple API and you look at how its implemented that looks complicated so you think okay you know if I can write a fuzzer in like a few hours for this you know it seems like high value so once you kind of play with the API bit and understand like how the API works you know you can just write this little specification for the API and protobuf and go ahead and write the fuzzer so basically I'll show how
this works on Chrome so just to make
sure I cover all of kind of the background knowledge you know for those of you that don't really care about fuzzing or don't care about anything else you know at least you can get bootstrapped on Chrome IPC research the basic idea of how the chrome sandbox ynx iteration works is when I'm saying I'm finding bugs in the sandbox like it's really finding bugs in the browser process which are reachable you know from a sandbox process and so the sandbox itself you know it's just constraining these render like tab processes so they can't really do much and then what you want to do is kind of jump from there to the browser process which can do anything so this is a very common model like almost you know like on 3ds you know you have like user land kernel then security code processor you have on linux like you might have a user land process and then in the sandbox there's some api is in the kernel you can hit like Cisco's you can hit and basically everything just keeps boiling down to there's some API that you can look at from the less privileged context and then if you can trigger bug in that API you escape and then you just kind of you know this kind of applies everywhere and so this idea of understanding like self-contained chunks of like you know
syscalls in linux or hundreds but being able to look at and say like okay here ten related sis calls you know this is like a sub system that I want to fuzz in isolation like this is kind of how you want to think about it and so if you just want to get started on Chrome you what you want to do is look at okay what are these endpoints in the browser process that I can reach from the renderer and then you don't really have to understand how IPC works to do this you just have to be able to recognize where what you're allowed to hit from the renderer to the browser and
what's actually in the browser and so fortunately the chrome code base is pretty well organized so they just tell you if you just generally go into any folder that says browser in it like all of this is outside the sandbox and prone to sandbox escape and so most of my bugs I found were in this content browser sub
system kind of thing but you can look anywhere and I think like all these results I've had the last year were just like in one folder and so you know there's so many other places where bugs can manifest I didn't even look at so basically there's plenty of room for more so just to go in on what I did is in this kind of content stuff is you just want to see where kind of the api's are reachable from the render are enumerated and those are in this render processed host imple init function so exceed plus plus kind of wordy but you get used to it basically there's there's two places where the the api's are set up and/or the interfaces are exposed those are create message filters and register mojo interfaces and it took me a while to realize where these were like a year or something but like that's those are the key functions to look at and so I'll skip over old-style IPC because it's going away but it's pretty easy to figure out what's going on if you look at it so I'll talk a bit about mojo so essentially this is a new IPC kind of platform that the chrome team has developed and the idea is they want to I guess simplified this process for developers in terms of defining a interface that you want to expose to a renderer or some other client somewhere else and essentially you write these little interface files called mode John and then the build system will generate all the C++ glue for you that you can just like subclass something and then it handles all the the mechanics of actually exposing this to other processes and so on and so as a security researcher you know you don't really care about that all you care about is like what can I reach and how do I know like what the fuzz or something so what I guess I looked at it's just you know where some of the Mojo files that have that are subclassed in this content slash browser and you can just do a little crap to check this so essentially the app cache was one of the bugs I found this year and here's the API that the render can you know these are all the messages that the renderer can send to the browser and along with the types of arguments and so you know that's pretty straightforward so in the browser process this is the code that we're trying to attack which is the actual C++ like implementation code for the API and so you can see their sub classing there and then they just make sure to override all these virtual functions that actually implements the API and so I won't go too into detail on this part because it's a little boring but essentially you know how does the renderer get from it to all the way over to this kind of browser C++ code well it essentially goes through this like request mechanism where the renderer tells the browser process like hey I have this kind of request to access this interface and then it'll actually just create that like dispatcher hosts implementation objects and you know just feed in that request over there so essentially stuff gets glued together somehow and you know then there's this stuff which is kind of ugly but I mean here's where you're actually exposing the ability to to do this so here's here's where we're actually like the request comes in and then we're this kind of request handler function gets fed in is that thing I mentioned earlier to register mojo interfaces so it's pretty his name's pretty well it's kind of easy to follow and they're adding new stuff constantly all of this stuff is on the attack surface like I think and I stopped Chrome a couple months ago I think I looked and there's like you know five new API is in there something like they're just constantly adding things so just a quick point about this essentially you want to do fuzzing in process with this like Lib fuzzy report above mutator strategy and you don't want to be like actually doing IPC and like it's just very brittle and weird so what you really want to do is just like here's the C++ object I want to just instantiate it and call those functions myself and then this whole thing is just very lightweight and easy to play with which is you know having a lightweight and like very easy to rebuild tweak something and play with the print things like kind of the faster you can iterate the better so all anything that's too complicated like the success rate goes way down so essentially like I you know the the fuzzer that I made open-source
is like the way you should do it but the way I actually did it was I just like made the object like commented out the private like I don't know if you can see on here yeah so just like commented out
private created the object started calling these things randomly it would crash and I would just hand fix things and you know it's kind of sloppy but you
know you're testing something in a very small unit that's really exposed to that kind of testing so now let's kind of put together
everything I've talked about so far so this exploitable abkhazia's after
free I found this year was found using this same idea of deliberate practice so I looked at this AB cache subsystem in the browser process and I noticed that there were three old bug reports that were triggering memory corruption and they were pretty interesting because they involved different kind of ways of attacking and these things had clearly been audited and I had actually seen these bugs a couple years ago and I kind of used it as evidence to myself at the time that fuzzing doesn't work and you need auditing but it kind of stuck in my head and I kept thinking someday I'll come back to this and like I'll overcome it you know and so essentially what's interesting is you know I've already talked about you know it's easy to specify the API and just feed IPC messages into it and I think everyone kind of understands that who does any IPC fuzzing but then there's also this idea that you've got some remote server that the appcache thing like creates a network request some servers you know serving that request and doing different things and so in the second bug it actually matters when things were like when the server was returning data because some jobs like stay alive and then if you send an IPC message to you know close your session and then the job is still alive there's like a raw pointer somewhere and you know something going on that it matters that the server keeps the connection open and then the last thing is just kind of a logical issue and if the server returns these HTTP codes in the headers of the response and this kind of weird order you trigger some logical bug that actually leads to memory corruption and so you know I looked at this and I said okay well so what do we need to test to cover all this basically IPC network and that timing and so not only that but this is kind of a stateful thing so we want to make sure that for each fuzzing session that we kind of reset the state completely and fortunately in C++ this isn't too hard because you know you just destroy the object and if it doesn't exist anymore what state is there so you know you just make sure that like you don't leave things lingering so yeah so I just had this basic idea would call around on my pcs with this fuzzed input we returned random data from the network and then we reset the state of the cache on every iteration and then part of it was thinking okay like if I can repro these old bugs if I reintroduce them by editing the source this is kind of appealing to this like deliberate practice idea that like I could have written a fuzzer that would trigger needs old things and this is kind of the idea I was pursuing when I actually triggered a new bug so now what's tricky about this is if you just returned random data from the network you're not going to make much progress and this is kind of where the auditing background comes in is you know you want to think about what is expressive enough of like how do I make my fuzzer expressive enough that I hit can hit everything but then not so generic that it's just spraying like it's just noise and so
I'll show how I did that in this specification and so at a high level my kind of root node in the ast or the tree
of the fuzzer message is this session message and then this just contains a sequence of commands and so commands are something I also made up and so the first ten of them are all the different IPC calls I can do the eleventh one is handling any pending requests or pre-caching like a response to any new request that comes in so that handles like both the asynchronous where it makes a request that's waiting for the server and also like the synchronous version where the response comes immediately and then lastly this run in full idle thing which essentially just it helps you like if you kind of place these run until idles randomly as your as you're kind of doing these IPC messages are kind of flushing the queue of accumulated work and so what this lets you do is kind of identify these race condition type things because you can do something like do a bunch of IPC's that come in and are handled at the same time without like actually serving like actually doing the work yet and then you do this run until idle and like all the work happens and you know I didn't like think of this a priori in
some like smart way I just looked at like the unit tests and I just try to think about like okay how are these developers already testing it and this is just what it looked like they were doing so these messages are very easy to write essentially just provide for each IPC message that I could have sent to this thing and I just make sure all the arguments are correct and then there's a little bit of cleverness which is like the host ideas also breaks down to just an enum of like 0 1 2 because just from looking at the code you know that if I'm randomly creating hosts destroying them and stuff over the whole like you know 4 billion in 32 IDs like it's just gonna fall apart and not find anything interesting so you know I just constrained that for the URL I also that is also a custom message that I constrained to just return a few like pre-made legit URLs so that way I'm also not testing like the URL parsing stuff so then you know how do I handle the network well I just read the source and looked at what are all the types of HTTP response codes that affect control flow and I just enumerated them and then for any given request that comes in from the appcache system I kind of just encode anything interesting about the response that I thought of it by by reviewing the source and it seems like the things that mattered were those issued peak codes whether or not the headers asked appcache to do caching or just download it once and then also the the app cache can request from the server this manifest file which has some metadata about what files that it should be caching and so you know essentially just all this is encoded in one message and so how you go from this like high level description to actually fuzzing it's just this so you can see how how simple it is you're really just you know I looked at kind of the unit test code and saw how they set up this app cache service and so they let you pass in this URL loader factory and what this is is just this kind of unit testable network request things so this is how I'm like you know intercepting the network requests and feeding data and so I do this little set up and then here I just create the one like render to browser host this is just kind of simulating how you would do the the mojo stuff if it was a sorry a real the real render to browser interaction and then I just go through those commands that I mentioned and just do these things so I mean this is all it is you just pull the host ID out of this part of buff message that we're getting at the top there that session that I defined as like the top-level tree node and you know you just go through and you just call the the api's that are there and so how to get the network stuff to work you know as I mentioned I have this like mock URL loader factory also C++ e but essentially it's this well okay so this is when I basically handle one of my requests messages that I came up with I just simulated a response this is a built in like unit test function that they have in their code base and I just pass in the relevant bits that came from that message so yeah so this is what it looks like I have some kind of do requests helper function and then I just passed my stuff through to it and so it takes that like URL factory and then serves responses to anything that's waiting and then what's interesting here and what's necessary to find the bug is that you know I mentioned that this is asynchronous so what will happen is when you do like register host and then if I go back yeah you like register host select a cache do some things like like the app cache will make a request to the server and then get this manifest and then will start making requests to download things and then these things are like pending it's pending like responses that it's waiting for from the server and so it actually mattered that you mutate the state further before those responses come in and so by doing this like in between the IPC messages not like pre-loading the the network factory with a bunch of responses I'm actually like serving things like I'm not making I'm not encoding an assumption about when I'm serving responses and I know this is kind of tedious to go into detail but essentially you know you run this thing so maybe 150 lines or something and then trigger this bug with address magnetizer and so essentially I use after free happens and what what's going on here is you can see the scope drive pointer destructor and it turns out that when let's here yeah so when you go to unregister the hosts like it's an IPC that's an IPC message there at the bottom that I that I sent and then it just accidentally this is kind of inaccurate this stacktrace but essentially some ref count goes from one to zero and then it starts destroying this app cache object and then in the destructor one of these kind of requests was waiting on a response from the server and then essentially like gives a reference back to that other object and that's kind of alighting some details but essentially like the ref count went back up to one and then now you're adding a bunch of references all over the place to something while it's being destroyed and so what happens is now you have all these pointers to a free table jekt and then you can trigger access to that free thing again later and so this kind of the recipe for an exploitable bug and so I just want to point out that all this fuzzer is open source and it's just in the chrome codebase so if you download it or go online to the code search tool you can just search for app cache buzzer and it will come up so then real quickly just to kind of cover the the exploitation you know I guess I have more time than I thought so I compressed this a lot but essentially I did this in part in a chain with two other guys say hello and Nicholas and so say hello provided the RCE bug and so from there we get code execution in the renderer and then this lets us send arbitrary IPC messages and so it's kind of annoying to send IPC with mojo like arbitrarily so we kind of piggybacked on the renderer side like glue code for sending these app cache messages so we just like found the C++ object and called into it and then all in all we end up with this primitive where we can deck ref and like release reference to this ref counted thing like after it's been freed multiple times so there's two stages to exploiting this like because we're in the renderer and we only have one bug we need to turn this into a memory disclosure and so you know fortunately this bug can be triggered repeatedly and so the idea here is triggering at once gives you this you know decrement by end primitive and so when you're releasing you know if you ever hit zero you'll trigger the destructor again and so essentially what you want to do for the leak is to not trigger the destructor because it will blow up but rather find a string somewhere in memory where there's a you know string pointing to the heap and then decrement the string pointer so then it starts like sliding somewhere else into the heap so that when you read that string back you're actually leaking keep data and so we did that so you know there's some object that had a standard C++ string in the beginning on Windows the first Q word is like the pointer to the string data so we decrement this it was actually a cooking object so we just read the cookie back from the browser and then in the cookie value we see the the leaked bytes and then from there there was a V table V table access that we can control in the destructor so we make another fake object that looks like it has one reference left you know make you hit zero so the structure is triggered and then this app cache of thing gets confused and essentially calls a controlled V table pointer and
then from there you know those are the primitives you need to write an exploit and then it was just a matter of kind of putting it together and if you're curious about that again you should look forward to Nicholas's talk and so just a summary essentially starting all the way from the beginning
you want to be practicing deliberately and keep working constantly and keep identifying gaps and actively working to improve you know which it sounds weird but you kind of like keep that in mind and use this new technique with live buzzer and parted left mutator I can promise you it's not going to be the last time you see someone using this and I mentioned I've started on xnu and we'll see some initial results pretty soon on that it's working so yeah and lastly never give up just may take months but it's fine so with that I guess I'll open to questions yeah thank you
thank you for that talking sure if you do have a question please line up at the
mindful phones in the room and try to limit your question to one single sentence if you would like to leave at this point please do that as quietly as possible so that everyone else can still
stay for the questions and also if you're listening on the stream you can
ask a question online - this seems there
is no question Allen there is one mic for number two your question please hello I just wanted to ask why have you
chosen Chrome for bug hunting was just like one written browser and then started yeah no I mean it's basically just kind of the hardest thing I could think of that I could plausibly do you know it's just for the purpose of getting better and so there's more to it like I think Chrome the way it's written is very amenable to research and like I actually didn't know C++ before I worked on Chrome so like learning looking at a great example of a C++ code base and learning from that was really helpful to me and you know I glossed over kind of my path but I was actually finding random like obscure like library bugs that weren't even reachable at first so just the quality of Chrome makes it so that what you're training is the real talent not just like being able to decipher bad code so yeah highly recommended I can say that like I definitely feel that the two years I invested on that one project like completely helped me get better so yeah thank you similarly request from the
Internet
[Music] is it so the question is is a I guess possible to attack using meltdown respecter so I don't know I guess it's possible I was essentially focusing only on kind of application level bugs so things that I could trigger like kind of deterministically using only bugs in the chrome code itself and so I mean also that those things came along like way after I was doing my research so you know I can't comment on that but I'm sure someone knows Thanks yeah unless I see no more people other
microphones or what's funny yeah okay thanks for your talk [Applause] [Music] [Music]
Feedback