Researchers have developed a bypass for Microsoft’s EMET exploit mitigations by targeting a design limitation of the WoW64 subsystem that provides backwards compatibility for 32-bit applications on 64-bit systems.

Backwards compatibility, a necessary evil for Microsoft in its need to support so many legacy applications on Windows, may be its undoing as researchers have found a way to exploit this layer in the operating system to bypass existing mitigations against memory-based exploits.

Specifically in this case, researchers at Duo Security have slid past Microsoft’s Enhanced Mitigation Experience Toolkit, or EMET, a suite of more than a dozen freely available mitigations against memory attacks that include ASLR, DEP, Export Address Table Filtering, Heapspray Allocation, and return-oriented programming mitigations.

The soft spot, the researchers said, is the Windows on Windows, or WoW64, Windows subsystem that allows 32-bit software to run on 64-bit Windows machines. A sizeable sample of Duo customers shows some disturbing numbers in terms of vulnerable users. For example, 80 percent of browsers in the researchers’ sample size were 32-bit processes executing on a 64-bit host running WOW64, putting them all at risk.

EMET remains a viable protection for Windows users, one that Microsoft has marketed many times as a temporary stopgap between the disclosure of a zero-day vulnerability and the availability of a patch. But in the WoW64 example, EMET can be completely bypassed.

“It’s a classic, recurring problem that we see a lot in Windows where there’s a lot of legacy stuff to support, so you build a feature to facilitate that transition to run older software,” said Darren Kemp, security researcher at Duo Security. “But the side effect is that as the OSes are improving, yes you’re getting more and more security features, but they all maintain this specific compatibility layer and it’s in a path that created some interesting bypass scenarios for various security features like DEP and ASLR. We’re demonstrating that, but with an entirely different mechanism.”

Duo said it reached out to Microsoft with its research and exploit, which was acknowledged. The issue, however, would likely require significant re-architecting of Windows with regard to the support of 32-bit applications on 64-bit systems, which is unlikely.

“The subsystem results in some limitations, by design. And those limitations have a negative impact on security software,” Kemp said. “It’s simply a limitation of Windows. It’s not an inherent vulnerability, but it essentially makes the mitigation ineffective in essentially all cases of 32-bit software running on 64-bit version of Windows.”

Kemp and his colleague and senior security researcher Mikhail Davidov modified an existing exploit for a patched Adobe Flash use-after-free vulnerability (CVE-2015-0311) to get past EMET. They explain in a paper released today that 32-bit applications under WoW64 behave unlike they do in 32-bit systems; the processor’s ability to switch between execution modes at runtime opens up a number of exploit options for attackers.

From the paper:

“One of the most important limitations imposed by the WoW64 subsystem is that it makes it very difficult for security software to effectively hook low-level functionality from userland. Windows does not provide any ‘official’ mechanism for inserting 64-bit modules into 32-bit processes. A significant portion of the API functionality a piece of security software (i.e. EMET) would want to monitor is implemented in the 64-bit copy of ntdll.dll (process creation, module loading, etc.).”

They explain that an attacker would need to transition the processor to long mode, resolve the location of 64-bit modules and functions within them and overcome the limitations of available 64-bit APIs in order to avoid the function hooks used by security software. EMET hooks into ntdll.dll, a library that provides low-level functionality that applications use. Two copies of the library exist on both sides of this process, 32-bit and 64-bit, however, they researchers explain that on the 64-bit side none of the hooks are in place.

“All of those mitigations don’t exist there,” Kemp said. “We force the transition and then when everything executes, none of those hooks are present.”

EMET bypasses are not new. In the last 18 months, there have been a number of high-profile exploits, most of them from the white-hat realm, that have illuminated some shortcomings in the valuable Windows security feature. Black hats too have taken an interest in EMET; the Operation Snowman APT campaign, for example, contained a module that ran a check to determine whether EMET was running on the compromised host and then made a decision as to whether to execute the remainder of the attack.

“Because Microsoft is so focused on not breaking legacy technology—and from an enterprise point of view, that’s a good thing—it enabled these kinds of attacks,” Davidov said. “Even though most people are running a 64-bit version of the OS these days, you end up with a ton of 32-bit applications on the machine, which means you end up with the WoW64 subsystem on there as well, which enables EMET to be bypassed.”