Taking DMA attacks to the next level

thank you like you said now my name is Dan Lake I work in Intel amps so I'm a systems engineer and I work in a part of the labs called the system prototyping lab so we work with a variety of researchers within the labs and what I do essentially is build hardware and software prototypes to help researchers prove out their ideas before they potentially and hopefully go into a product group and I work with Anna but anyway let's talk about da attacks and my name is Anna I am a research scientist at Intel labs I work on the security side defining the next security features that are gonna be in future Intel products and I also hold a PhD in

computer security sorry so this talk is basically a repetition of the talk that we did in blackhat so just fair warning if you have seen this before you can go to the next talk which is also amazing but this talk will describe some early research that we have done in a new type of physical attack for DRAM memory and we haven't we don't have a demo to show unfortunately and we haven't completed an a full attack but we will describe the hardware design and the protocol limitations that our attack is based on and if such an attack is successful then the result will be full access to the entire physical memory and because the limitation is as I said in

the hardware and the protocol this attack will be applicable to all types of memories including normal you Dimps which is used for desktops sodium's for laptops and our Dems and all memory architectures as well first of all let's do an introduction on what DMA attack is so it's basically a type of physical attack where the attacker connects to a DMA capable port and through that he is able to gain full read and write access to the entire physical memory space such a port could be either a PCIe port or a firewire port or a usb etc and the goal for the attacker is to either extract some secrets that reside in the memory such as a disk encryption key or to

bypass a corrupted memory and bypass the platform security policies for instance modify the page tables in order for to make one application that was running with ring 3 rights now run in ring 0 are also installing malware in the kernel and an example of an actual DMA attack is for instance something that elf frisk demonstrated about a year ago now in a MacBook Air and through his DMA attack he was able to obtain the file volt disk encryption password but thankfully this attack has been patched now and your MacBook Airs are secure from the attackers perspective the pros of such an attack is that it's relatively easy and meaning that there's already off-the-shelf hardware that you can buy often it's

less than three hundred dollars and there's software and github and there are great tutorials that you can follow and do that attack yourself on the con side it does require the specific interface for this attack to work obviously and there are also mitigations for that attack so the past few years there have been medications through either BIOS and programming the VDD so that a device cannot have direct access to the entire physical memory space and there are some access control there or you can mitigate this attack by blocking associated drivers and ports so if you know in your laptop there you're never gonna use one port or possibly in your desktop you're never gonna use this

particular PCIe port then you can just disable it through BIOS should be fine so the motivation for our attack is okay what if we could eliminate all this cons and make something that is super duper resilient but in order to do that we need to explain a little bit on how the DRM is designed so basically them consists of a series of DRM chips which hold tiny capacitors inside and this is mounted into your PCB and the DIMM is then inserted into a dim socket on the motherboard which has internal traces and through that the DIMM communicates with the processor and here's an example of how it looks like in an actual system as you can see this is a normal desktop

which has four available Tim sockets and one of them is populated with London if you take a closer look to that you can again see the dim PCB which is the green part and then the empty dim socket which is right next to it but if you look super closely you can see the tiny silver dots there which are actually the dim pens those are the pins that make a connection between the dim and the and the processor and if you flip that same motherboard on the other side you can again see those same pins because they are a through-hole so overall all 288 pins for each of those Tim sockets are exposed on both sides of the motherboard

and those pins are electric electrically connected so what that means that all the communication that is going on between the dim and the motherboard is visible to anyone and this is a standard design as well this is not specific for that specific motherboard so as an attackers we said okay what if you could plug into that those pins and observe that communication that is perfectly doable but what if you can take it a step further and issue and connect to those pins again and issue reads and writes and to that them and impersonate an actual memory controller that - right but in order to do to see how's that it possible and if that is possible

as well we have to dig a little bit deeper on how the theorem works right that is specified by the j-2x standard which defines the set of requirements that must be satisfied by all memory modules and all architectures so that is something that is global so the first thing that happens is the DRAM initialization and this is part of the bios and in that stage basically the CPU reads the dim serial presence detect EEPROM data from the SN bus this contains information such as the manufacturer of the DEM the module serials like supported voltages for the dim etcetera and this bypasses the memory controller and the next day state is that the CPU configures the memory

controller so at that stage this is again part of the BIOS the CPU decides on the clock frequency that is going to use to communicate with the DEM and configures the memory controller to hold this information next the memory controller is responsible to perform something that is called memory calibration basically a memory controller is agnostic of the motherboard and the dim traces that it communicates to and that makes sense because you want a particular memory controller which is part of the processor to work with different kinds of motherboards and that work with different kinds of dims and at the same the other way around so you want Adam to operate with different motherboards right so the memory controller is it

possible to calculate what are all those traces and configure itself appropriately so it calculates the round-trip time between the memory controller and them and also calculates small discrepancies between the the different traces so as I said there are 288 pins one trace might be a little longer than the other so the memory controller needs to take to take this into account as well and the final part of the initialization is that the memory controller sets the dims mode registers those are red that enable or disable features that the DIMM supports and it also does some fine-tuning for the timing so if you want to overclock your damn you need to tweak those registers a little bit next

is what happens when the during normal operation so when your computer is active and the processor doing actively reads and writes to the memory in that case the memory controller needs to schedule these accesses and optimize them and the memory controller also schedules periodic memory refreshes so because this is the memory contents degrade over time this is how DRAM normal diagrams work the memory controller issues periodic refreshes to hold the data they're very nice and then is what happens during sleep in particular I'm talking about s3 suspend mode which is a mode where the CPU is powered off but the memory contents are held there and when you wake up from the state then it's a little bit faster than

doing say hibernate where the memory contents are lost so in this particular state s3 the memory controller is powered off the CPU is part of the DIMM is powered on and it's in self refresh state so that it holds its memory and a clock a particular signal that is controlled by the memory controller is the clock enable signal and this needs to be to zero the rest of the signals are in tri-state this is a pretty important signal because this is what the dim is gonna monitor and as soon as this cke signal goes to one then the the dim will wake up and you can then issue again reads and writes to the memory so

overall there is a protocol limitation and that is that there is no particular authentication between the memory controller or the DEM and there is no state information that is held on the dim everything including the calibration results which are identical for that system are held in the memory controller side not on the dim side so basically nothing prevents an attacker from impersonating and memory controller to the dim because the dim is agnostic to the memory controller that it works with okay but how we could exploit that the idea that we had is to create a device that would attach to those exposed signal pins that I showed you earlier and impersonate a memory controller to the DEM however that would

be extremely difficult when the system is in is in normal operation in s0 because the the cpu and the original memory controller would issue reads and writes constantly and we will in our device will interleave with that and that would be caused a mess however that attack would be possible when the system is in s3 sleep because at that point there's nothing that communicates with a DDR and will be the sole owner of that bus and an example of a realistic attack would be to say victim go to a conference and leave aids system to sleep then the attacker could get hold of this system and attaches the rogue memory controller device that I mentioned to those exposed pins and the

attacker now would own that system so the requirements for this successful exploitation would be as I said to attach the Raghav American troller to the victim system while that system is in s3 sleep pulled the clock enable signal to one in order to wake up to them perform the calibration between their Rock memory controller and the memory bus traces because we're gonna introduce new traces and our memory controller needs to tune for that in order to do successful in communication with Adam then obviously the attacker needs to send memory reads and writes commands because we need to read do reads and writes for the attack then put the clock enable signal to zero in order to put the dim to sleep and

finally detach from the victim system in order to wake up normally so now the owner of that system would never notice that an attack has happened and next we're going to go through each one of those builders that I showed you earlier

okay so in order to get the system while the system is asleep we want to be able to wake up the dim and be able to talk to it as a rogue member controller so the first thing our device needs to do is to issue a self refresh exit command and the way that it does that is through the use of this cke signal so there's just this one signal that if we can control this signal we can tell the dim to wake up so here in the diagram we show the dim on the right and what we call the victim memory controller on the left and then we come in and we apply a voltage to that pin to

try to get it into a logic high state while the memory controller is actively trying to keep that signal in a low state so in order to not attach the voltage directly on to a ground pin of the memory controller and potentially damaging our processor with the integrated memory controller we attach what we call the attacker's resistor here so we just want to limit the amount of current that's going to be flowing into the memory controller so what we did in the lab is we brought you know actually a variety of different motherboards to test out this methodology with a variety of different resistors and voltages to test are we able to wake up the the dim just using a

power supply and and our attacker resistor so this is a picture of one of the benches in my lab and with the microscope and you can see in the center picture here there's a little blue wire that we poked into one of those signals that Anna pointed out earlier the diagram on the right shows you where the blue wire is and just out of the frame there there's a resistor and I think we probably built half a dozen or a dozen of the little resistor wires and tested it with different voltages and different resistances and we found it across the board with at least both the ddr3 and ddr4 in a variety of regice unbuffered non-ecc varieties we are able

to wake up the the dim using this methodology so we found that for for some of them we could use a resistor around 50 ohms and around 1.2 volts for ddr4 and we were able to wake this up we then went through the rest of those 288 signals on the dim saw some of them are already various power rails some of them are ground rails but we went through each of the remaining like the address lines and the various control lines and make sure that we could positively assert a value of 1 or a value of 0 while the memory controller was sleeping so once we validated that we know that we can completely own that bus while the

processor is asleep so the first thing that we need to do that and once we've once we've owned that bus is to attach our rogue memory controller and as Anna mentioned we need to be able to train our memory controller against the bus because every different motherboard you attach to and every different DIMM that you connect into that motherboard is going to have different link signals different impedances and all sorts of layouts that are they all within the jeddak's standard but there's a wide variety of acceptable layouts as you know you can look at dims from a variety of manufacturers they all look different to some degree so normally the system does this when it first boots up the

memory controller on your motherboard talks with the dims because it has to be designed that processor has to work with any motherboard in any dim so once it's done that it stores the results in the memory controller but our memory controller perhaps has never seen this board before so we have to do that when we first connect one of the advantages to that though is that if we're targeting a specific victim system if we have the opportunity to see what brand of motherboard they're using in the model and maybe get a our eyeballs in and see what memory they're using we can actually pre calibrate before connecting to the system so we don't have to do

this stage which may take some time to find the right settings for that particular system and then the calibration results could be the same across all the different systems that are the same so once we've connected the designers of these motherboards take great care to make sure that there's no stubs and impedance discontinuities on the motherboard so they get the highest quality signal going between the processor and the memory so obviously when we come along and we attach on an additional device we're adding loading onto that bus that the designer didn't expect to be there and one of the ways that we can mitigate some of the signal integrity issues is to run the ddr at a lower frequency so

as I mentioned earlier the frequency that you're running whether you're overclocking your board or not that's actually decided by the the processor and the BIOS settings in your processor but the memory doesn't really care what frequency you're running it at as long as you're within the the jeddak's specification for that particular unit so once we connect and we calibrate against that we can actually run at whatever frequency you want down to a certain threshold and about 800 megahertz is the low threshold for ddr4 because the ddr4 technology introduces something called a delay lock loop and that DLL inside the RAM ensures that all the timing between the clocks and the data is line up but it also means that

you can't run your clock too slow fortunately one of the things in the jeddak's pack allows you to turn off that don't lock loop so once we've calibrated we want to turn off the delay lock loop and then we can actually run our clock extremely slow and although the memory performance is going to be lower it allows us to scan through the memory with less signal integrity violations yes why don't we hold till the end yeah well we'll try to finish up and give a few minutes for questions yeah so once we've calibrated and we will reduce the clock frequency then we can issue the reads and writes just following the jeddak's specification if you're familiar with the DDR

specification there's kind of a large state machine for how to activate and address the rows and the banks and that's something that the memory controller in our in our device that we've built actually we use just use an off-the-shelf memory controller that has all this functionality in it so you see and here it is so this is a board that we built in our lab so we're using an FPGA and we're using a ddr4 in this case so up above here you can see there's a slot where there would be a ddr4 like a dim socket like you would find on your motherboard but in the boards that I built I only populated one with that socket

and the rest of them I actually leave it empty so that we can play around with some of those pins on the back of the motherboard and then the plan here is we build a mechanical electromechanical connector that attaches onto the backside of that motherboard it uses these little crown tip spring popes that can grab on to those signals and then we actually you can see the bottom here the rogue memory controller board this is the board I just showed you it has all of these pins in it and when we apply it to the backside it allows a simultaneous access to the entire 288 pins of one of those dim slots

great thank you Dan and so overall the thread model that we have built for this attack is that this attack requires a hardware a skilled Hardware attacker and it also obviously requires physical access to the victim system our attack is also invasive not in the terms that it will make it will modify the the victim system in any way but it's invasive in the terms that you have to dig out the motherboard out of the system you're gonna attack so that requires a little bit of time especially if it's a laptop and it's gonna be not be noticeable as well and finally it may require some prior knowledge of the victim system spec so if you know that

you're gonna attack that system with that motherboard it's if you have this knowledge then you can pre calibrate the the solution the the board that Dan showed you and then you don't need to do the calibration all over again because it will be the same across systems that have the same memory module and same processor for the future work that we have is to obviously complete complete this mechanical connector and attach it to the board that we already have and then run the full attacks the full attack against the the memory bus and we as Dan mentioned we anticipate to have a signal noise and reflection problem but this could be mitigated if we make the

clock if we clock it low enough then we think that it's not gonna be a huge issue plus we don't necessarily need to do rely to all the rights to all all the reads to be perfectly we can do them three times four times five times and then when we read the data back if it's what we expect then we're golden in terms of mitigation for this attack one that it's a little bit silly is to just not use sleep and use hibernate and said and also I think it's a good idea to focus on the physical security if you care about your system if it holds something that's really important in terms of long-term we plan to be able to

enhance the dim socket and the bother board design in order to not have those pins there in the first place because this is something that it's doable and we would also like to enhance the Jade expect to perform some kind of authentication between the memory controller and them and not trust it blindly so to conclude this talk we describe some early research that we have done regarding a DMA attack it requires a skilled attacker and we this attack exploits a hardware design and protocol limitation this is new line of research for physical security I hope we will be able to influence other people to go into there and there are short term and long term medications so thank

you [Applause] questions

you