 So I am Mickey, that's Jesse, um, that's our Twitter handles. If you want to ask us questions about anything we give at the stock, please feel free to reach out and ask us even next week or whatever. We're happy to help. About the agenda of the stock, well we're going to start with a little bit of a high level introduction into what is a driver in Windows. We can keep it high level and then we're going to go get more and more technical as we go along. Part of the things we're going to discuss is what the problem is, uh, give you some funny examples of it, the tools that you need to explore for yourselves, and a couple of funny stories about disclosures. This topic is not new, so bad drivers have been known to be found in, um, the past decade. They pop up one here, one there, three here, and you get a little blood post and description and, excuse me, how to use them and it just goes away after a while. The vendor patches it, fixes it or not, and it stays there and then just continues on. So here are some of the examples we used in, in our talk and based our, um, some of our code on, so we thought it would be best to give credit. Um, more information can be found in these links. We'll have the slides available on the GitHub, uh, soon after the talk or next, early next week, and we'll explain for that later. Um, let's start with the biggest, uh, the smallest, uh, the simplest explanation. I'm sorry, English is not my first language. Um, why are we talking about Windows and not Linux or, or Apple? Uh, Linux drivers are basically all in the tree, so, except for specific examples that are proprietary code, most of the Linux drivers are available in GitHub or open source and you can find them and look at them. Apple is a closed garden, so whatever Apple does, Apple knows and Apple sees, so we don't really care. There is a caveat, um, Apple does have, uh, their Windows drivers for their hardware. We did skim those, but we didn't find anything substantial there. What is a driver and how it's used? So basically in, in, in the computer and operating system, you have a user space, you have kernel space and then you have the hardware. For applications in user space to talk to the hardware, you're gonna need some sort of way to do this securely. Otherwise you violate every known concept of a security boundary ever. You don't want a ring 3 or user space application to be able to read and write spy flash. It's just wrong. So we have this concept called drivers. These drivers are running within kernel space. They communicate with the kernel, the kernel gets requests from the application, passes it on to the driver, the driver does its magic, communicates with the hardware and goes back and forth. It's pretty straightforward. These drivers in Windows are signed. Now, um, for a driver to run and be executing kernel space in these days, it needs to be signed and, uh, it needs to be certified by Microsoft. We're not going to go into the entire process of how drivers are certified by Windows. It's not, it's not easy to explain. There's a back and forth. I don't know, some of you are, are sparking right now. Yeah, because you probably try to sign drivers with Windows. There is a reason for that process. Um, but it's, it's not quite straightforward to get out from reading blog posts on the internet. Um, the point that, the key point in this slide is Windows 10 signing process, right? So Microsoft introduced this new process called EV. EV stands for extended validation. Um, if you want to EV sign a certificate, uh, uh, driver, you need to have this EV certificate which, um, allows basically Microsoft to co-sign the driver with you and give that Wickel certification side by side so you have a driver that's certified by Microsoft and, and operates and everything's great. Um, EV, these are slides we found from Microsoft presentation given in Shanghai 2015, uh, when they introduced this. Uh, funny, funny thing about this is that the bad guys, the bad guys reference here and that EV certificates are better because it means less malware, but not for legacy. So if you have an old driver that's already signed, do whatever you want with it. Ever Microsoft is a good guy that will let you load the driver even if the certificate's expired. Um, we do have one of these drivers that for some reason loaded and we kept double checking the properties and it's un, it's just expired, the certificate, what the hell's going on, so we're in sign tool. Sign tool said it's, uh, it's not within the required period of verifying, no idea why it loaded, it's still loaded, I don't complain. So at this point we were like, maybe we'll get our own EV certificate, we'll try to make our own example driver and, you know, have some fun with it. We saw this list of things to do, of getting it and, you know, you have to have the legal agreements to sign on behalf of your organization. I don't think so. It's just too much of a hassle. We work for a company that company has their own driver they develop, they, they sign it with Microsoft. I don't want to risk anything potentially with Microsoft, so highest of notes. So let's, let's take a look at some of the, uh, the issues that we've seen in the past with sign drivers and, uh, one example that we, uh, that a lot of people know about is, uh, read, write everything and, uh, there's also, uh, Low Jacks is one of the more interesting, uh, uh, malware that we saw that was using sign drivers. Slingshot was another APT that was using, uh, this class of driver specifically to bypass Windows protections. Uh, we've also seen this type of, uh, driver being used by game cheating engines or, uh, anti-cheat software. Uh, there was an interesting case, uh, Capcom driver where this driver was signed by Capcom for a video game that it would turn off, uh, SMEP protection, execute code that you pass in from user space and then, uh, continue on. And that was found pretty quickly and people were able to, uh, know to block that. But the, these issues keep popping up individually. So we were trying, wanted to look, uh, across the spectrum a little more. There's some, uh, nice examples right up. So if you, there's a vulnerability in a MSI driver and here's how to use it to escalate from, uh, user space non-elevated to, uh, anti authority system by using one of these signed drivers. So to take a, a little bit of a closer look, uh, read write everything, it's essentially, it was designed to give you the ability to look at these hardware interfaces in your system, basically explore the system, see what the state of the machine is, and it basically has a, a user space app and then a signed driver which is intended for this purpose. But, uh, the problem is that it, it allows access to components that have really important security properties and they need confidentiality in some of these, uh, resources and, uh, integrity in other resources. So you're basically given free reign to arbitrarily read, write, modify some of the device, some of the interfaces that Windows depends on, Windows security depends on these not being tampered with. So this, this was an interesting app, um, but then, uh, Lowjax was a malware that was found in the wild, it was an APT that they actually brought a copy of that RingWrite, right, anywhere driver along with them as part of their infection. Uh, their implant tool used read write everything in order to, uh, gain direct access to the spy controller and then they were able to use that in order to write their own malicious module into the, into the system flash and, uh, persist in that UEFI firmware that would, uh, survive reboots, operating system reinstalls because they have the ability to directly talk to the hardware through this mechanism. And even if your system did not have this read write everything driver on it, they just brought it with them, they were able to load it and use that capability in a really interesting, uh, attack. Uh, there was another APT command, uh, campaign that also basically, it also brought their own driver. Their driver was not signed, but they exploited, uh, four different drivers that had, uh, read write MSR capability in order to get arbitrary code execution in the kernel and bypass driver signing enforcement so they could install their own, uh, kernel root kit. So this is out there actually being used in the wild by real attackers. So there's a few different reasons why you might want to use one of these drivers. Basic one is just privilege escalation from user space, get, either escalate a user from a normal un-elevated user to admin user. There's also just getting code execution running within, uh, within the kernel itself. Uh, another possibility is you can use some of these, uh, drivers to disable bypass, uh, window security mechanisms and sometimes that can be used in order to, uh, escalate privilege within the kernel or just get access to resources that you shouldn't get access to. Uh, there's another, uh, motivation where essentially getting access to the hardware itself is, is really useful. You can modify system firmware, you can modify device firmware. There are a lot of devices that still have unsigned firmware and you can go basically write your malicious modification to either the system firmware, get code execution before the operating system loads or modify a device and, uh, have a persistent, uh, implant in a particular device. And there's some other things you can do with direct hardware access, but those are some key ones that we wanted to specifically call out. So there's a, a few different attack scenarios. Uh, if the driver is already on the system and loaded, the driver itself controls the policy for who can talk to this device. So, many drivers, you don't have to be admin. You can be a normal non-elevated user in order to talk to this particular device. There's another scenario where the, the driver is on the system but it's not loaded yet. And in that case, you do need admin privileges to load the driver. Uh, we have found signed applications that you can use to load drivers, uh, that are signed by well-known trusted vendors that you could potentially use one of these applications. There'd be a little UAC pop up that says, would you like some trusted vendor to modify your computer? And that might be a means to, uh, load the driver if you don't have admin privileges. But you can also just wait. So the, if you, if it's already loaded, you don't need to be admin. If it's not yet loaded, you do need admin essentially. And there's also the scenario where the driver isn't on the system. All of your, all of your drivers are fully up to date. Uh, malware can bring a driver with it and load that. In this case, they do, you do need to have escalated to, uh, an admin in order to load the driver. But there have been a lot of privilege escalations. Uh, you can bring an older version of the driver. So, uh, even if the newest version has been fixed, in many cases the old vulnerable driver will still be loaded into windows or loadable into windows. And you can just bring the old version, load that, and use this kind of capability. And Lowjax did this for their in the wild APD campaign where they brought an older driver, they were able to load it and get direct ex of the hardware and implant the UEFI firmware. So we've, we've seen this pop up every now and then just one at a time, there isn't really, uh, industry wide fix for this problem or industry wide effort to go fix this. So we wanted to, uh, take a look and see, see how hard it is to find these drivers and how widespread it is. So we, uh, focused on, because we're interested in signed drivers so that we're loaded into windows, we, we threw out any that we found that weren't signed. Because we're looking for drivers that talk to hardware interfaces or have that kind of capability. We look for drivers specifically from, uh, firmware and hardware vendors. And then just to make it a little easier, we, uh, went with the smaller drivers, it would probably be more simple. So also looking for things like, uh, read write MSR opcode, uh, move to control register in and out opcodes. Those are specific x86 instructions that are talking to drivers or talking to devices or hardware in a way that we're interested in. Uh, one other thing to keep in mind is that, uh, there's two different, uh, driver, there's two different mechanisms or frameworks that you could write your driver. There's the, uh, older, uh, Windows driver model and, uh, the, the newer Windows driver framework. Uh, with the, uh, the older version you basically, your driver would just call IO create device and then write a address of a handler for, uh, all of the requests that, that, uh, user space is going to make to your driver to a specific address within, uh, a structure that it passes to this IO create device, uh, function. Uh, the Windows driver framework has changed a little bit but it's a, a similar kind of concept where you, uh, you have a couple functions that are set up and, uh, eventually you do have a, a main dispatch or, uh, IOctl handling function that will handle all of the requests from user space. Uh, uh, I, I don't know if we mentioned it but IOctl is basically IO control. So there's a specific number that you can say, I want IOctl one, two, three, four. And, uh, the, the dispatch will call your, your kernel handler and say, here's your IO request packet with request one, two, three, four and the data that was passed from, uh, user space. Um, so there is a little bit of a difference where, uh, in IO create device versus this, uh, create device secure function. If you, if the driver is calling a create device secure it can actually specify a, uh, uh, security descriptor which is a policy that says who can talk to this driver and what type of access they have. Uh, this is a, an example of one of these, uh, uh, SDDL strings. Uh, in this case it's a discretionary access control list that allows generic all to local system and generic all to built in administrators. Most of the drivers that we looked at don't bother to set any kind of policy so a normal elevate, a normal non-elevated user can talk to these drivers. So, we essentially spent two weeks looking for drivers. We, uh, skim through hundreds of, of, uh, driver files just doing, uh, manual disassembly analysis looking for this type of, uh, behavior. Uh, we found 42, uh, different vulnerable signed drivers. Uh, we found 42 vulnerable signed x8664 drivers. Uh, we did find, uh, a lot that had a 32 bit version so it was around, uh, 80 something total files but we did find one itanium driver that I don't know if anybody still has an itanium machine out there but, uh, we've, we've also found more drivers since but there were, uh, 42 drivers. 42 x8664 drivers that we were looking at but, uh, the types of things that we found were things like basically you could ask from user space for the kernel to go read and write virtual memory in the kernel or to read and write to, uh, physical memory addresses. Uh, you could go talk to, uh, MIO devices, uh, model specific register, arbitrary read, write, uh, control register access, talking to PCI devices, some SM bus access, just basic, uh, in and out. So, uh, here's an example of, uh, uh, mem copy that we found in the kernel where they literally are taking the, the source destination and size for this copy operation from user space. There's no checks of any, any, uh, pointers, uh, no pointer checks, no length checks. You can literally just ask the driver to go copy memory around for you. Um, this, this can be used to mod, to modify, uh, kernel code and data structures. Um, patch guard will detect some modifications. It doesn't detect them all though. So, it's, if you have a, a primitive that's this flexible, you can do a lot of interesting things with it. Uh, you can copy from user space into kernel memory the other way around. It's, it's really useful. Uh, another thing that we found is just basic arbitrary physical memory write, uh, read and write. Uh, in, in this it's intended so that you can use it to go talk to device drivers and do MMIO access. Uh, in this case, there's also no, uh, sanity checks. You could basically have any, any address, any size and go try to call this function, uh, MMAP, MMAP IO space. Um, there has been a change in how Windows deals with this function as of, uh, uh, 1803 where they've tried to limit the scope of what you can do with this physical memory write only to those, uh, MMIO addresses. So, uh, older systems before 1803, you could just map, map any kernel address and do a read and write there also. Um, but even after 1803, you can still go, uh, get direct access to the hardware and do some pretty interesting things there. Uh, there, there's also drivers that just expose the, the physical to virtual mapping. So you can look up addresses in virtual space and find their corresponding page in, uh, the physical address layout, which is, is, it's useful for, for dealing with actals that give that kind of, uh, physical address, but it's also useful for, uh, things like Rohammer where it's like knowing where things are mapped physically into, into the address space. This type of functionality can be really useful. So, another thing that we, uh, looked at was just arbitrary, uh, model specific register, uh, read and write. Uh, here's an example where they're taking the address of the model specific register to read, no filtering, directly give you the data back. So if you're not familiar with model specific registers, uh, these are, uh, internal registers within the, the CPU that, like you have your general purpose registers for normal executing code, but these special purpose model specific registers are, uh, in addition to that and they were originally used for experimental features that Intel wanted to try out and some of those, uh, experimental features, they decided these are really useful. So we're going to turn them into architectural, uh, model specific registers or MSRs such that from a certain point going forward, they're committing to support this particular usage model for the, the value that you put into, into the MSR will be used in a architecturally defined way. And, uh, they do have, uh, special op codes, special X86 op codes, uh, read MSR and write MSR in order to, uh, access these, uh, registers. Uh, one interesting point is that you can only access them from ring zero. So ring three, if you try to read a MSR, uh, you'll get a, a fault and it, it won't allow you to, uh, get that data. But we, we have a primitive here where you can read MSRs and there's some pretty useful things that you can get just by reading the MSR. Uh, we also found, uh, model specific write primitives and there are some really, really critical model specific, uh, registers that, uh, are, are especially interesting like, uh, star, C star, L star and C star where in order to even transition from user space into kernel space or ring three into ring zero, when you call a, when you execute a sys call instruction, it will, as part of that transition going from use, from ring three into ring zero, it will take the address that's stored in this L star register and use that as the address that it starts re, executing in ring zero. So if you, if you have the ability to write to this register from user space, that's pretty dangerous. So there's also, uh, control registers and there's a lot less control registers but they store some key, uh, control bits for the processor. Um, CR three is the base of the virtual memory, uh, paging tables. So knowing where that is could potentially be useful. Uh, CR four has, uh, uh, some other security controls. CR zero has some security controls. So in this case we have a arbitrary ability to read any of these control registers, uh, including the base of the page table structure in kernel space, not the user space copy of the page tables. And there's also, uh, control register write, uh, functions where you could take an arbitrary value, an arbitrary control register that's taken directly from your user space, uh, input buffer and write the value to the control register. And some pretty, uh, key ones that are, that some of the security, uh, controls in Windows depend on is, uh, supervisor mode execution protection. That basically is, uh, one of the features that helps protect against a number of different attacks that have been very successful against Windows in the past. Uh, there's also this, uh, write protect bit in CR zero where if, if the write protect bit is not set in CR zero and, uh, the, the kernel or ring zero code tries to write to a page that is marked as read only, it will completely ignore the permissions in the page table and let you do the write anyway. So it's a, it's an interesting control. So it's kind of her security hardening but it's useful to know about it. If we can write to that, that can help us. Other things are just arbitrary, uh, IO port write. You can write arbitrary values, arbitrary IO ports. It's, what you can do with that is platform dependent. You could possibly use that to modify system and device firmware. Uh, we, we saw a really cool, uh, vulnerability last year involving a speed BMC configuration where there were debug features that were accessible from the host and you could through IO reads and writes arbitrarily read and write into the BMC address space. Uh, laptops have, look likely have an embedded controller that you can talk to over IO access. And then there's also legacy PCI access over IO port CF8, CF8, CFC. There's also just functions to literally do that legacy PCI write. So there have been uh issues with uh, security of PCI devices and that comes up a lot. So to kind of look at the MSR case a little bit more, essentially the LS, L-star MSR is pointing to an address into kernel memory where we don't know exactly where the kernel has been loaded. There's address randomizations happening. So when, when this transition happens, when you go from user space to kernel space, it starts executing at the, at the address that L-star points to. So if you can write to L-star, we can basically allocate a buffer in user memory. And then when that transition happens, the very next, next call that happens, it'll start executing from your pointer instead. But there's some complications to that. So one of the features that I mentioned, uh, supervisor mode execution prevention is intended to uh, stop this feature. There have been a lot of bugs where you could get the kernel to uh, jump to your, your pointer. And they added this feature to the CPU, uh, I think in a Sandy bridge where, maybe Ivy bridge. But it's essentially a feature where if the CPU is executing in a, in a ring zero and it does a code fetch to a page that's in a user, user mapping, it'll cause a, a fault. And this is controlled by a bit in the CR4 register. So if we have a read write primitive for uh, control registers, we can just read this bit from, or we can read the CR4 value, clear the bit and write it back to CR4 and in order to uh, get around supervisor mode execution prevention. Um, there's another uh, complication that uh, uh, there needs to be a little bit of state change when you're transitioning into the kernel space. So although it starts executing in ring zero, it hasn't fully switched into kernel space. So you need to do a little bit of extra work entering and executing your, your payload there. And then there's also uh, uh, kernel page table isolation. So as part of the, the meltdown mitigation for uh, one of the Intel CPU issues, uh, they basically isolated the kernel pages so they have two different sets of pages, one for user space and one for kernel space. So uh, we do need to know the address for those kernel page tables in order to fully be able to switch into kernel space. Uh, but if we have an I-Octol that we can arbitrarily read CR3, then we can, then we can get the address of that kernel uh, page table base so that when we build our payload we could just swap in the kernel page table pointer and do what we want to do. So we have a couple little demos of uh, switching of uh, some of these uh, features. Uh, quick note, all these demos are in PowerShell. So we, we have a basic uh, uh, so this, this one is not PowerShell, but this, this is just a simple. So we, in order to, to do our research we basically uh, made a, a simple tool to uh, load any arbitrary driver for us. So instead of needing to uh, instead of needing to write a helper to load it and deal with it, it's just a simple tool to load a driver, create the service, start the service for us so we could try things out. So in order to do this, we were running as administrator. Um, the other demo that I'm about to show uh, is not running as administrator. Yeah. So in, in this case we basically are reading some uh, state from basically uh, the kernel is being loaded at a random address. So from user space not elevated at all, we can uh, read the uh, the address of that uh, entry point into the kernel and uh, understand where the kernel is loaded. So this can help us with uh, with further attacks that depend on where, where the kernel is loaded into uh, into the address space. We also know the, the base of the, the page tables is this uh, second value so when we're building a payload we can use this, this value to uh, make that easier. So there's also uh, the SMEP bit in uh, in CR4 where we can also like, in this case we, we read CR4, we saw that it was enabled, we cleared the value, we wrote it back, we see that it's still, it's, it's disabled now uh, and there, there is a uh, a feature in Windows called uh, Patch Guard that will go and look for uh, configuration of the system, look for dangerous things and uh, we found a write up that meant, that said that they were able to measure that they were reading these MSRs every 30 minutes. So, that's a lot of time to uh, get your malicious code to uh, run. And so we, we were testing, it didn't crash even after like 45 seconds. We did see some cases where it, it would crash after you wrote to the MSR but it's uh, it seems like plenty of time in order to uh, get your, your payload working if you want to use this for. And this is on a uh, 1903 system, so it's latest, has the latest version of uh, of uh, Patch Guard. Okay. So, some of the problems is like, we, we took all of these drivers, we uploaded them to Virus Total, none of the drivers came back as malicious, they're loaded by Windows but, AV isn't really helping us with this issue because you can, you can use a lot of these drivers to attack AV and bypass some of those, some of the, those uh, protections. So we, we were hoping that we could actually fix this. So, Microsoft does have a virtualization based security and uh, hypervisor enforced code integrity. Um, those uh, those are only present from uh, 7th generation CPU and newer. Uh, also there are compatibility issues that prevent you from turning this on and HVCI will help against some of these issues but uh, not all. And I have a, a Cabby Lake laptop that is pretty new and should support it but I have compatibility issues and I haven't been able to actually turn on this feature. Um, there, there's also some uh, enterprise uh, device guard policy that you can configure to block known drivers once they're known to be vulnerable but there hasn't been any really industry wide fix for this yet. So we're hoping to uh, fix that. So all of these, all of these drivers that we found originally were just through manual analysis. So we were looking how can we actually automate this and started looking at the uh, anger framework for uh, symbolic execution. And if you're not familiar with anger or symbolic execution uh, it essentially allows you to dynamically execute the parts of a program and every time you get to a conditional branch it will try to execute both paths and see what happens. So it's really useful but it's easy to uh, run into issues but so I, I got an initial script just to try out the idea working in about a day and it works really well in some cases. In other cases the code is complex enough that you run out of memory and you have a, a state explosion because there are so many conditional branches that it had issues. But for, for what that actually looked like for trying it out, we uh, we had a specific driver that we know is vulnerable and we know the, the address of the handler that, that main act will dispatch is at a particular address and we know the address of a right MSR opcode that we want to uh, search for and see if this is actually taking data that's passed from, from user space. So essentially you just need to load the driver into anger in this case we don't care about uh, libraries so we'll not load libraries and then uh, create a uh, an anger uh, execution state object that uh, starts execution at the iocl handler, the dispatch function. And we can take that uh, IO request packet that structure and uh, basically create symbolic regions for those parts and set pointers so that when we're starting execution at the uh, iocl handler it will have these uh, these uh, symbolic regions as the, the input data that we're passing into this function. Then you can uh, create a sim, simulation manager and just let it start executing code from the uh, from the iocl entry point with a target address of the uh, right MSR address. So we're trying to reach that address. If it's found we just print that, we print that a path was found and whether the uh, the input data to this right MSR is taken from the input buffer if it's symbolic data. And it, it worked, it completed in less than five seconds and we prove that when we reach this uh, MSR at, write MSR opcode uh, that the address and uh, data that will be written to the, the CPU register is uh, included in the input buffer. It even tells you the specific d-word offset into the input buffer for where you need to structure your, your data to, to talk to this driver. And it, it completed in uh, five seconds literally the, the last three slides that I showed you, that's the entire script to uh, to do this and prove that, that this is actually taking input from the user. Uh, another issue is that we want to automatically find that iocl handler ourselves so we don't have to manually open every driver, do some disassembly, find that prime, that initial dispatch function. So for uh, WDM Windows driver model uh, drivers, it's a lot easier. We can easily just set a, a uh, memory write breakpoint on that structure, structure element in the driver object. And uh, this, this script right here, that's an all you need to find the iocl handler for these WDM drivers. We can also uh, automatically find the uh, iocl number so you have a driver, there's a right MSR, it'll tell you that there's a right control, a control register or an MSR. It'll tell you the number you need to pass for the iocl. It can tell you what values you also need to put into the, into the input buffer. So in this case, uh, this list of constraints down at the bottom were automatically detected. And uh, anger can actually uh, simplify those for you. So these three constraints at the bottom basically are simplified to the value at the first D word in uh, the input buffer needs to be four. And then the second uh, there are the, the third and fourth D words are the value that's written to this uh, CR4 register. So we can actually find a lot of information automatically. Um, there are some problems with, with this uh, anger is based on a VEX which was part of Valgrind so it was all user space applications. And as far as we can tell it was never used to analyze privilege code because it literally has decode errors when it runs into some of these privilege op codes. So the, the decompiler and instruction lifter it, so it lifts into an immediate, intermediate representation. And that part of the code, it runs into decode error and it doesn't know what to do. So there is some functionality that was added in the Python framework on top of that where you can write a Python module to kind of emulate or implement what this op code should have done. So we were, we were able to take advantage of that and have it work more reliably on, on more uh, on more uh, drivers. So one other problem is that it currently only supports, at least the tool that we wrote only supports uh, WDM drivers. We do detect if it's a WDF driver and have some ideas on how to make it work with uh, WDF drivers also. It's just a little bit more indirection and hooking but it should be fairly straightforward. Um, and then there's the issue that some drivers are a little bit more complex and cause it to run out of memory. I've had it run out of 64 gigs around. So we uh, we, we need to fix a few things. So I'll let, let Mickey do it. So um, now for a little bit of uh, naming, shaming and faming. Uh, we talked about 20 total vendors. These are the ones that we can disclose right now. Some are not um, ready to release updates. Some did not respond. Some said acknowledged but we haven't heard back from. Um, and some are really working on a fix but because they're in regulated environments, they require more time to go through certification. So we're not gonna disclose them. We're gonna go through um, everything we've been through talking to these peep, to these guys and, and these uh, companies since uh, late April, early May. Uh, we're gonna start from the best example to the worst. Um, the best example we had is with Phoenix. Phoenix is one of the big three IBVs. I have never heard or experienced a better response than Phoenix. We, we, we started with, with the first disclosure batch to send out to vendors. Um, I think Monday that week. And we said yeah, we'll finish it up. We'll send it on Tuesday. Obviously it ended up Friday at 5 p.m. And we sent it out to emails and we went home. Saturday morning we got an email back saying we acknowledge the issue. We're working on a fix. Within six weeks they already had a fix ready to deploy to customers. This is textbook. Like I've never, ever experienced anything like this. Especially with a driver. Uh, we also sent an email to cert and uh, cert CC. We, for some reason it got lost in communication with US cert. Uh, it ended up calling them a couple of days ago and they did receive it. So I don't know what's going on from that perspective. We did get a receipt but um, no actions were, were prescribed for us from, from certs. Microsoft. Uh, now that's a story. So Microsoft's model of, of the operating system is basically give third parties the option to write their driver, right? It's like, I have a company, I have a product. Here, write code to interface with our product. Um, the problem with this class of issues is a lot of drivers fall into that caveat where some, someone might write bad code. So what can Microsoft do about it? They can't just say hey, okay people. Uh, write some code but don't make it bad. It's a bit problematic. So we had a, an initial discussion with them and, and, and send them a note, say hey, what's your, what's your view about this? And we got a response from MSRC tier one that said, not a problem. Uh, talk to you later. We sent another email later on asking if they're really sure. It was a back and forth. And the end of the day after uh, quite a few rants on Twitter, we ended up getting to communicate and ended up doing a couple of face-to-faces here in Vegas. Uh, it changed the complex, the entire conversation. Uh, I'd like to say thank you to Krista Anderson and Nate Warfield for being very good at communicating and uh, forthcoming and trying to help. Also to Kimberly, Marissa, Mary, Yustas and Gaurav, I hope I'm not butchering that name, for helping from MSRC site to clear everything up and, and um, help sort things out. Now, the worst driver award goes to Asrock, um, because this is one of four, I think? One of four sign drivers that does all of this. So, it's quite impressive. The, you try it award goes to Nvidia for telling us that the driver that we found is internal. So, it doesn't merit a CVE because it's, it requires a security hardening uh, effort internally. Although it is distributed by MSI on their website as a tool for updates for their graphics cards. So, it's internal tool but it's distributed by an OEM on the internet. Okay. The worst ones are these four that did not respond. So, out of these four there is one, um, that completely doesn't respond. So at least some of them sometimes respond. But real tech. I've had um, researchers during this time in Vegas we talked to each other and we, we share notes and we discuss uh, you know, experiences like, oh this vendor sucks, this vendor is great. And no one in real tech is answering any emails. So, if anyone from real tech sees this, please check your inbox, inbox and reply to something. Um, a few advisories are coming out. So, Phoenix did June 21st within amazingly quickly time. Uh, already sent to OEMs. So, uh, the fixes that Phoenix inside an AMI will release. The three big BIOS vendors are gonna go get distributed to OEMs. And um, OEMs will then distribute it to customers. Uh, Intel had a fix in July 9th, Huawei in July 10th. Uh, let's see. Inside is today. It's the next slide. And a couple more coming out next week. We can't talk about it. And a few more during the, until the end of the year. Um, inside was kind of enough to send us this, uh, statement. I'm not gonna go through it, but the gist is, they're fixing it. Microsoft send us this statement. I'm not gonna go through this because we've been through enough. Uh, and now we're moving to conclusions. So, basically, bad drivers are bad. Um, people that write ring zero code and write it badly are a danger to society. Um, these, some of these drivers, like the easiest way to fix this is, okay, I'm a vendor, I wrote a driver, I own up to it, I revoked the certificate. Done. Can't load it anymore in Windows 10 at least. Um, so getting vendors to, to, to revoke the certificates is, is not as easy as sometimes. Like we had with Phoenix, but um, it will be a great help to do this. Like, the biggest majority of, the, the majority of drivers that we've seen are old. They're not new, brand new 2018, 2017. Some of these go back to, 2008. So, just revoke the certificates. This is like a big problem. It's not just specifically, it's just a class. Again, um, multiple researchers have disclosed these drivers separately at a time, but the problem is systemic and we wanna, we wanna hope that, we're hoping that at some point this can be fixed in a larger scale. Windows 10 is, is moving towards this. There's mitigations in place. There's HVCI, um, virtual based security, but you know, you have to have a 7th gen CPU and above for HVCI to work and even then not always does it work. Um, we are gonna release all, all our code, C sharp C plus plus and PowerShell examples on GitHub with the latest slides and the videos and, um, our tracking for all the drivers and where you can find them. Please check this GitHub on August 13th. Um, we did have this internal debate of whether to release it today or in three days. But because it was so close, we just decided to sort everything out, get through Vegas and upload it on the 13th. And I think we're done.