Key Windows 10 Anti-Malware Tech Critically Broken

Over a decade ago, Microsoft added support for a key malware mitigation technique that makes it harder for rogue applications to predict which code will be loaded into specific target addresses. This technique, called address space layout randomization (ASLR), stores data in different locations each and every time the application is run. If your code is riddled with security flaws, ASLR won’t secure it, but it will (hopefully) make it a little harder to find and therefore exploit. Or at least, that’s how it’s supposed to work — but Windows 10, it turns out, has a teensy little problem. It stores its supposedly randomized data in exactly the same place, each and every time.

To understand the magnitude of the failure, it may help to think of a loose analogy. Imagine you have an insecure mailbox that’s constantly being robbed. One hypothetical way to deal with this problem is to have many mailboxes scattered across your property. Each day, your long-suffering postal worker puts your mail (4-5 pieces) in a subset of available mailboxes (let’s say, 30 mailboxes total). A person could still search your property and find them, but it’s going to take longer and be more obvious.

Actually, with Windows 7 and EMET System-wide ASLR, the loaded address for eqnedt32.exe is different on every reboot. But with Windows 10 with either EMET or WDEG, the base for eqnedt32.exe is 0x10000 EVERY TIME.

Conclusion: Win10 cannot be enforce ASLR as well as Win7! pic.twitter.com/Jp10nqk1NQ

— Will Dormann (@wdormann) November 15, 2017

Now, imagine that instead of putting your 4-5 pieces of mail in up to five different locations, your mailman stuck it in exactly the same locations, each and every time. That’s more or less what’s happening here and it’s a problem afflicting both Windows 8 and Windows 10. Without any entropy (randomness), there’s no protection offered at all.

There are two ways to enable ASLR. One is to use the /DYNAMICBASE flag provided by the Visual C++ linker. This method still works perfectly, as far as anyone can tell. But since relying on programmers or vendors to always keep their code properly secure is a recipe for disaster, Microsoft also provides tools to force applications to use ASLR whether they’re designed to do so or not. This capability is baked into the Fall Creators Update as the Windows Defender Exploit Guard and was previously available as Microsoft EMET (Enhanced Mitigation Experience Toolkit), a GUI for enabling security measures already baked into the OS. The screenshot below shows the newer Defender Exploit Guard baked into Windows 10 FCU.

The problem is this: Apparently Microsoft’s default ASLR implementation fails to activate a key sorting method of ASLR, known as “bottom-up ASLR.” Microsoft’s own technical documentation describes bottom-up ASLR as method of assigning a base address by searching “for a free region starting from the bottom of the address space (e.g. VirtualAlloc default).” Enabling ASLR without simultaneously enabling bottom-up ASLR means that memory values are stored in exactly the same location each and every time. Here’s how CERT describes the problem:

Although Windows Defender Exploit guard does have a system-wide option for system-wide bottom-up-ASLR, the default GUI value of “On by default” does not reflect the underlying registry value (unset). This causes programs without /DYNAMICBASE to get relocated, but without any entropy. The result of this is that such programs will be relocated, but to the same address every time across reboots and even across different systems. Windows 8 and newer systems that have system-wide ASLR enabled via EMET or Windows Defender Exploit Guard will have non-DYNAMICBASE applications relocated to a predictable location, thus voiding any benefit of mandatory ASLR. This can make exploitation of some classes of vulnerabilities easier.

It finishes on the cheery note that there’s no practical solution to the problem currently available for deployment, but individuals can reenable the security ASLR is supposed to provide by importing the following registry key:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel]
“MitigationOptions”=hex:00,01,01,00,00,00,00,00,00,00,00,00,00,00,00,00

As always, we do not recommend mucking about in the registry unless you are certain you know what you’re doing. US-CERT has some additional details on both the problem and this fix available on its website. And yes, Windows 7 users, you get to preen a bit — this problem does not affect your operating system.

By Joel Hruska on November 20, 2017 at 3:12 pm