Divide et Impera: MemoryRanger Runs Drivers in Isolated Kernel Spaces

Editor's Notes

• #2: Hi! I’m Igor! Today I’d like to show, to present you my MemoryRanger, which can isolate drivers code and allocated data from illegal access in the kernel memory. This topic is of critical importance for all security experts who are dealing with protection of operating systems.
• #3: A few words about mé. I earned my PhD 7 years ago. My area of expertise includes Windows Kernel security, rootkits detection and hypervísors /ˈhaɪpə(r)ˌvaɪzə(r)z /. I carry out research projects by my own as a hobby. I’m a fan of cross-disciplinary research. You can find my results in my blog. By the way I am fond of travelling and powerlifting as well.
• #4: I have divided my talk into three main parts. First we’ll be looking at the consequences of attacks on kernel memory. After thát, I’ll give you a brief analysis of Windows built-ín security features and research projects, which are designed to protect kernel memory. Finally, I’ll show you how I solve this problem using my MemoryRanger. Feel frée to ask me any questions at the end of the talk.
• #5: Nowadays kernel-mode drivers share the same memory space with the rest of the OS kernel. All drivers can read and write any part of kernel-mode memory without any hardware restrictions; this fact makes the modern operating systems to be prone to rootkit attacks and kernel exploitation.
• #6: Malware driver can dump the drivers’ code and tamper allocated memory, for example, Windows Internal structures and allocated data of the third party drivers. As a result, hackers can èscalàte privileges, hide their footprints, steal users’ secrets, or even disrupt industrial systems, which are controlled by drivers. Let me demonstrate you some of these attacks.
• #7: Let’s imagine two houses with private art collections: Russian house and a British one. In the Russian house we can see the panting of Wassily Kandinksy, you know he was a great Russian painter. The Banksy’s art is in the British house. I hope everyone is familiar with Banksy’s painting. And here is the “hacker-attacker”, who wants to grab all these masterpieces. If these houses are not protected the both private collections will be stolen. In the kernel-mode memory, the situation is absolutely the same.
• #8: If drivers are not protected the data can be stolen. Let’s see how it can happen. I will load two drivers. The Russian driver and a British one, which store their data in the allocated memory pools. After that, the attacker’s driver will be loaded to dump the drivers’ code and steal both Russian and British data buffers. And finally, I will show you how the attacker can even escalate process privileges. Let’s see how it can happen.
• #9: I am launching a Russian console /kənˈsəʊl/, which loads a Russian driver. In the same way, I am loading a British driver. Finally, the hacker-attacker is launching its driver to access kernel memory. Now, the attacker is trying to dump the Russian driver using its loaded address. Look, the attacker is successfully reading the first byte, which is M and the second one is Z. What about the British driver? Hackers are reading the first two bytes without any problems as well. We can see that the code of both drivers can be stolen. Let’s move on to the private data, which can be stored in the allocated memory. The Russian driver is allocating data and setting it content as “Wassily Kandinsky”. Let’s check “Kandinsky”. Fine. The data has been allocated. The British driver is allocating memory and setting Banksy as its content. Let’s check Banksy. It’s all right. Now the attacker wants to steal these “priceless” data content. To steal Kandinsky, hackers need to know the corresponding memory address. Let’s assume they do know this address. Usually hackers do know everything. So the attacker can read this data, and overwrite it. Here we have only four ones instead. We can see that the attacker did modify the data. Now, the attacker is entering the British house to steal Banksy’s art. After overwriting we have only four twos instead. Banksy collection has disappeared. Both data buffers were stolen and modified.
• #10: Hacker-attacker has successfully stolen both private collections. It means that our houses were not protected in a proper way. What was wrong? How can we defend them? We will see it later. And now let’s go back to demo to see how the attacker can even escalate process privileges. The attacker is starting the CMD. After launching it, he is getting its process ID. Done. He is copying its PID. We can see that the CMD has users’ privileges and it is not enough to reconfigure the Windows Firewall, which is expected. Now the attacker is trying to elevate the CMD privileges. He is using PRIV command with process ID. Checking the privileges again. The privileges have been escalated. Now the CMD has the highest privileges and now CMD can reconfigure the Windows Firewall service and even can turn it off. We can see only a small message, which confirms that the Firewall is out of service and it cannot be automatically restarted. This is very good news for hackers. But let’s wait for PatchGuard reaction, which is designed to prevent illegal memory modifications. We’ve been waiting for 10 hours it is quite a long time and nothing has happened. The OS has not been crushed. It means that PatchGuard didn’t prevent the invasion and the OS became infected.
• #11: So, we can see that Windows Kernel cannot prevent illegal memory access. The attacker can read the driver’s code, steal and change allocated data and even escalate process privileges without any security reaction, such as a Blue Screen of Death. Let’s have a look at the current situation with memory protection projects.
• #12: Look at this table. Microsoft has developed a number of security features for memory protection. The first one is “Device Guard”, which provides kernel code integrity by marking executable pages as “read-only” . So any modifications of the code will crash the system. Not bád. The second one is “PatchGuard”, which crashes the OS after revealing some changes of internal structures, for example EPROCESS unlinking. But you’ve just seen that PatchGuard does not protect EPROCESS structures completely. Finally, Windows Security does not protect memory allocated by the third party drivers. Many security experts from all around the world are trying to fill /fɪl/ this gap. There are several research projects, which are designed for memory protection. And you can see that there is no general solution, which can deal with all these issues at the same time. Today I will propose the solution. I’ll present you my MemoryRanger, which provides both integrity and con-fiden-tiality for drivers code and allocated data. 
• #13: Look at this. Nowadays kernel mode drivers share the same memory space with the rest of the kernel.
• #14: If we can move these two drivers with their allocations into two separate memory enclosures, we will protect their memory from each other. The thing is that Windows OS doesn’t give us such an opportunity.
• #15: Luckily for us, hardware virtualization technology provides the mechanism, which can be used to implement the idea of memory ísolátion /ˌaɪsəˈleɪʃ(ə)n/. I mean Extended Page Tables or EPT feature. Without EPT guest physical addrésses are used to access the host physical memory. Address H is equal to the address G.
• #16: Using EPT we get an additional or second level of address translation. When EPT is enabled, guest physical addresses are translated to host physical addrésses by traversing a set of EPT paging structures. Now, address H is equal to the address E, not to G. Let’s have a look at EèePèeTèe details.
• #17: EPT structures include EPT entries, which determine the mapping between the guest memory and the host memory. Each EPT entry includes memory access bits and page frame number.
• #18: This number is linked to the corresponding host physical address. It can be used to prevent access to the protected data. We can rédiréct / riːdʌɪrɛkt, / the access from the protected data to the fàke one by changing PFN value to the addréss of fake page.
• #19: Memory access bits indicate whether access attempts are allowed to the page referenced by this entry. Any dìsallowed access attempts will trigger EPT violations, and then control goes to the hypervisor. So we can trap read- write and execute- access to the page by changing these memory access bits.
• #20: Another interesting feature is that we can allocate several EPT paging structures with various memory access configurations. By switching between them, we can organize drivers’ execution in ìsolated enclaves. EPT feature seems to be very promising for the memory isolation /ˌaɪsəˈleɪʃ(ə)n/. Let me show you how all these ideas are implemented in my Memory Ranger.
• #21: I explored the following scenario. The OS kernel and other drivers are loaded into the memory and access their data. We have two legal access attempts, which are marked by green arrows.
• #22: As the Driver A is loaded, it allocates memory and áccesses this newly allocated data. All in all we have three legal access attempts, which are marked by green. Red lines indicate the following illegal access attempts. Driver A modifies the OS internal structures. Other Drivers read the memory of Driver A and try to overwrite its allocated data. As you remember that all drivers share at the same memory space, all these illegal access attempts are becoming uncontrolled.
• #23: Let’s roll back and launch MemoryRanger to isolate Driver A from the rest of the OS kernel. First of all, my MemoryRanger allocates the default EPT structure. All loaded drivers and Windows Kernel are executed inside the default EPT structure.
• #24: MemoryRanger traps the loading of Driver A and allocates a new EPT structure for Driver A. Memory Ranger updates all EPT structures in the following way. Only Driver A and OS kernel are executed inside new EPT. In the new EPT structure, memory access bits have been cleared to 0 for OS structures to restrict access from Driver A. In the default EPT structure, memory access bits for the driver A have been cleared as well.
• #25: After driver A allocates memory data, my Memory Ranger updates all EPT structures again. As a result, any access from other drivers to the driver A and its allocated memory will be trapped and blocked. Also, all áccess to the OS structures is forbidden for the Driver A. In the same way, Memory Ranger allocates a separate EPT structure for each new driver and updates all other EPT structures. This is the main idea. Let’s move on to the demonstration.
• #26: Let’s add one more treasure house to our criminal story, let it be American house full of Jackson Pollock paintings. Now we have three houses with three private art collections. The attacker is more motivated.  To protect these houses we need to build at least a fence.
• #27: It helps to prevent attacker’s access and isolates three houses from each other as well.
• #28: In the kernel mode, the drivers memory will be isolated in the same way. I will load three drivers. We call them Russian, British and American. All these drivers store their data in the allocated memory pools. After that, I will launch a malware driver in order to steal and modify these data buffers as well as dumping the drivers’ code. Finally, a malware driver will try to èscalàte process privileges. Let’s have a look what will happen if I launch MemoryRanger befo-o-re.
• #29: First of all, I am launching Memory Ranger console application. It loads the driver and activates the hypervisor. Then, I am launching three drivers: Russian, British, and American. Finally, the hacker-attacker is launching its driver. The attacker wants to dump the Russian driver first. He copies its address and we can see, that the attacker can read zero value. What about the next byte? He has a zero value as well. So the attacker fails to dump this driver. Now let’s read the drivers’ content using the driver itself. Now we have M and Z value. We can see that Memory Ranger can protect the content of the Russian driver. Now the attacker is entering the British house. He is going to dump British driver. He is copying its address and trying to read its content. So he gets a zero value again. MemoryRanger is foisting the fake null data to the attacker instead of the real one. Let’s try to access the British driver using the British driver itself. Now we are reading MZ bytes. It means that MemoryRanger can prevent unauthorized access attempts and grants the legal access.  And now let’s check if the American driver can read the content of the British driver. We have zero value again. <MSC>Memory Ranger isolates drivers from each other</MSC>. Let’s move on to the private data, which can be stored in the allocated memory. For the Russian driver I am allocating “Wassily Kandinsky”. Now, let’s check the allocation. Wassily Kandinsky. For the British driver I am allocating “Banksy”. Now, let’s check the allocation. Banksy. And finally for the American driver I am allocating the data and setting “Jackson Pollock”. Now, let’s check this allocation. Jackson Pollock. Now the attacker wants to steal all these treasures. Let’s see if he does manage that. He is starting with Russian house and Kandinsky art. He copies its address and tries to read. The attacker can read only a null string. He is trying to overwrite this data. It’s time to check if the Kandinsky has been modified. We go back to the Russian driver and check the allocation. Memory Ranger is protecting this data. Hackers failed to steal and modify Kandinsky. Now the attacker is entering the British house to steal Banksy. He is coping its address. And we can see that the attacker have read nothing again. He is trying to overwrite this data. Now, we go back to the British app and check Banksy collection. We can see that the MemoryRanger is protecting Banksy as well. And now let’s check if the American driver can access Banksy’s data. As you can see the American driver can read nothing. It is trying to overwrite the data. No results. Memory Ranger is ísoláting drivers allocation from each other as well. We can change the data only by the driver, which allocates thís véry dáta. Let’s check it. Let’s replace “Wassily Kandinsky” with “Ivan Aivazovsky”. The allocated buffer has been updated in a legal way. MemoryRanger is protecting even allocated data. Let’s start CMD to test privilege escalation attack. The attacker is launching CMD, getting its process ID, and checking its privileges. As we expected CMD has users’ privileges and cannot reconfigure the Windows Firewall. The attacker is trying to elevate the CMD privileges. The attacker is using PRIV command with process ID to escalate privileges. Let’s check the privileges. Cmd has still users’ privileges and cannot reconfigure the Windows Firewall service. It means that attacker has failed. CMD is not able stop the Windows Firewall service. The OS is protected.
• #30: So you have just seen that MemoryRanger prevents illegal memory access by running drivers into ísoláted kernel spaces or enclosures /ɪnˈkləʊʒə(r)z/. Let’s have a look at memory access rules which are provided by MemoryRanger.
• #31: Memory Ranger protects memory according to the principle of least privilege. Newly loaded drivers can access only their own code.
• #32: The read and write access to the data is granted only to the drivers, which allocate these data buffers. All other memory access attempts are blocked.
• #33: Memory Ranger protects drivers’ code from being dumped, it prevents read and write access to the allocated data, and finally, it prevents a privilege escalation attack. Let’s move on the Memory Ranger architecture.
• #34: This MemoryRanger includes the following three parts: MemoryMonRWX, DdiMon and Memory Access Policy. The first two parts were developed by Satoshi Tanda, during our collaboration. MemoryMonRWX processes the loading a new drivers and processes as well as all EPT violations, while DdiMon installs the invisible hooks on kernel functions, which allocate and deallocate /diː/ memory. I developed Memory Access Policy, which is a kind of brain for the first two parts.
• #35: For each newly loaded process, MemoryRanger adds the following structure to the list. This structure includes process ID and the address of its EPROCESS structure.
• #36: For each newly loaded driver MemoryRanger adds the following structure to the list. This structure includes an address of allocated EPT structure for this driver, as well as drivers start and end addresses, and the vector to collect memory addresses, which will be allocated by this driver.
• #37: Each time the driver allocates memory data MemoryRanger adds the following information to the list. This structure includes the address and size of newly allocated data.
• #38: Memory Access Policy manages all these lists and decides to grant memory access or to deny it.
• #39: To put it in a nutshell the MemoryRanger dispatcher is here. It processes three EPT violations and one VM exit.
• #40: For éxecúte violation MemoryRanger changes pointer to the appropriate EPT structure, so the kernel-mode code continues its execution into the corresponding EPT structure.
• #41:  For read and write violations MemoryRanger checks whether this access is legal. For an illegal access, the MemoryRanger changes PFN value of the protected page to the fake one, and allows /əˈlaʊz/ access to this fake data. Finally, it sets Monitor Trap Flag. As a result, after a driver reads the fake data the control goes to the hypervisor again.
• #42: Now MemoryRanger restores PFN value to the protected page and blocks any access to this page. Finally, it resets the Monitor Trap Flag.
• #43: Here are the steps how to add a new data to be protected by my Memory Ranger. First of all you need to create a list of addresses and sizes of memory regions, which need to be protected and clear access bits to restrict the access. Do not forget to update this list, for example using callback function.
• #44: Then dispatch EPT violations, which occur during access to your data. To process all violations you have three input parameters: type of access, address of module, which tries to access and finally the address of data, which has been accessed. You can only monitor the access attempts as well as redirect them.
• #45: Now let’s move final step, which is the benchmark assessment.  I measure the time of legal access from driver to the allocated data in four situations. Without memory protection with enabled cache, with disabled cache, and with two memory protectors: AllMemPro and MemoryRanger. AllMemPro or Allocated Memory Protector is the closest competitor for MemoryRanger, which I developed a year ago. AllMemPro uses only one EPT structure to prevent illegal access to the allocated memory. I can conclude that MemoryRanger is a bit slower than access to the memory with disabled cache and it three times faster than the closest competitor.
• #46: We are close to the end of our dramatic story. Let me recap very briefly on what I have presented and what you learn. First of all, I’ve demonstrated that drivers can access kernel-mode memory without any security reaction. Then, I’ve presented MemoryRanger, which can prevent unauthorized memory access by running drivers in isolated enclaves. Finally, I’d like to highlight one important thing. MemoryRanger seems to prevent the recent side-channel attacks. If anyone has a proof-of-concepts of Meltdown or Spectre, please send it to me.
• #47: I’d just like to conclude with old Làtin expression. It is on the screen. I believe it is applicable not only for ancient Sparta but also for kernel-mode drivers in newest Windows.
• #48: Thank you!