 I would like to ask all of you to come a bit more to the front and show some love to our next speakers. It's going to be a really exciting talk about a really exciting research on Flippeng Shui. Please welcome Viktor von der Veen and Kavé Rassavi from the FUSEC research group that was doing research in 2016 into the Rohammer exploitation and they managed with the Flippeng Shui technique to actually reliably exploit that harbour bug. So enjoy. Good afternoon everybody. I'm Viktor, this is Kavé, we're from Freie Universität Amsterdam and we're going to talk about Rohammer and Flippeng Shui, research we did last year in 2016 with our research group. So who are we? Well, that's me over there, Kavé is next to me. Other people who are involved in this research were our professor, he's in the middle, this Herbert Boss, he's the boss of the group, that's why he's called Herbert Boss. That's him, there's Cristiano, and then over here there's Ben, who was also involved, and it's Eric. No, Eric is not on his picture, but I think he should be here in the room, is he here in the room? Eric? No? He's not here yet? But he was also involved. We do a lot of stuff, this talk will be about hardware vulnerabilities, but we also do interesting research on the other topics that are here. So mobile security, some binary armoring, we do some malware analysis, so we were involved in taking down the game over Zeus Botnet collaboration with the FBI a couple of years ago. We also do software testing, which means we do fuzzing, we write fuzzers, and many more interesting stuff. But today it will be about Flippeng Shui, and basically your takeaway message of today, so after this you can fall asleep or move to another talk, is the following. Even if we can build perfect software without any bug whatsoever, a single hardware issue, a single bit flip in your hardware can still compromise it. All right, so Flippeng Shui, in 2016, our research from our group, we show that with single bit flips, we can turn these bit flips into a reliable compromise of the cloud. This was done in this work here. We can break the browser using bit flips, which was shown by Eric and the data paper, and we can also use bit flips to break your mobile phone, and we're going to talk about all three of these today. Since we are in another lens, I wanted to express that these are all research papers that have been published at top venues in computer security, and they're dots, right? So I think it's something to be proud of. Thank you. Actually, in 2016, we were the best research group in security, and we were better than MIT, I think. All right, so a bit more arrogant, I guess. We had a world-wide impact. We were covered by many news all over the world. Well, yeah, OK, introduction. Flippeng Shui, the requirements. What do you need if you want to do a Flippeng Shui attack? First, you need is a reproducible hardware bit flip. We're going to use Row Hammer for that. I'll talk about it in a minute. And then next is the ability to target this bit flip so that you can actually flip a bit in something that's interesting. So about Row Hammer, who here? I want to see hands. Who here is familiar with Row Hammer? So that means there are still some people that are not familiar with Row Hammer, which is good, because I'm going to explain it. I'm going to talk about single-sided Row Hammer. Imagine your DRAM is like this matrix of capacitors, storing ones or zeros. Oh, this is hard to see. But people found that if you're going to read from one of these rows in your memory, and then read something else, and then read from the row again, many, many times, you will see, at some point, if you do it enough, a bit flipping that is next to one of these rows. There's adjacent to these rows. We call these rows that we're reading from. We call these aggressor rows and the rows in which we can flip a bit is the victim row. Now it's important to mention that Row Hammer does not allow you to flip every bit. Sometimes with DRAM, maybe not vulnerable enough, so you can not flip anything. But people found that once you flip a bit with Row Hammer, you can actually reproduce it. So once you know that this particular red cell over there is vulnerable for Row Hammer, you can try to store some important data there and then reproduce this to flip a bit. Then people found that single-sided Row Hammer is nice, but you can actually increase your chances of flipping a bit if you're going to sandwich this victim row by reading from two aggressor rows in an alternating fashion. OK. So if you're an attacker and you want to do this, there are a few challenges. So first thing you need to do is you need to bypass the CPU cache. As probably most of you know, if you're reading something from your DRAM memory, the CPU is going to read something from DRAM memory, it's going to get stored in the cache. And we're going to repeatedly read the same row from DRAM. Your system is not stupid. It will basically serve everything from the cache. So we need a way to tell the cache after we read one of these rows into it to remove it, to flush it from the cache. Actually, and there is an instruction for that on Intel. But it basically does this. You give it an address, and then it will remove it from the cache. Another way of getting your data out of the cache is simply to read more until your cache is full. And at some point, it will evict the address that we are interested in. And then next time you read it, the read will go to your DRAM. OK. So the mechanics now of a FlipFix Huey attack is first, do memory templating. And with memory templating, we mean scanning your memory, the entire memory, or whatever you can get for bit flips that are useful for your attack. The second step, then, is to land sensitive data, so something that you can actually exploit into this region, the page, the cell, where you can flip a bit. And then you reproduce a bit flip, and basically, you're done. All right. And now, Kaveh is going to talk about his work that he presented at USENIX about hammering a needle in a software stack. Thanks, Victor. All right. So these three steps that Victor just talked about, we're going to show three examples of how we could use these steps to compromise different systems in different settings. So the first one is using this primitive to compromise a VM in the cloud. So imagine that you're an attacker, and you want to compromise somebody's VMs. Then you have to start a VM somewhere that is close in the same physical machine as the victim. And then your goal is that to flip a bit somewhere in the memory of this victim VM so that you could compromise it. So this is all like the assumptions of the attack, so that you basically want to use raw hammer and another feature is called memory duplication to make the attack possible. So memory duplication is this feature that some providers use in order to reduce the memory footprint of their VMs. So you have lots of VMs running in the cloud, and most of them are running Windows or Linux, the same software stack. And you want to reduce the footprint by making sure that they don't store the same copies in memory. And the idea is that you can, using this primitive, this flip-fang tree primitive, you can flip a bit in a memory that is being used by another VM. So I have a question for you. So just for those who haven't heard about this before, I wanted to think, if you could flip a bit in a VM, one bit, what bit would you flip so that you could compromise? So your goal is to compromise this VM, this victim VM, and you can do this by flipping one bit. So I wanted to think, what would you flip? We can discuss this like after, so what we chose and what is possible and what is not. So you start by templating. So the first step, as Victor said, is memory templating. How would you template memory? So because you are running on the same physical host as your victim, you have access to the same physical memory. And the thing is that, as Victor said, you need to be able to flush the cache. Because for all of this to happen, you have to read from memory really quickly. And for this, since you are root in your own VM, you can use this instruction that Intel provides. It's called CacheFlush that would help you to flush and then you can use it to access your own memory really, really quickly. So what the victim does is basically allocates a large physical contiguous buffer and uses the CacheFlush instruction to read from memory. So you start reading, you check, no flip, you do a bit more, still no flip, and then suddenly you get a bit flip in your own memory. But this is in your own memory, right? You're a victim VM. So how would you use this to flip a bit in a victim VM? And this is where the duplication part of the attack comes into play. So we want to force our victim to store some sensitive data in this location that has a bit flip that once we trigger this bit flip, it allows us to do a compromise. So that's what we say. We use memory duplication for this and the way it works is that, so typically you have your victim VM and your attacker VM. Typically they have some data. Some of these data are different, like if you have a pointer in memory, potentially in your memory page, this pointer is different between two VMs and this is not something that you can do duplicate. But some data, for example here, like this one, these two, are the same. So you could, as a hypervisor, as a cloud provider, you could just somehow store only one copy that would save you one page. And you do this for many pages and suddenly instead of only being able to run 10 VMs, you can run 100 VMs. This is quite good, right? Because it allows you to make more money by running more and more VMs. So yeah, so there is a process that goes on in the background and scans for these sort of pages and as soon as it finds the same copy, it basically updates the page tables, the pointer that the VMs use to point to this physical page. So now we come back to the question of what would you flip? So we talked quite a lot about this and so one of the things that we came up with that would allow us to use this, remember that this is one bit flip, right? So you have to make sure that the data that you want to corrupt is exactly at that location. So and then you have like 32,000 possibilities for a bit flip within a four kilobyte page, which is the unit that the system uses to do memory duplication and also paging. So we thought about this, what could we flip quite easily? And one of the things that came up was cryptographic keys. So imagine like for example, you have a RSA key starting your VM and then this is like, imagine if you have a four kilobyte, so if you have a RSA of 4,000 bits, it spans quite a bit of a memory page. So these are like all potentials that you could use to flip a bit in an RSA key. And the other option would be a domain name. So we have two attacks that I'm gonna discuss how we use this sort of bit flipping in these things to compromise this victim VM. All right, so let's talk about how we use this to do the compromise using these bit flips to compromise open SSH. So how many of you know about authorized keys? I hope many people. Yeah, this is something that we all use, right? So it makes it much easier. We don't have to enter our passwords all the time. So there is this file in your home folder that you could store your public key there and then from then on by showing the private key and doing a challenge and response with the open SSH server, you can just log in. And one of the properties of this authorized keys file is that so basically the stuff, so the public key that you're storing there is that the attacker would not be able to guess this. So this public key is made out of two prime numbers and these two prime numbers that are multiplied together and it's a hard problem to factorize these two. So once you can factorize these two numbers, then you can easily like generate a private key and then use it to log in. Right, so we target this thing, this public key, and this is usually on disk, but as soon as you start the SSH connection, the open SSH server reads these files and brings it to memory. And memory is something that you can't trust anymore because you can flip bits in the memory. So typically, as I said, it's quite hard to factorize these two numbers, but once you do a bit flip, it suddenly becomes much, much easier to factorize it. So instead of being two prime, once you do corrupt this sort of like RSA key, suddenly it becomes a multiplication of many primes, which makes it much, much easier to factorize it. So typically, like this factorization is shown to take, you know, a hundred, maybe if not hundreds of thousands of years to actually factorize a 4K RSA key, but once you do this bit flip, as we show in our paper, it actually suddenly becomes like a matter of seconds or even minutes to actually factorize it to all its building blocks, building numbers, prime numbers. And once you have that, you could easily SSH to the victim VM. Now you could say, so this is a nice attack, so we actually executed this and then we showed that it could compromise the victim VM. But one problem we did that you might say is that it's not a zero-knowledge attack, right? So you need to know the public key of your VM. I mean, your victim VM. There is GitHub, so if you know, okay, this is the admin that is using this VM, you could go through GitHub that automatically uploads your public key. So there are like some ways to get this, but wouldn't it be nice if you could compromise the VM without knowing anything about it? And this is what the second attack is about. So we use the bit flipping to... In two rounds, we used the flip-fang tree in two rounds to the first round to flip a bit in the domain name and then the second round in a cryptographic key to sort of like make this compromise happen. So typically when you do like an update, update, right? There is this file that sources that list of these domain names, right? That your updates are coming from. Like ubuntu.com, or if you're using dbn.com, there is also on Windows and Android, there are these URLs that people use to basically fetch their updates. And once you do a bit flip in this file, suddenly your ubuntu.com becomes something like ubuntu.com, for example. And then the victim is gonna go to this website and get the packages from there. But we should be good, right? Because these packages are signed. So people have thought about this, people have been doing lots of these network attacks to make sure that your VM or your system goes to a malicious repository to download the packages. So they said, okay, how can we fix this? We do end-to-end cryptography, right? We signed the packages and then once the packages are signed, there shouldn't be any way for the victim can check this and then it wouldn't install these packages once it knows that the signatures don't match, right? But fortunately, we could do a bit flip in the GPG key that the victim uses to verify these packages. So this is the same, it's the same as RSA. So once we do a bit flip in there, we could again calculate all these prime numbers and then we could use it to sign the packages. So in the first step, we flip a bit in the victim's VM to go to our repository. The second stage, we flip a bit in the file so that the package, the malicious package that we want the victim to install, like for example, a new open SSH or core UTS or whatever that we want to backdoor, we use those private key, this new private key to sign it so that the victim would trust it and install it the way we want it to. So we did all of this and this attack also worked and so we were a bit worried so we wanted to make sure that nobody's harmed by this attack so we contacted NCSC and they did a really, really good job of disclosing these issues because this is some issue that affects all the layers of the stack, it affects your DRAM, it affects your operating system. Potentially it could be affected by this, your cryptographic library, OpenGBG or SSH could be affected by this so we contacted those to make sure that they would do something about it. We also bought all of these domains so that people could not do an attack anymore using these domains and we gave this to, so like at some point Interpol took over and now that the domains are basically handed by them so that people would not be able to abuse these domains to do a philiphenchory attack in VMs. And it was also nominated for a Pony, the best cryptographic attack but we were up against Shattered which is I think like much more impactful so we didn't actually, so Shattered got the award. So this was the example that used philiphenchory to compromise Cloud VMs. Now we also used the same principle to compromise the browser. So the attack is called DDoop-S Machina and the point that DDoop-S Machina wants to make is that you could compromise a browser end to end without any software vulnerabilities. So you go to a website and then you use sort of like a side-channel attack which I'm not gonna talk about today but I'm gonna use the information that it provides to basically leak some pointers and then we use the leaked pointers to do a philiphenchory attack to corrupt these pointers to sort of like compromise the browser. So none of these things, there is no bug in Edge but using this philiphenchory primitive and the DDoop side-channel could basically compromise the browser. And we do this all from JavaScript which sort of shows like this is actually quite dangerous. So and I'm gonna again go through the three steps of how the attacker would go through to be able to compromise the browser using the philiphenchory primitives. So in the first stage we have to find bit flips, right? We have to template the memory to find which locations in memory are vulnerable to raw hammer. And in the previous example it was quite easy, right? We could just use cache flush instruction but in JavaScript you are quite limited, right? We don't even have like virtual addresses, right? Everything is sort of like in this high level JavaScript language. So we can do easy cache flushing but instead you could easily read a bunch of other location in memory that would flush the cache at the location that you want to hammer. So you go on and access some other location in memory and then you access your target and then this would allow you to sort of like trigger the bit flips to do the templating part. So and our target is a JavaScript array so I don't know how many of you know do programming in JavaScript but typically you have a normal array in JavaScript that allows you to store all kinds of things in there like you could store like a double in there you could store a pointer reference in there you could store many things in there but accesses to these arrays are slow because it needs to figure out, okay, is this object that is currently being referenced a pointer or an integer? So there are some checks involved there but there is also this other type which is much, much faster and these are called the typed arrays which the type is known so it's an integer or a double, sorry, a short and then since it doesn't need to do checks there accesses are quite fast and fast is good for us, right? So we want to be able to read from memory really, really, really quickly. So we use this typed arrays to sort of like do the eviction and hammering and then we want to target a JavaScript array. So here I've used some colors so the red colors are the location that map to the same location, same location in the cache so if you read from those then in the JavaScript array that would flush the location that this JavaScript array at the location red is located. So by reading from these red parts we can sort of like read from memory that is located at location red in the JavaScript array. So this is like how we use the eviction buffer to read from memory instead of reading from the cache. So then this is like how the templating works and so the other problem, as Victor mentioned we need to know the sort of like location of the object that we are reading in memory but in JavaScript as I said we don't have anything, right? We don't know the virtual addresses let alone the physical, we don't know the physical address let alone the virtual addresses so we can't really do double-sided there because we don't know the addresses but there are like some other crazy side channels that Eric came up with like using the so like how memory basically is laid out so depending on how you're reading from it things become faster or slower and so by using this information he crafted this access pattern that allows you to do double-sided raw hammering so like probabilistically and he managed that it could actually get bit flips from JavaScript without having any information which is really, really interesting so if you want to know more about this I can refer you to our paper which discusses these things and then this allows you to get a bit flips from JavaScript so this is so like how the attack works so here you have your JavaScript array and this has like an object there that points into memory so our target is so like this pointer, this reference that is pointing to a typed array and typically what you have when you have a typed array in JavaScript what it has is a Vtable pointer and a size so the Vtable pointer defines the functions that you could use on this array so in terms of like tell me what your size is can I get an object, can I do something on this location and like other type of functions so all the functions that you could do on this type thing is defined by this Vtable pointer and it has a size that defines the size of this array and then your data will come after this size so we take this typed array and then using the side channel which gives us two pointers we create this counterfeit object in the data area of this typed array so now you have a Vtable pointer, a size and there but we don't have, it's a counterfeit object right we don't have any reference to it so it's not really useful we can't use this to do anything but given our Rohammer we just start reading from memory really quickly right so that's how Rohammer works and at some point we trigger this bit flip and this bit flip causes this pointer to this typed array to suddenly start pointing to our counterfeit object and once we have a reference to our counterfeit object we can do some things because we control the size of this remember that this is something that we put in there right so we could control the size of the object that we put in there so since we can put a really, really large size and at this point it gives us arbitrary read and write over the memory so in JavaScript you're not allowed to read beyond your object so that's the whole point of sandboxing but with this primitive and this attack we can easily read beyond our object and suddenly we have arbitrary read and write in the memory and from there on we could do control diversion attacks and escalate the privileges we can start doing other kinds of attacks so it allows us to take over edge without a software bug so we were talking with Microsoft about this and to sort of make sure that the users of Windows and Edge are protected against this attack and then Microsoft decided that they're gonna disable memory duplication starting July last year so that people would not be able to do the DDoS Machina attack and yeah, so people like this quite a lot also the hacker community liked it quite a lot so and then in 2016 in Las Vegas Eric won the most innovative research pony for this attack and yeah, so that's it so now I'm gonna give it back to Victor and Victor is gonna tell you how we use FlipTank3 to compromise mobile phones in your pocket thanks okay, thank you yeah, hello again so this last scenario of the talk we'll be about Drammer which was really a collaboration between Vue and people in Austria and also people in Santa Barbara where I was when I did this work it also could publish at a very good conference last year and basically the question that I had after I saw Ben and Kave breaking the internet I figured can we use then can we maybe do Rohammer on Android and then use it to route an Android phone however, if you're going to look at this then you will realize soon that Android phones are usually different than the stuff they were working on before because you have suddenly ARM which is a completely different chipset than Intel also Android devices turns out that they don't have any kind of memory deduplication so the stuff they did before we couldn't do however, we still managed to pull this off by exploiting the behavior of the underlying memory allocator in your operating system but let's start with the first phase again memory templating so we need to bypass the CPU cache now recall on x86 we can either do this with cache eviction as indeed a bad machine or with the explicit cache flush instruction and my first job was now to flip a bit on ARM so does this work on ARM? well, of course not because why would you make things simple, right? and turn out that this cache eviction was too slow so I couldn't... I implemented it but it was not fast enough to flip anything and then the explicit cache flush instruction it's privileged so if you are a normal app on Android you cannot flush anything from your DRAM so we had to do something else, right? and then we found that this cache that the CPU is using sometimes it's not something you want there because if you have other components for example an audio driver or a GPU it might want to work on the same DRAM that your CPU is looking at and in this case you don't want your GPU to look at something that is different than the CPU is looking at so whenever you have a setup like this there's some kind of need for direct memory access in which the cache is disabled DMA so we could use DMA actually to get uncast memory and then landing sensitive data so let's look at the threat model that we had in mind we were assuming a recent Android operating system without memory duplication because it's too costly on mobile phones it will drain your battery too fast and we have an unprimed list app that wants to get root access now if you want to get root access basically what you want is read write access to anywhere in memory because if you have that then you can find anything in the kernel that's interesting and then change anything there and we were actually going to use this to override their own user ID that would say this app has only this limited set of privileges and we override it to zero and then we would get root so the goal is read write access and the approach for this is that we were going to land a page table at the location in memory that is vulnerable to row hammer and then once we have that there we're going to flip a bit in it and I will explain you now how it works so page tables page tables are a simple concept that are mapping virtual addresses to physical addresses another example if you have a user space program and you allocate some buffer you get some virtual addresses but if you don't look at your physical memory the mapping from your software from your virtual addresses to physical addresses it's non-linear could be anything so in this case the beginning of your buffer is pointing further down in memory than the second part of your buffer and a page table is this thing that will you see what it says it translates virtual addresses to physical addresses so there is this structure somewhere in your memory where there will be a virtual address and then it will say oh yeah this virtual address b6a blah blah is stored as this physical address I also added the binary representation here because we need that in a minute so where are page tables stored I just said it in memory for example there in between your buffer and then what happens if we flip a bit in a page table so I'm going to flip a bit right there oh yeah we're going to modify mappings so now it should be yes so I'm looking at this particular bit over there which is the the first mapping the first virtual address pointing to hello in physical memory I'm going to flip that one into a zero what will happen then with the actual physical address it will change from one four zero zero to one zero zero zero now if we also update the mapping we will see that all of a sudden this virtual address that was first pointing to the word hello is now pointing to another location in memory namely the page table so we now have a buffer in our user space program which we can use to access a page table and with access like this we actually get read write access to anywhere in memory because we can now modify mappings we can change the page table whenever anywhere we want we can add new oh we can we can change entries so we can change the second part of a buffer to point to somewhere else or we can add new ones so with this if you get this far then you have read write access to anywhere in memory right and then with that we can actually get root access the question however is how do we make sure that this page table will be stored here and not somewhere else in memory because we need it to be stored in a place where we can actually hammer it from two sides and for this we invented a new technique which you call this thing and I'm going to give you an intuition on how this works uh... so let's look at your physical memory these are capacitors uh... very small capacitors and then you have some applications running on your device they use some memory the blue cells here uh... and then the first step of this thing should be is allocating large chunks of memory in this case we get two of those and then we're going to search for bit flips and at some point I was supposed to do it like this yes at some point we find a cell where we can flip a bit now the next step is allocating smaller chunks in memory of a specific size in this case size four and we get all of these now next we release the small chunk that had the bit flip in it and immediately afterwards we're going to do this trick in our software to generate a new page table and because in this scenario we assume a page table has takes four cells to store the operating system will have to put it over there because all other cells are in use and there are simply no other place for it to store it and from here on now we can do actually have a memory again and flip a bit so this is probably hard to see people always ask me what was it like if you were doing this while I was looking at stuff like this and this is not going to work because there's a bit flip in here you won't see it it's there no you can see it and then we did some evaluation right because we wanted to know how many phones actually are vulnerable to this so we had a lot of phones to play with and we found actually that out of 2075 so we looked at 18 of them had bitflips and interesting enough sometimes you have a Nexus 5 a certain model there were zero bitflips and then you looked at a different Nexus 5 so same model same manufacturer it had close to a million bitflips sometimes because not every bitflip is vulnerable sometimes the first bitflip that you found that you could actually exploit you found it after one second but sometimes it will take 15 minutes to find your first exploitable bitflip in general we did some computation about this we found that once you have the bitflip it will take 22 more seconds at most to actually exploit your device then we wrote an app for this when we published the work people could install our app people trusted us to do this and then we were seeing also bitflips on Google Pixel phones at 1 plus 3 I guess also 1 plus 5 these days people were crazy enough to run it on the Galaxy Note 7 and all these phones also had bitflips so it turned out that this problem was pretty widespread disclosure then which was very interesting we contacted Google after we finished the exploit and we suggested a list of mitigations this was on July 25, 2016 now why is this date important? it is 91 days before you would call public with a paper and Google has their own security team called Project Zero and they give Google 90 days to fix stuff so we gave them 91 days which was like in time right? enough time to fix it then at some point we had a a video call with these guys and pretty soon one of them said yeah can you maybe publish your work and another conference later this year well of course not because CCS is important for us so that was a no and then it was what if we give you more more money and then also no and then I think it was most crazy it was like yeah well then maybe you maybe obfuscate some technical details of your paper so that other people cannot easily reproduce it anymore that was also a no and then we got in the end $4,000 an insane amount of money for an attack like this there were some partial fixes in November and then later on they roll out some more fixes that should stop it I'm not sure it does but they say right now it works and then this was this year actually we won a reward for this so we won the dot cyber security research paper award and they got a lot of 500 euros which was later doubled to get another one so I guess the message here is if you want to make money you should go into research because and also actually so I just got back from from Black Hat last week and I won the I won the little pony over there the pink one for for best privilege escalation block so that was pretty cool no money of course in conclusion now what right we show in the last year 2016 we showed that you can use Rohammer to break all three major platforms we can break your cloud you can break the browser we can break your mobile phone and it's important to know that we're also working on defenses so that you can actually defend yourself against Rohammer but what we realized what we must realize is that software was never really defined a designed to deal with hardware issues to hardware business and what we see so far is all defenses against attack like this they're still in early stages and right now also easily bypassed and even as we were also seeing right now is that hardware medications that have been designed and proposed they're still optional so not everybody may use this and also lastly you cannot fix Rohammer right so you cannot open your phone and then take out a memory and then try to solder it a little bit and then put it back in and then hope that you a Rohammer problem is gone it's not possible so yeah Rohammer is it maybe the silent killer since 2010 we saw that a lot of DRAM chips that have been manufactured since are vulnerable for this and 83% of the DDR3 modules in some studies with 83% of them affected this really is an issue we think that more research is necessary to understand what's going on also it's not going away so with Bitflips on the pixel other people reporting Bitflips on DDR4 we're going to see Rohammer research and attack defenses for quite some more time so what's next question to self do you still trust your hardware and will there be a Rohammer 2.0 that's it you can find more details, demos actually do we have do we have time how much time do we have we wanted to show a demo I think I have it open 20 minutes oh there's a lot of time for Q&A or we can do another video oh and 10, oh ok, ok um ooh wow does it work? yes it works so it's bit hard to tell I guess um I'm launching the DRAMmer exploit here uh first I'm trying to run SU so I'm trying to get root privileges and then I'm calling the exploit and here it is searching for bit flips it finds a couple but not all of them are usable and then here it's uh launching the second part of the attack must be very hard to read um but actually already here we have access to kernel memory and right now we're scanning it and then we found some structures and then it turned out that we're not so we we we found the CPU uh the user ID our own user ID and we overrided with zero and then we check whether we're actually uh also root and then it turned out we were not overriding our own structures so maybe we were uh giving somebody else root access and then in the end we get a shell and we are root and this was on Android 6.0.1 which was at the time the latest uh Android version I think this should be it yes so do you want to do another demo do you guys want to see another demo you have to do it though which one uh let's do SSH is it Feng Shui yeah this one yeah like this oh yeah it's five minutes good all right so we have two screens here uh so the let me try to remember yes the left the left one is the so like I think the um so like gives you a log of um what is going on so it's basically we wrote so like an exploit that launches every time it creates you know two new VMs and um and then one is the attacker and one is the victim the attacker doesn't know the private key of the victim and then it tries to so like do the flip Feng Shui attack to trigger a bit flip in the RSA public key of the victim and then um tries to generate a new private key and logging on the right side so we have a so the things that once we do a bit flip we still have to factorize so like we have to factorize the RSA the corrupted public RSA key to be able to generate the private key and for this we need lots of computation power so we have a cluster at our university that we use for like so here you can see that we have 256 cores and we're so like like with the strapping a new factorization process so once we find the bit flip right we want to check it on the public key to see whether we can factorize it or not and then so on the right side we start looking and then as soon as we find one one bit flip that allows us to do the factorization then we know okay this is the bit flip that we want and then we choose that and then we so like that page that physical page we put uh so like the public key that we uh of the victim there the memory duplication in the background like basically updates the the select pointers of the victim to point to this page and then we trigger the bit flip and this corrupts the the so like the VMs public key and then we already have the factors because the cluster have given us the so like the factors we generate the private key and then we log in all right so I'm gonna we're gonna go through this quickly I guess so here we are like starting the VMs I'm gonna get out of the way this is really a slow but you asked for it so you have to watch watch through what is it doing it's now starting the VMs it's starting up so yeah so this is the so like the public modulus of the the so like the victim and uh so it's waiting it's bootstrapping it's networking so like it could talk with with them developing this was really painful like it took us like weeks because we had to wait every time so here's the so like IP address of the so now the attack VM is ready so we SSH to the victim to make sure that it's page uh so like with the with an invalid username so that we make sure that the public is brought into into memory and um at this point we start like a scanning for for bit flips and there on the right side you can see that you know because these are valid bit flips we start looking we add them to our cluster and we start looking for one that is basically we can factor so we use the ECM which is a known factorization algorithm for this which works quite well for our situation yeah so now we found the factorization so basically one of our processes came back we said if you do this bit flip here will be the the so like the the the factors for this and now we're gonna wait for memory duplication in the background so we put the public key in there and we're waiting for the memory duplication process to actually you know measure the pages in the background is this the music from the video sorry yeah there is a music so here we are actually looking from the outside when the duplication happens but in a in a real world the attacker could use the duplication style channel to figure out when the duplication has happened or just wait 10 minutes you know so that's so like what we are doing here so we want to be we want to check that indeed the duplication has happened should be okay all right the end is really quick yeah so most of the time is basically spent looking for bit flips and waiting for the duplication to actually you know measure pages but the actual attack itself happens really quickly I wonder if it's gonna work yeah I don't know it's taking too long man it's not gonna work all right so now the duplication actually happened so we're talking with the you know exploit instance running in the in the in the attacker we basically so we waited so long for this duplication to happen for this right so where basically once it is it happened we basically corrupted and then it gives us the command that you can try to log in with this new private key and here you can see that actually with this new private key we could actually log in and yeah so that was it so this is so like how it looks like there is a part to this let's go back here because yeah that was it I think hopefully we have some time for questions if not then you can always go to a website our contact us on twitter yeah you can download the website the app if you trust us trustworthy you can download the app to test your mobile device yeah thank you yeah thanks for listening thank you so much for this fascinating research and presentation you just gave we do have time for q&a yeah but first yeah please give another big round of applause for this awesome research maybe sorry maybe a bit of a dumb question but please bear with me for a second so if you've if Rohemmer flips the bit why doesn't the error correcting hardware in the RAM take care of that yeah well because many times there's no error correcting code in the so of course you're probably referring to our ecc which usually the server should have and then it should stop the flip make sure we attack for the cloud which would be would be most hard because if you have ecc there would be harder but for your normal desktop computer or your laptop usually doesn't have ecc same for mobile first of all thank you for your presentation it was really good couldn't a possible solution software side would be to hold a private key for the SSH server in multiple locations in the memory and check from multiple locations so that if you have a bit flip at one point you need to have the coincidence of having it at two points so you mean the public key yeah sorry the public key so that's that's a possibility so perhaps like a slightly like better way of doing it would be to keep like integrity check of the public key and every every time we want to use it you check whether the integrity hash that you make out of your public key is still the same we propose this but so the OpenGPG guys OpenBG they did something like this so they added the integrity check for this but the SSH guys Theodorat is not the nicest guy also he had concerns for backward compatibility because once you have like SSH versions that don't support this then it would be problematic so but yes something some software solution like this would protect against attack don't have to you don't trust your hardware and that's the yeah so don't trust your memory that's the sort of like the message thank you so when your paper first came out by my compliance that I was really impressed and secondly I started thinking of defending because that's what I what I really like to do as well it's the other side of attacking and I tried to look at on the on the host side what are the the the the side channel signals which can help me detect a row armor attack so I tried detecting changes in my cache of course because if I I tried to write stuff to memory and time how long it took to get back because if you get it from cache it will come back quicker if your cache is empty because of hammering it comes back slower so I tried to get a valid measurement I couldn't find one do you have any theories where such a detection would could be developed yeah now he was talking about the host so that's your sure domain okay there is a defense already out there it's called anvil it looks at the performance counters in your processors to see whether you're getting too many cache misses and uses this as a metric to decide that hammering is going on and then refreshes the memory by accessing those rows that might be affected by this so there is already something going on but it wouldn't work on ARM because we don't have those performance counters yeah that's why I didn't focus on ARM I couldn't figure out how to go that way thanks has to be in any cases of this attack actually being used in the wild because it seems to me that there are lots of lots of unknowns like you could use it to root your own phone or you could use it to say compromise a smart card where you can run software but there would be too many unknowns to actually use it against a random target in the wild like you they have a non-targeted browser exploitation yeah yeah I agree would be very hard to do this in a while so we haven't seen it I guess people are trying to implement the drama attack to root their own phone because if you have access to it yourself then it might be easier but still it's yeah it's hard to set this up and pull it off that's true yeah so the especially the D2S Makina I think that's so like quite dangerous because you could basically just rent advertisement companies to basically send your JavaScripts to people but hopefully it took Eric who's a very very smart guy a very long time to implement this attack so I'm kind of hoping that you know it would take a long time and by then hopefully we would have like harder mitigations in place As to the hardware duplication attack factor you mentioned that it's done per page and the portion of the memory you're interested in is much smaller than that can you maybe elaborate on how you get an entire page to be identical to the target that's a very good question so the things that we rely on so when we read this file it ends up being in the page cache which is like this so like cache that so Linux or maybe Windows also yeah keeps to so like make sure that most of your accesses are served from memory not disk because memory is fast this is slow so and we are targeting that cache which so like is page so it's page based and then whenever you read this file basically puts it in that page so it has to allocate one page so even if the file is a smaller than a page it still allocates one page and then the rest of the bytes are zero and this so like allows us to get an exact match basically so that's so like how it works with flip-anchry Hi thanks have you seen any efforts trying to implement can you please try to speak a bit more into the make have you seen any efforts trying to implement this on an iPhone for jailbreaking for example I haven't seen it we briefly looked at it but it was not very straightforward to get direct memory access so we couldn't actually hammer and search for bit tips I'm pretty sure should be possible but so far there are no no results no reported bits in iPhone we would love somebody to do it so get lots of money from Apple if you do it is this ever likely to occur in the real world as a non-intentional attack just to say a particular usage pattern of computers around can you please repeat the question is this ever happened likely to happen in the real world as a non-intentional attack just as a normal software bug so actually so I think when it was first reported there was this guy who was working on this encoding libraries encoding decoding libraries for so like a video and then he was getting so he was sure that his software was correct but most of the times he was getting like sometimes like random corruptions and it was a single trader program so he was like really really baffled by why this is happening and then once this error was reported he was saying that it was very very much likely because of this so yeah indeed there are cases in the real world that there are certain access but it doesn't happen too often but if you do things like apparently encoding and decoding in a certain way it could cause this pattern specifically that will cause bits to flip have you tried the bit flipping also on ecdsa keys rather than sr rsa we have not tried it but it's interesting yes I think it there may be like a potential so the thing is that it should be something that people use if people are using it we think that it's an interesting target so the other thing that we would like people to do to start thinking about so because this attack the philip feng shui attack targets crypto so we think that there should be a little bit more on the crypto side to start protecting against these kinds of attacks so we are hoping that I'm not a cryptographer I don't think Victor is a cryptographer we would like cryptographers to also look at this because it seems like these kind of errors are not going away and cryptographic so like data seems to be a good target so there should be more protection indeed that's a good question thank you very much for the questions to be on time for the next talk which is going to be my safe is your house at 1430 we are going to close down Q&A now but Victor and cafe will be available if you have more questions or just want to pet the pony after the talk thank you again and another warm round of applause for Victor and cafe