Get Off the Kernel if You Can't Drive
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 335 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/48385 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
TwitterFreewareBitDevice driverEnergy levelMereologyWindowJSONUML
00:46
Device driverBlogLink (knot theory)Device driverBlogDescriptive statisticsInformationDevice driverCodeSource codeJSONXMLUML
01:24
Crash (computing)Control flowComputerRoundingDevice driverStrutSlide ruleInformationDevice driverComputer hardwareWindowSpacetimeStochastic kernel estimationDevice driverCartesian coordinate systemFormal languageTelecommunicationRing (mathematics)QuicksortPhysical systemInformation securityComputerOpen sourceFlash memoryBoundary value problemJSONXML
03:13
Device driverProcess (computing)Computer hardwareBlogSign (mathematics)Device driverSlide ruleCausalityExtension (kinesiology)Validity (statistics)Process (computing)Public key certificateSelf-organizationPoint (geometry)Device driverWindowFrequencyElectronic mailing listFormal verificationMalwareCategory of beingStochastic kernel estimationSpacetimePresentation of a group
05:09
Computer programSoftware developerComputer hardwareDevice driverPublic key certificateCodeSelf-organizationActive DirectorySystem administratorComputer fileImage registrationProcess (computing)MalwareNoise (electronics)WritingReading (process)Device driverDevice driverPublic key certificatePoint (geometry)Category of beingFormal verificationFrequencySign (mathematics)Self-organizationElectronic mailing list
05:59
Game theoryDevice driverCheat <Computerspiel>WindowSocial classDevice driverMalwareProxy serverSign (mathematics)VideoconferencingType theorySoftware
07:03
Game theorySpacetimeComputer hardwareUtility softwareSoftwareDevice driverProxy serverInterface (computing)Component-based software engineeringINTEGRALMobile appState of matterDevice driverSpacetimeSpectrum (functional analysis)BitVulnerability (computing)Right anglePhysical systemCodeComputer hardwareWindowDevice driverInterface (computing)Category of beingInformation securityMalwareGame theoryVirtual machineWritingSign (mathematics)Ultraviolet photoelectron spectroscopy
08:41
MalwareDevice driverDirected setStructural loadGame controllerFirmwareOrder (biology)Direction (geometry)Ring (mathematics)MereologyDevice driverWritingGame controllerReading (process)Operating systemPhysical systemFirmwareDevice driverProxy serverFlash memoryStochastic kernel estimationMagnetic stripe cardModule (mathematics)CodeComputer hardwareSign (mathematics)Real numberRootkitComputer animation
10:12
SpacetimeStochastic kernel estimationMechanism designInformation securityProxy serverDirected setComputer hardwareFirmwarePhysical systemDevice driverControl flowDevice driverPhysical systemFirmwareDirection (geometry)Structural loadDevice driverWindowCode1 (number)Computer hardwareOrder (biology)Stochastic kernel estimationDevice driverInformation securityMechanism designDifferent (Kate Ryan album)Operating systemSpacetime
11:56
Device driverPhysical systemStructural loadProcess (computing)MalwareRevision controlInstallation artRootkitFirmwareDevice driverSoftware frameworkData modelComputer hardwareOpcodeLimit (category theory)AreaExecution unitPointer (computer programming)Formal languageInformation securityLocal ringSystem administratorComputer fileMechanism designDevice driverDevice driverCASE <Informatik>Numbering schemeComputer hardwareInformation securityWindowSimilarity (geometry)Functional (mathematics)Data structureSystem administratorWritingSpacetimeRevision controlLatent heatAddress spaceEndliche ModelltheorieSystem callSign (mathematics)Game controllerSoftware frameworkVulnerability (computing)Stochastic kernel estimationMagnetic stripe cardMalwareStructural loadDifferent (Kate Ryan album)Reading (process)WorkloadType theoryOrder (biology)Electronic mailing listFirmwarePhysical systemArithmetic meanCartesian coordinate systemString (computer science)BitOpcodeComputerMathematical analysis
17:35
SpacetimeDevice driverVirtual realityRead-only memoryStochastic kernel estimationMagnetic stripe cardControl flowProcess capability indexBus (computing)Virtual memoryLatent heatWritingSemiconductor memoryDevice driverGame controllerType theoryTotal S.A.Stochastic kernel estimationDevice driverAddress spaceEndliche ModelltheorieReading (process)Bus (computing)SpacetimePhysicalismVirtual machineSpeicheradresseOperator (mathematics)Open sourcePrinciple of maximum entropyComputer file
18:32
Patch (Unix)Data structureStochastic kernel estimationCodeToken ringRing (mathematics)Device driverStochastic kernel estimationPointer (computer programming)CodeSpacetimePatch (Unix)Form (programming)Kernel (computing)Principle of maximum entropyLengthSemiconductor memoryXMLComputer animation
19:21
Execution unitVirtual realityData structurePatch (Unix)CodeStochastic kernel estimationToken ringWritingRead-only memoryAddress spaceAddress spacePhysicalismoutputFunctional (mathematics)Level (video gaming)Virtual realityPhysical systemSemiconductor memoryMathematicsSpacetimeCorrespondence (mathematics)Type theoryMappingDevice driverWritingStochastic kernel estimationDevice driverWeb pageDirection (geometry)Reading (process)
20:50
Data modelBefehlsprozessorOpcodeControl flowReading (process)LengthCoprocessorAsynchronous Transfer ModeWeb pageData structureInformation securityVirtual machineExtension (kinesiology)Virtual realityDynamic random-access memoryDefault (computer science)SpacetimeRing (mathematics)WindowStochastic kernel estimationSeitentabelleEndliche ModelltheorieInformation securityMagnetic stripe cardPoint (geometry)Asynchronous Transfer ModeBuffer solutionNumbering schemeoutputPrimitive (album)Latent heatGame controllerOrder (biology)WritingData structureAdditionVirtualization1 (number)Functional (mathematics)CodeBefehlsprozessorAddress spaceBitGroup actionMereologySystem callWeb pageDifferent (Kate Ryan album)OpcodeCASE <Informatik>Read-only memoryReading (process)Virtual memory
25:15
FirmwareProcess capability indexServer (computing)LaptopAddress spaceSpacetimeGame controllerVulnerability (computing)Computing platformWritingCross-platformProcess capability indexVulnerability (computing)Information securityBitAddress spacePhysical systemConfiguration spaceFirmwareCASE <Informatik>WritingFunctional (mathematics)Magnetic stripe cardLaptopGame controller
26:09
Magnetic stripe cardPoint (geometry)Machine codeStochastic kernel estimationStochastic kernel estimationRandomizationKernel (computing)Group actionSpacetimeSemiconductor memoryAddress spacePointer (computer programming)Point (geometry)System callMagnetic stripe cardBuffer solutionProgram flowchart
26:54
Asynchronous Transfer ModeWeb pageBefehlsprozessorStochastic kernel estimationCodeReading (process)Primitive (album)WritingComputer wormSoftware bugGame controllerOrder (biology)Asynchronous Transfer ModeBitBefehlsprozessorCodeStochastic kernel estimationPrimitive (album)Web pagePointer (computer programming)Hydraulic jumpCausalityRing (mathematics)Reading (process)WritingJSONXML
27:52
Stochastic kernel estimationSeitentabelleWeb pagePhase transitionBefehlsprozessorStructural loadOrder (biology)SharewareComputer wormPointer (computer programming)Set (mathematics)Different (Kate Ryan album)Address spaceSpacetimeMereologyBitDevice driverRing (mathematics)
29:43
Structural loadDevice driverStochastic kernel estimationTable (information)Web pageOrder (biology)Service (economics)System administratorSharewareState of matterCASE <Informatik>Stochastic kernel estimationAddress spaceComputer animation
30:22
Stochastic kernel estimationWeb pageTable (information)Device driverStochastic kernel estimationSeitentabellePoint (geometry)Computer wormAddress spaceSpacetimeBit2 (number)BuildingComputer animation
31:02
Data bufferDevice driverReading (process)WindowMultiplication sign2 (number)Order (biology)Crash (computing)Configuration spaceComputer wormCASE <Informatik>MalwareMagnetic stripe cardRevision controlReading (process)Source codeComputer animation
32:13
Proxy serverInformation securityVisualization (computer graphics)Data integrityMachine codeDevice driverCodeBefehlsprozessorLaptopMathematical analysisElectric generatorRevision controlINTEGRALPresentation of a groupInformation securityEnterprise architecture
33:50
Process (computing)Software frameworkGenetic programmingScripting languagePersonal digital assistantCombinatoricsScripting languageMultiplication signSoftware frameworkComputer programBranch (computer science)MereologyCodeSymbol tableState of matterSemiconductor memoryCASE <Informatik>Computer animation
34:41
Software testingStructural loadDevice driverArithmetic meanState of matterAddress spaceMagnetic stripe cardLibrary (computing)OpcodeDevice driverCASE <Informatik>Right angleObject (grammar)Functional (mathematics)SpacetimeJSONXMLUML
35:27
Software testingGenetic programmingMereologyRead-only memoryPointer (computer programming)SimulationState of matterAddress spaceDialectMereologySimulationSymbol tableoutputData managementWritingAddress spaceBuffer solutionLetterpress printingMagnetic stripe cardCodeRight angle2 (number)Point (geometry)JSONXMLSource code
36:25
outputAddress spaceData bufferFunction (mathematics)Read-only memoryState of matterDevice driveroutputScripting languageDevice driverBuffer solutionSemiconductor memoryElement (mathematics)Right angle2 (number)Data structureDevice driverWindowAddress spaceBefehlsprozessorMagnetic stripe cardSlide ruleWritingEntire functionWordLatent heat
37:46
Constraint (mathematics)Video trackingGame controllerConstraint (mathematics)outputInformationBuffer solutionNumbering schemeElectronic mailing listMagnetic stripe cardWritingGreatest elementSource codeJSON
38:39
Representation (politics)Error messageOpcodeCodeMereologyCodeSpacetimeError messageOpcodeCartesian coordinate systemIntermediate languageCodeSoftware frameworkFunctional (mathematics)BitSemiconductor memoryDevice driver1 (number)Module (mathematics)Device driverRegulator geneComputer animation
40:37
Dependent and independent variablesRevision controlDevice driverPublic key certificateLength of stayDevice driverInformation securityRegular graphRead-only memoryMagnetic stripe cardWritingProcess capability indexReading (process)IntelContent (media)Public key certificateDevice driverMultiplication signSocial classQuicksortCodeOperating systemComputer configurationOnline helpRegulator geneGroup actionWebsiteEmailTelecommunicationData conversionDevice driverInformation securityDependent and independent variablesEndliche ModelltheorieMultitier architectureStapeldateiView (database)1 (number)WritingProduct (business)Integrated development environmentStatement (computer science)Perspective (visual)MathematicsSlide ruleMagnetic stripe cardBit
46:22
Control flowBlock (periodic table)Web browserComputerDevice driverSoftwareRead-only memoryData integrityInformation securityTrailCommitment schemeExploit (computer security)Statement (computer science)Entire functionContent (media)Software repositoryScripting languageCodeSlide ruleSharewareVideoconferencingDevice driverLink (knot theory)Machine codeDevice driverWindowBefehlsprozessorPublic key certificateRing (mathematics)Structural loadVideoconferencingOnline helpTrailMultiplicationSlide ruleScaling (geometry)Point (geometry)VirtualizationCodeMultiplication signSource codeJSON
Transcript: English(auto-generated)
00:00
So, I am Mickey, that's Jesse, um, that's our Twitter handles. If you want to ask us questions, uh, about anything we give at this talk, please feel free to, feel free to reach out and ask us, even next week or whatever. We're happy to help. But the agenda of this talk, well, we're going to start with a little bit of, uh, high level introduction
00:24
into what is a driver in Windows. We're going to 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 exploit for yourselves, and a couple of funny stories about disclosures. This
00:48
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 blog post and
01:05
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 our talk and based our, um, some of our
01:22
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
01:43
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
02:05
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
02:25
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
02:42
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
03:03
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
03:25
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
03:42
explain. There's a back and forth. I know some of you are, are smirking right now, yeah, cause you probably tried 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
04:01
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, driver, you need to have this EV certificate which, um, allows basically Microsoft to co-sign the driver with
04:27
you and give that wiggle 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 the slides we found from Microsoft presentation given in Shanghai 2015, uh, when they
04:43
introduced this. Uh, funny, funny thing about this is that the, 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.
05:10
However, 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, just expired the
05:24
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
05:42
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 and be half your organization. I don't think so. It's just too much
06:04
of a hassle. We work for a company, that company has their own driver they developed, they, they signed it with Microsoft. I don't want to risk anything potentially with Microsoft, so, highest of notes. So, uh, let's, let's take a look at some of the, uh, the
06:25
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, ReadWriteEverything and, uh, there's also, uh, Lojax is one of the more interesting, uh, uh, malware that we saw that was using sign
06:43
drivers. Slingshot was another APT that was using, uh, this class of driver, uh, 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
07:01
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 passed in from user space and then, uh, continue on and that was found pretty quickly and people were able
07:21
to, uh, know to block that, but the, these issues keep popping up individually, so we wanted to look, uh, across the spectrum a little bit more. There's some, uh, nice examples of write ups of, there's a vulnerability in an MSI driver and here's how to use it to escalate from, uh, user space non-elevated to, uh, anti-authority system by
07:44
using one of these sign 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,
08:05
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
08:24
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, Lojax was a malware that
08:46
was found in the wild, it was an APT that they actually brought a copy of that ring write 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
09:02
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
09:26
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 coman- uh, campaign that also, basically, it also brought their
09:44
own driver, their driver was not signed but they exploited, uh, 4 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
10:05
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
10:27
user, there's also just getting code execution running within, uh, within the kernel itself. Uh, another, uh, possibility is you can use some of these, uh, drivers to disable,
10:41
bypass, uh, Windows 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
11:02
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
11:20
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 few different attack scenarios. Uh, if the driver is already on the system and loaded, the driver itself controls the policy for who
11:45
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
12:03
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 can potentially use one of these applications. There'd be a little UAC pop-up that says,
12:22
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, uh, 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
12:42
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
13:02
admin in order to load the driver but there've 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
13:27
capability and Lojax did this further in the wild APT campaign where they brought an older driver, they were able to load it and get direct access to the hardware and implant
13:40
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, uh, 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
14:03
drivers and how widespread it is. So, we, uh, focused on, because we're interested in workload 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
14:22
capability, we looked 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, uh, 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
14:43
instructions that are, uh, 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
15:01
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,
15:21
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,
15:44
eventually you do have a, a main dispatch or 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 could say, I want IOCTL 1234
16:06
and, uh, the, the dispatch will call your, your kernel handler and say, here's your IO request packet with request 1234 and the data that was passed from, uh, user space. Um,
16:27
create device versus this, uh, create device secure function. If you, if the driver is calling, uh, create device secure, it can actually specify a, uh, a security descriptor,
16:41
which is a, a policy that says who can talk to this driver and what type of access they have. Uh, this is 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
17:05
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,
17:26
looking for this type of, uh, behavior. Uh, we found 42, uh, different vulnerable sign drivers. Uh, we found, uh, 42 vulnerable sign x86-64 drivers. Uh, we did find, uh, a lot
17:40
that had a, a 32-bit version, so it was around, uh, 80 something total files, but we did find one, uh, itanium driver that, I don't know if anybody still has an itanium machine out there, but, uh, we, we've also found more drivers since, but there were, uh, 42 drivers, 42 x86-64 drivers that we were looking at, but, uh, the types of
18:03
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 do read and write to, uh, physical memory addresses. Uh, you could go talk to, uh, MIO devices, uh, model
18:22
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
18:46
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- be mod- to modify, uh, kernel code and data structures, um, patch guard
19:05
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
19:20
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 MIO 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
19:45
this function, uh, mmap, mmapio 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,
20:04
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, read and write get direct access to the hardware and do some pretty interesting things there. Uh,
20:21
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 IACTLs that give that kind of, uh, physical address but it's also useful for, uh, things like
20:42
lowhammer 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 model specific register, uh, read and write. Uh, here's an example where they're taking the address of the model specific register to
21:02
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
21:20
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
21:43
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 opcodes, special x86 opcodes, uh, read MSR and write MSR in
22:03
order to, uh, access these, uh, registers. Uh, one interesting point is that you can only access them from ring 0 so ring 3 if you try to read an MSR, uh, you'll get a, uh, fault and it, it won't allow you to, uh, get that data but we, we have a primitive here
22:23
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's some really, really critical model specific, uh, registers that, uh, are, are especially
22:42
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 3 into ring 0, when you, uh, when you call a, when you execute a syscall instruction, it will, as part of that
23:04
transition going from use, from ring 3 into ring 0, 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 0. So, if you, if you have the ability to write to this register from user
23:22
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, CR3 is the base of the virtual memory, uh, paging tables. So, knowing
23:44
where that is could potentially be useful. Uh, CR4 has, uh, uh, some other security controls. CR0 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
24:00
structures 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
24:24
that are, that some of the security 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
24:41
the past. Uh, there's also this write protect bit in CR0 where if, if the write protect bit is not set in CR0 and, uh, 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
25:04
and let you do the write anyway. So, it's a, it's an interesting control. So, it's kind of security hardening, but it's useful to know about. If we can write to that, that can help us. Other things are just arbitrary, uh, IO port write. You can write arbitrary values to arbitrary IO ports. It's, what you can do with that is platform
25:26
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, a speed BMC configuration where there were debug features that were accessible from the host and you could,
25:40
through IO reads and writes, arbitrarily read and write into the BMC address space. Uh, 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
26:06
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
26:25
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
26:45
then when that transition happens, the very next, next syscall 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,
27:04
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
27:21
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
27:42
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
28:00
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 exiting your, your payload there. And then there's also a, a kernel page table isolation. So, as part of the, the meltdown mitigation for, uh, one of the Intel
28:23
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, to fully be able to switch
28:40
into kernel space. Uh, but, if we have an IOCTL 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, a couple little demos of, uh, switching of, uh,
29:05
some of these, uh, features. Uh, uh, quick note, all these demos are in PowerShell. So, we, we have a, a basic, uh, uh, so, this, this one is not PowerShell, but this, this
29:26
is just a simple. So, we, in order to, to do our research, we basically, uh, made, made
29:41
a, a simple tool to, uh, load any arbitrary driver for us. So, in, in, uh, instead of needing to, uh, instead of needing to write a helper to load it and deal with it, it's just, uh, 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, uh, running as
30:03
administrator. Um, the other demo that I'm about to show, uh, is not running as administrator. Yeah. So, in, in, in this case, we basically are reading some, uh,
30:21
state from, basically, uh, the, 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
30:42
us with, uh, with further attacks that depend on where, where the kernel is loaded into, uh, into the address space. We also know that 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, the SMEP bit in, uh, in
31:07
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
31:20
disabled now, uh, and there, 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,
31:49
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
32:01
plenty of time in order to, uh, get your, your payload working if you want to use this for- what's that? And this is on a, uh, 1903 system, so it's latest, has the latest version of, uh, of, uh, Patch Guard. Okay. Okay, so, so, so, so, uh,
32:24
some of the problems is, like, we, we took all of these drivers, we uploaded them to VirusTotal, 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
32:41
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, uh, 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
33:07
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 cabbie lake laptop that is pretty new and should support it, but I have compatibility issues and I haven't been
33:24
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
33:41
yet. So, we're, 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
34:03
essentially allows you to dynamically execute 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 really useful, but it's easy to, uh, run into issues. But, so, I, I got an initial script
34:23
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's so many conditional branches that it had issues. But for,
34:42
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, that main actual dispatch is at a particular address and we know the address of the right MSR opcode that we want to, uh, search for and see if this is actually taking data
35:04
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
35:24
execution at the IOCTL handler, the dispatch function. And we can take that, uh, 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, IOCTL handler, it will
35:46
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, sim, simulation manager and just let it start executing code from the, uh, from the, uh, IOCTL entry point with a, a target
36:06
address of the, uh, right MSR address. So, we're trying to reach that address. If it's found, we just print that, we, 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, if it's symbolic
36:24
data. And it, it worked, it completed in less than 5 seconds and we proved that when we reach this, uh, MSR, right MSR opcode, uh, that the address and, uh, data that will be
36:41
written to 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, in, uh, 5 seconds. Literally, the, the last 3 slides that I showed you, that's the entire script to, uh, to do this
37:04
and prove that, that this is actually taking input from the user. Uh, another issue is that we want to automatically find that iOCTL handler ourselves so we don't have to manually open every driver, do some disassembly, find that prime, that initial dispatch
37:22
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, uh, element in the driver object. And, uh, this, this script right here,
37:41
that's all you need to find the iOCTL handler for these, uh, WDM drivers. We can also, uh, automatically find the, uh, iOCTL number. So, you have a driver, there's a write MSR, it'll tell you that there's a write control register or an MSR. It'll tell you the number you need to pass for the iOCTL. It can tell you what values you also need to put
38:05
into, into the input buffer. So, in this case, uh, this list of constraints down at the bottom were automatically detected and, uh, ANGR can actually simplify those for you. So, these three constraints at the bottom basically are simplified to the value at the first
38:23
D-word in, uh, the input buffer needs to be 4. And then the second, uh, 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
38:40
problems with, with this. Uh, ANGR 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 opcodes. So, the, the decompiler and instruction lifter, it, so, it lifts into
39:03
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 opcode should have done. So, we, we were able to take advantage of
39:25
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
39:42
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 of RAM, so, we, uh, we, we need to fix a few things. So,
40:05
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, uh,
40:24
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
40:42
go through certification. So, we're not gonna disclose them. We're gonna go through, um, everything we've been through, talking to these, to these guys and, 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
41:07
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
41:22
that week and we said, yeah, we'll finish it up, we'll send it on Tuesday. Obviously, it ended up Friday 5pm and we sent out the emails and we went home. Saturday morning, we were working on a fix. Within six weeks, they already had a fix ready to deploy to
41:42
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
42:03
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
42:25
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
42:44
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, a, an initial discussion with them and, and,
43:02
and send them a note, say, hey, what's your, what's your view about this and we got a response from MSRC tier 1 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, a back and forth. And the end of the day, after, uh, quite a few rants on Twitter, we ended up getting to
43:24
communicate and ended up doing a couple of face-to-faces here in Vegas. Uh, it changed the comp- 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
43:41
trying to help. Also to Kimberly, Marissa, Mary, Eustace 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, um,
44:05
this is one of four, I think, one of four signed drivers that does all of this. So, it's quite impressive. The, you tried award goes to Nvidia for telling us that the driver
44:25
that we found is internal, so it doesn't merit a CVE because it's requ- 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 an internal tool but
44:47
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
45:02
respond. So, at least some of them sometimes respond, but Realtek. I've had, um, researchers during this time in Vegas, we talk to each other and we, we share notes and we discuss, uh, you know, experiences like, oh, this vendor sucks, this vendor's great. And no one in Realtek is answering any emails. So, if anyone from Realtek sees this,
45:26
please check your 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
45:40
fixes that Phoenix, Inside and AMI will release, the three big BIOS vendors, are gonna go get distributed to, 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, so the
46:04
next week, we can't talk about it. And, uh, a few more during the, until the end of the year. Um, Inside was kind enough to send us this, uh, statement, I'm not gonna go through it, but the gist is, they're fixing it. Microsoft sent us this statement, I'm not gonna go through
46:25
this because we've been through enough. Uh, and now I'm moving to conclusions. So, basically, bad drivers are bad, um, people that write ring zero code and write it badly are a
46:42
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
47:07
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 to back
47:21
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,
47:41
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
48:05
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
48:20
August 13th. Um, we did have this internal debate of whether to release it today or in 3 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.