Windows 10, and even Windows 8.1 Update 3, uses Control Flow Guard (CFG) to protect against memory-corruption attacks. Close to the end of last year, Microsoft said the CFG security feature could "detect attempts to hijack your code" and stop executing the code "before the hijacker can do damage to your data or PC."
This summer at Black Hat, Yunhai Zhang showed how to "Bypass Control Flow Guard Comprehensively" (pdf). And at DerbyCon on Friday, Jared DeMott and Rafal Wojtczuk will present "Gadgets Zoo: Bypassing Control Flow Guard in Windows 10."
The abstract posted by DerbyCon states:
Modern memory corruption exploits gain arbitrary code execution by overwriting a function pointer with a controlled value and triggering a code path that dereferences it. Recent compilers attempt to prevent this by emitting additional checks before dereferencing code pointers, thus placing restrictions on the control flow graph. This makes exploitation more difficult. In VC++ 2015, Microsoft has implemented "Control Flow Guard" (CFG), which disallows certain indirect function calls. Windows 8.1 and 10 binaries are compiled with this option enabled, and contain the kernel extensions required to perform the extra checks. (LLVM/Clang offers control flow protection as well, but they are experimental and not currently used in real world apps for Mac or Linux at this point.) In this talk, we briefly describe known information on CFG implementation and weaknesses. The meat of our research is providing a generic CFG bypass. We have partnered with Microsoft to safely coordinate this release.
DeMott, a security researcher at Bromium Labs, told Threatpost that "Bromium disclosed the technique to Microsoft before Black Hat, but the company has decided not to fix it and that it was not worthy of a bounty." Microsoft, which has no comment at this time, said "the bypass doesn't affect all systems and that it would be a difficult attack vector to exploit."
DeMott added, "They said it really only affects 32-bit apps running on 64-bit machines, and that it doesn't affect all systems. My response to them was that IE runs as 32-bit by default on 64-bit Windows and this still fully affects the browser."
CFG is also part of Microsoft's Edge browser. Back in May, while announcing how Microsoft built Edge to be a "safer browser," the company explained:
The end-game in memory-corruption is for the attacker to gain control of the CPU program counter, and jump to a code location of the attacker's choice. CFG (Control Flow Guard) is a Microsoft Visual Studio technology that compiles checks around code that does indirect jumps based on a pointer, restricting these jumps to only jump to function entry points that have had their address taken. This makes attacker take-over of a program much more difficult by severely constraining where a memory corruption attack can jump to.
These new memory safety protections have been enabled and shipped out to Windows and IE users over the last year, and are on all the time in Microsoft Edge.
In March, when Core Security discussed bypassing CFG, the company added that CFG "is a promising mitigation technology that will increase the difficulty and the costs of writing exploits. As with every known exploitation mitigation, there are ways to bypass it if certain conditions are met."
Sure enough, as will be revealed at DerbyCon, CFG can be bypassed in Windows 10. Yet Microsoft isn't going to pay a bounty. Perhaps the average Jane Doe couldn't pull off DeMott's newest bypass, but nation-state hackers certainly could. Threatpost added that such an "attack provides a point of entry onto a network, opening the door to secondary attacks leading to data loss or privilege escalation."
"This is the next evolution of the typical cat-and-mouse game that is memory corruption," DeMott said. "All this research, even though it sounds bad, it's pushing [the] ball forward and raises [the] bar for attackers. [Microsoft] chose not to fix it and felt like they did the best they could with it and not fully repair it. There's some slight risk here and the technique we used doesn't exist everywhere."
Back in July, before Bromium Labs attended Microsoft's Worldwide Partner Conference, Bromium and Microsoft collaborated on a project to enhance Windows 10 security. So it doesn't seem like the two companies hate each other or anything like that, yet it seems like Microsoft might want to stop blowing off Jared DeMott; apparently DeMott excels at beating up Microsoft products.
Back in 2012, when DeMott was awarded third prize in Microsoft's BlueHat competition, Microsoft had planned to give DeMott an MSDN subscription valued at $10,000. After that prize met with some intense booing by the crowd, Microsoft added $10,000 to the MSDN subscription.
By 2014, Bromium's DeMott showed off attack code capable of bypassing "all of the protections" in Microsoft's free Enhanced Mitigation Experience Toolkit (EMET) 4.1. At that time, he got in a little kick at the Redmond giant, claiming, the return oriented programming (ROP) protections from the BlueHat $50,000 second prize winner, which "made it into EMET, do not stop ROP at all. The notion of checking at critical points is akin to treating the symptoms of a cold, rather than curing the cold. Perhaps one of the other prize submissions would have better addressed the problem of code reuse."
Even better was Bromium's accompanying whitepaper (pdf), which included the "custom LoadLibrary shellcode" message taunting Microsoft.
No bounty for Bromium this time, but I sincerely doubt it's the last time Microsoft will be hearing from DeMott.