BG - Ghost DMA Attack & The SeDeFuS Conundrum - Dr. Raghudeep Kannavara, Alan Sheng

coming up next our breaking ground track continues with ragudi kanavara and alan shung's presentation of ghost dma attack and the cetaphis conundrum hey everyone um this is raghudeep kanawara and alan shang we work for intel carp today we'll be talking about the ghost dma attack and the sedufus conundrum and it's a pleasure to be addressing you all today and hopefully you will find this talk interesting so let's go over the agenda of what we want to cover briefly we'll talk about the dma attack and dma attack mitigations this is all well published and available in public literature we'll then switch gears and talk a little bit about the sedufus conundrum and what we mean by sarufas conundrum and why it's

important in this discussion we'll follow that up by the ghost dma attack discussion and the mitigations for the ghost dma attack which is obviously the meat of this talk today and we will follow that up by a demo which is the highlight i believe for the talk so without further delay let's get the disclaimer out of the way this talk is presented exclusively for your security infotainment any resemblance to actual products deployed in field or end of life is purely informational and we really hope that you find this talk useful um and any q a we can wait till the end of the session so let's talk about dma attacks dma attack is the exploitation of a computer's

ports to access sensitive data this is well documented and there has been mitigations that have already been published in the space when an external device plugs into a computer it connects using direct hardware access to read or write directly to main memory without any operating system supervision or interaction and this means that the os security policies are bypassed allowing the connected device to access and directly read or write sensitive data which presents an opportunity for a dma attack and if your computer has such a port like the thunderbolt port an attacker who gets brief physical access physical access is the key to this discussion uh to all uh to access all your data even if your drive is encrypted

or your computer is locked or set to sleep so dma attacks via pcie devices so far have required physical access to your computer to launch a successful attack and like we talked about before thunderclap and thunderspy are well documented attacks that have been discussed at different conferences and the mitigation for dma attacks are also available dmre mapping for device drivers protects against memory corruption and malicious dma attacks and it provides a higher level of compatibility for devices on kernel dma protection enable systems dma guard policy may block devices with uh with dma remapping in compatible drivers connected to external or exposed pcie ports such as a thunderbolt depending on the policy value set by the

system administrator and of course at the hardware level intel i o mmu also called the vtd enabled dma mapping supports address translation for dma from devices so a quick look at how the i o mmu interacts with the the physical memory and the dma capable device essentially io mmu is translating all the accesses to the main memory and and converting the virtual i o address from a dma capable device to a physical address that's mapped to the main memory which is very similar in concept where it originated from to the cpu side of the world where you have the memory management unit it actually converts the physical ad virtual address to the physical address and

vice versa as well so any address translation has to go through the mmu so you have this layer of protection when vtd is enabled and when iomu is working and arbitrary address accesses in the main memory should be prevented now let's switch gears a little bit and talk about security and debug ability for security a system tries to minimize or eliminate information exposed that is essentially security and privacy sensitive data that we try to minimize the exposure of debug capabilities on the other hand seek to provide observability so that the user can actually debug the system and access system internals security and debuggability are thus are on the opposite end of the spectrum um and there are corner cases that

we find when one is required to turn off security counter measures in order to enable debuggability and this could be an attack vector right for example turning off vtd to enable debug which is not a general practice which is not recommended but there could be a corner case and the user if he or she is doing that should be aware of the risks in doing so so interesting attack surfaces emerge at the intersection of security and debug ability this is just a screenshot showing that vtd can be enabled or disabled this is a bios setup utility option that user can control so the other interesting concept that we want to talk about is security and functionality and usability

good security with adequate functionality and usability is uh really important and specifically when we talk about third-party apps and third-party firmware that are often enabled to run on platform integrated hardware subsystems or accelerators that seek to provide better functionality and usability of the hardware to both the oem isp and the consumer with rich user experiences like audio or video processing experience some of these uh some examples of these platform integrated subsystems are sensor hubs audio video processing units or similar pcie endpoints these subsystems usually have some rtos running on a microcontroller which with a dedicated local sram and potentially a dma engine and that is a really interesting area for um from a security perspective

so in order to function subsystems require access to main memory for example reading in audio data or sensor data to process data and write back data back to the main memory and interact with the applications running in the context of the operating system from within the um you know subsystem and talking to the operating system or or the file system for example for subsystem memory accesses to pass through io mmu vtd needs to be enabled and the device driver needs to support dma remapping else the subsystem has direct access to host physical memory that means it can bypass the operating system security mechanisms right and specifically if there are third-party apps and third-party forms are running on

a subsystem that are malicious direct access to the host physical address can be catastrophic so in this cartoon we want to talk about the different moving parts and explain a little bit about what is trusted and what is not trusted in a hardware subsystem so this uh on the picture on the left uh shows you the software firmware and hardware stack you have the third-party app running on the operating system in within the context of the operating system and that we believe is outside the trust boundary while the device driver and the os kernel is within our trust domain the third-party firmware which is also in this case running on the microcontroller is um could be malicious while the oem

firmware is trusted which is color-coded in green all of these firmware have access to the dma engine that is on the hardware subsystem and if vtd is enabled all the address transactions from this dma engine actually map to a address translated by the i o mmu into the main memory but if the vtd is disabled iomu doesn't come into the picture so you have direct accesses to the physical address and it could be a rogue access and that is very dangerous in this case hence we want to call out the conundrum is what we figure we if you look at it here security debuggability functionality and usability are on different spectrum so we just want to show that this

there are certain trade-offs that need to happen there are certain considerations that need to go into architecture design and implementation when we are trying to bring together different concepts and there's one additional spectrum here that we haven't talked about in this diagram and we'll talk about it in the next few slides so if you have uh thought about it uh hold on to the thought and and we can discuss that later so now switching gears back to the dma attack we want to talk about the ghost dma attack in this discussion obviously we believe this is a new class of dma attacks that do not require physical access to a computer the attack is launched by malicious third-party

apps and firmware that run on platform integrated hardware subsystems which are essentially pcie endpoints by manipulating programming the subsystems dma engine to perform arbitrary accesses to the host physical address space by passing the operating system security policies the goal here is to read modify our corrupt arbitrary address locations in the host physical address space which is the goal for any dma attack and the consequence of such an attack could be ranging from a dos to p does depending on the privilege that the firmware has uh to memory corruption arbitrary code injection and also information leakage on how the attack you know if the information leakage is possible depending on how the attack is structured but essentially um any dma attack that

um that requires uh physical access is you know this is something that could attain the same kind of impact how would it work uh for the ghost dma attack to work the attacker does not need physical access to the computer the attacker only needs to ensure malicious third-party app and firmware is installed on the user's computer malicious third-party app and firmware can be installed by leveraging vulnerable or insecure you know software firmware update mechanisms think solarwinds which was recently in the news or simply by social engineering it's um possible to get like malicious updates on the device the malicious app runs in the user space context um that is in within the context of the

operating system it can continually pull the presence of dmar entry in the acpi tables and infer vtd is disabled if dmr entry is absent in the acpi tables and then it can launch a dma attack through the subsystems dma engine if the vtd is disabled either by default for or for debugging purposes or for any other reason even though the computer is in the safe custody of the rightful owner the dma attack succeeds once malicious you know especially the firmware is installed and it starts executing so why does this attack work um so let's talk about the threat model um here the threat model assumes the following the malicious third-party app the and the firmware is installed on the user's

computer and hardware subsystem that is a prerequisite and in order for that to happen like we discussed there should be some kind of social engineering or there is a broken software firmware update mechanism that needs to be exploited the malicious firmware has access to all of dma engine in the harvard subsystem and it can reprogram it to access arbitrary host address space which is a prerequisite here and we have cases where we have seen this is possible the dma engine does not separate subsystem versus host accessible ranges so there is no privilege separation between um you know between the subsystems memory that the firmware can access versus the host accessible ranges within the host malicious third party app can monitor

the dmar entry in acpi tables and communicate with the third party firmware api so the app can instruct the firmware through the firmware apis to perform certain malicious actions and this is required for enabling usability we talked about how data could be streamed to like the main memory for audio processing or certain kind of operations so this is entirely possible so having you know described what the threat model is in this case we want to state that the device drivers and the operating system kernels are trusted there is no exploitable vulnerability required in the in this case vulnerable device drivers allow an attacker to gain access to the kernel and compromise the entire operating system you don't really need

this kind of attack for you know if you have a vulnerable device driver so let's talk a little bit about the acpi and dmar the acpi stands for advanced configuration and power interface tables these can be read from user space there are tools you could google online and you'll be able to find certain freely available tools to read and dump acpi tables dmar stands for direct memory access remapping if vtd is enabled dmar table is configured and acpi dump when you dump the cpi tables you will find that there is a dmar entry and an application you can monitor for that entry uh to see if vtd is enabled from the user space and yes uh you know we really don't need

to monitor the dmar table uh to verify if vtd is disabled right we can always launch a brute force attack malware can always do that if vtd is disabled the attack will you know work if worst case scenario the attack fails if vtd is enabled so you know it could just do a brute force attack even if vtd is enabled and if the device driver doesn't take advantage of vtd the attack will still work right because the device driver because dma guard policy may not be updated or may not be active and the device driver is not taking advantage of vtd right and of course the security tradeoffs um with performance gain is another important topic that we actually miss

when we talk about the conundrum so we've seen many security issues come up when we optimize for performance and one example here is the pcie address translation service to bypass iomu this was described by the set of researchers who talked about the thunderclap vulnerability because dma remapping has performance costs address translation service enables pcie endpoints to cache to participate in translation cache management essentially you're caching the addresses so these devices can maintain their own cache of translations in the address translation cache and using this feature any device can claim it's using an address that's already been translated and just bypass io mmu translation right that's like bypass of the vt io mmu capability here for trusted devices this is a useful

performance improvement but let's say you're you have an untrusted device or the firmware running on the device is untrusted then ats could allow a compromised device to ignore immune and write to places that it shouldn't have access to in the first place

so let's switch gears and talk about what is the ghost dma attack sequence and how does it actually manifest so let's start with the user user here either naively installs the malicious third-party app or firmware and firmware and and all the subsystem update mechanism has an exploitable vulnerability that an attacker can take advantage of so this could be either one of these cases but essentially the prerequisite is that we need to have the malicious third-party firmware installed on the pcie integrated pci device malware monitors the presence of dmar entry in the acpi tables on the user's computer from user space uh if dma or entry is missing in you know vtd is disabled but essentially this is not needed you could

always launch a brute force attack but just this just makes the attack more sophisticated or you know complex maybe and the malware launches um ghost dma attack right the the that means that the firmware is compromised in this case and it can reprogram the dma to access arbitrary address locations in the host you could you know create memory corruption issues inject arbitrary code in the kernel space or essentially dump the entire kernel onto the file system and then do some cross processing or you could actually have the malware connect back to an attacker control server in the guise of user approved telemetry or maybe without user approval and exfiltrate user data to attacker control server at any time of the malware's

choosing right so you send anonymous data to a a you know so this this is a play on the on the alphabets here but you know you trick the user into sending data out of the system so the impact of the ghost dma attack is if the attack succeeds it's actually still there and more dangerous than traditional dma attacks because it firstly doesn't require physical access it can affect many computers that are vulnerable at the same time because the update mechanism could potentially be exploited on many systems at the same time and it is persistence because it actually decides not in the file system it resides the the modeler could reside the essentially the firmware

could reside on a pcie integrated endpoint so the attacker can run arbitrary code at the highest privilege level and potentially gain access to kernel memory passwords banking logins encryption keys file systems you know you name what you have the entire control kernel space that the malware can access and dump and do some analysis on it so obviously mitigating ghost dm attack is important um right for from a oem or isv perspective enabling dma remapping for device drivers is very important have secure install and update mechanisms to authenticate or verify the integrity of the software firmware apps ensure privileged separation for dma operations for third-party firmware or apps on subsystems that's really important from a user perspective beware of social

engineering tactics never install software that you cannot trust also enable kernel dma protection windows 10 onwards right and dma guard policy and always have vtd turned on and you know if this if you're not a normal user you probably if you're a normal user you're probably are not doing this but if you are trying to debug a system then it might require turning off vtd for example then you're back to square four so i mean back here so you should never install software that you don't trust so the key takeaways that we want to highlight in this talk before we jump into the demo section is that platform integrated subsystems include like sensor hubs and audio video

processing units or similar pcie endpoints that are integrated on the device these seek to enable rich user experience but they have certain attack surfaces that should be reviewed for security these subsystems usually have an rtos running on a microcontroller with a dedicated local sram and a dma engine which is an interesting attack vector these devices so like i said present rich opportunity for an attacker to launch dma attacks without physical access by exploiting weaknesses in the update mechanism especially if you are supporting like third-party updates this could be an attack vector enabling third-party apps and firmware to run on such subsystems requires uh certainly requires security considerations so oems and isvs need to be cognizant of

subsystem security the privilege provided to third-party apps and firmware running on these subsystems and their update mechanisms

so let's talk about the demo um this is the highlight of our discussion today so i have my colleague alan on the bridge uh alan do you want to talk about the demo and um also we can play the video of the demo actually working um so please please take sure sure uh thanks raghu uh so we have this demo section and in this section i will first brief what we did and then we have the pro record video so that ragu can play so in this demo we just try to demonstrate uh how we use a pretty old intel platform to create a tool and then uh hijacked the uh firmware on top of one of integrated

ip subsystem so that we use a tool to master the firmware to dump the memory from the windows managed host memory and then we use a kernel windows kernel debugger to verify and make sure that that's the same windows kernel space data so to hijack the ip system firmware is not easy and this is not our focus today we just demonstrate uh how possible when people disable btd and you know the possibility to uh have this illegal memory dump as well as you can override the memory okay raghu can you go the video sounds good

okay let's watch the demo this is a intel cabinet box that they used for the demonstration intel cabinet soc has a view integrated microcontroller id most of those microcontroller ip has built-in dma controller we created one windows based tool which can send the commands to one of those microcontrollers and then modify the microcontroller firmware which could receive the command from these two this tool can send command to firmware to ask forward to start its dma to dump data from windows managed host memory the dma can read and write the host memory but from this demo we just show the read operation so i open one windows command plan window

so you can see this tool this is for the demonstration so actually which memory address i want

to

those kernel this address it's a three zero zero zero zero zero zero so i just copy and paste into the command line window and then the tool will send this command to the microcontroller forward and then microcontroller phone will just do dma to dump the address data and then feedback to this tool and this tool will still also start the data into this output file so if you look at the dump data yeah from here this three zero zero zero zero the dump the data so do remember 4d5890 because later we will use urban debug to verify those data

so the virtual address of ng kernel so this actually shows the virtual address they may need to convert the virtual address to the big physical address

so we use the pte command to convert the virtual address to the physical address then use a db command to dump the from this physical address three zero zero zero zero zero zero and give a length

so if you look at the dump the data od 5a nine zero so this match to the data we dumped from the tool

okay i think that's all from the demo uh back to your ragu thank you ellen and that brings us to the q and a session here um so thank you for listening to our talk and we are open to any questions um that we could potentially provide some more clarification on so please please go ahead thank you for joining us and i would love to hear like what brought you to look at this particular you know kind of aspect of the system and uh why'd you go poking in here and and uh you know what uh what makes this something that uh was was worth all the effort um thank you it's a pleasure being here

and um thanks for you know hosting our talk today at besides so to your question i think it's a really interesting question uh my role in in my organization is uh um helping with the security development lifecycle for the products we ship from our business unit that means i have this opportunity to work with very intelligent and excellent people who drive product engineering and one of the issues that we found when we are poking around with this specific ip subsystem is on the older platforms we realized that there was an ability to you know muck around with the firmware running on the microcontroller in this subsystem and this interestingly had a dma engine that could directly talk to the

host dma space and if you could get the firmware to somehow misbehave and you know communicate with the actual app that's controlling this firmware in the third-party ecosystem we were you know thinking that there is a potential attack vector here where we could uh you know corrupt the host memory or you know siphon off information from the host memory working in tandem with the application that's running in the host operating system space in some form so we started poking around a little bit and we kind of came across um you know came up with this uh proof of concept that alan actually demonstrated to us so it's part of our security evaluation work um and i just wanted to mention that uh

this issue is uh right now on you know fixed it's on an older platform that's end of life so we got it out of the way we made sure to make sure it's fixed uh it's not on newer platforms but we just want to highlight that this is an important area for the industry to be looking at because you know we talk about dm attacks from thunderbolt and you know pcie ports but when we talk about pcie integrated subsystems they offer a very interesting attack vector and when we open up that uh subsystem for third-party development uh hosting third-party apps and third-party firmware it becomes even more interesting and that's why we thought this is an interesting

message to convey right yeah no the uh it's the general class of thing that's that's the the most fascinating part of this not so much to the specific platform that you've founded on um so what uh you know what would you what would you hope that people would take away from this you know the most out of this this uh conversation that you're trying to have here we believe that this is an important attack surface that probably has not been explored that much are not a lot of research or publications we haven't found many in the space maybe because it's a very corner case but we see that this is a space that is going to expand

when we allow these different third-party vendors and oems to work closely and collaboratively to develop applications and rich user experience applications on you know platforms uh we feel that in the future this is an area that is worth exploring and paying attention to um so we thought this could be a talk that would highlight this um and the demo would actually make this a little bit more interesting yeah so and one of the things i mean i i i love a good breaking i love we all we all get excited about ooh hey look we can like get into the thing and make it do stuff it wasn't supposed to do um one of the key things i've always tried

to bring to brie sides is is that finding and breaking things is is great but it doesn't mean anything if we can't like you know make this make things better and and use it to help you know move the the industry forward so what would you say like just even at a tactical level what would the average you know help desk admin or or or you know uh enterprise you know uh blue team folks you know do to best secure their you know make sure their their company is securing their devices at the build configuration stage so that you know this kind of thing as a general class isn't going to be a problem for them

that's a really good question i think the core of the problem that we are trying to you know build upon is the ability to get malicious firmware installed on a pcie subsystem i think if if we can patch that specific hole this whole class of attack would obviously not work you know so we are trying to convey the message that you know make sure your firmware updates are reliable um you don't get malicious firmware to install on your machine just from you know industry perspective and then when you work with your third party partners have a mechanism to make sure that their firmware that's getting installed on the subsystem or the hardware is also verifiable in the chain of trust

in some way right so build that entire chain of trust from your base firmware to the third-party firmware that you're letting install on your machine i think that we're in that involves some kind of close collaboration with the industry partners like for our company and the ioms or isvs working in the space right um and the general class of sorry go ahead no no no please continue right from a debug perspective i think the virtualization that's an idea we were poking around but you know generally we don't expect a user to turn off virtualization to you know normal user wouldn't probably be doing that but you know given a color case you are trying to turn off

virtualization to do some debugging maybe this is an attack surface that would get exposed we just wanted to highlight that when you're interested in debugging there might be side effects that you need to be careful of um and that's ultimately is that something that that is you know to some degree i mean if you are going to play in this pool you're reliant on uh you know the the manufacturing partners that you're getting these devices from to come up with some part of that solution for your trust's you know uh stack that you're building there or is this you know do you see this is something that you can uh entirely you know knowing that you're

you're taking this risk that you can entirely improve or defend yourself against your you know in your own right um so there has to be some kind of trust so you would have to establish a mechanism with your partner to make sure that their applications are verified that has to be a prerequisite and we do have that in place the other thing that i want to highlight is when you are architecting your system you want to have some kind of privilege separation on what your base firmware or oem firmware can access versus a third-party firmware can access what privileges you provide and having that you know as part of your security architecture providing the definition of privilege

separation and access controls could be another way you know architecting from ground up and then building the mechanism of verifying the third party firmware and signatures and how do you do that how do you enable secure firmware update you could build on top of it so yeah i guess it's a defense in depth problem so you would build it from the bottom up build good robust process on top of it to make sure firmware updates are secure all right um hmm i guess you know if uh that's that's a a lot of of uh scaffolding to have to put in place you know at a lot of layers for for one you know one company but uh i

i think that's if that's the the state of where we are if there's not a way to uh i mean some sort of like shared framework for doing that like in a consistent way uh that would guide people in in the right direction uh you know where's the i guess where's the opportunity to um to look at this uh you know beyond the boundaries of just like one vendor one company you know and kind of come up with guidance where you know people can do this uh in a in a a a good way you know uh rather than having to invent it from you know scratch themselves right yeah that's a good question so there are

mechanisms that we use today to enable secure form updates and also verify the authenticity of the third-party firmware so as i said this is an issue that we kind of we believe we have addressed at the core when we are working with third-party vendors and oems but you know there might always be a condor case when things go wrong so as long as you architect for you know defense in depth but the implementation has a buffer overflow so you can never really be sure if something goes wrong or someone uses like a weak rsa or wrong you know uh key size it might you know that's the implementation is where you probably like all crypto problems right yeah

and you know verification of you know uh the legitimacy of something it's it's all comes down to implementation that's why which is the pattern i've seen over and over again is you know people they implement a you know a trusted compute module or that or a they think they're using a good you know certificate based you know pki or something and and they just they get one little thing wrong right and it's everything they're doing so which is why i'm like kind of pushing towards that you know what would you think you know how do we get to a place where that's more um you know uh less less prone to the the uh implementation errors at every

layer right yeah yes yeah i think validates yeah not expecting you to have a solution that's just you know kind of like spitballing if somebody works in the space what's your idea yeah yeah i think validation you know having robust uh security validation black box or a hacker mindset to looking at your system from an external perspective trying to break the system reverse engineering and having those kind of teams working on your systems especially systems like these that are very interesting for an attacker having you know company-wide efforts to do penetration testing or hackathons or getting working with external researchers getting their points of view um just be cognizant of the changing threat landscape you know what kind of attack surfaces

are emerging new tools right so i think it's a game that we need to catch up on uh right sure so at the very least in a larger company you can you can centralize these kinds of processes and have teams that are famous working you know practice and maybe frameworks and tooling to like prevent every you know development team within your company having to to reinvent that wheel but across companies it's the wild west still right and we're just probably not going to get there yeah all right well that's a really interesting challenge i i appreciate you uh entertaining me while i poke at like the fringes of the impossible um but uh and also very much you just being

here today to share this with us um thank you thank you any questions uh you know you can put them in the uh the discord i assume you've got uh access you know how to find the breaking ground channel on our discord uh if not uh you know people can hit you up on twitter or what's your what's the best way to get in contact with you if someone wants to continue this conversation um so the best way to just contact me is on linkedin um my my name is on linkedin i should be able to find me i'm probably the only person with that name on the planet so it's easy to find me

okay how did i do with the name by the way i i wasn't i you know i did i did i butcher it really bad no no you're you're good you're you're correct okay excellent awesome that's my biggest terror like generally when we do these you know it's there's it's in person and there's a human being and i just walk up before the talk and say hey how do i pronounce your name is it this way is it you know what how would you like me to refer to you and uh and it's been we haven't been able to do that here uh this year so uh yeah i'm always fingers crossed in those recordings uh

yeah anyway have a great day you too you too damon thank you thanks for hosting me and our talk take care