eXtended Flow Guard Under The Microscope

Microsoft seems to be continuously expanding and evolving its set of security mitigations designed and implemented for Windows 10. In this blog post, we’ll examine an upcoming security feature called eXtended Flow Guard (XFG).

XFG has not yet been released, and will not be part of the upcoming 21H1 version of Windows 10. It is, however, present in the Dev Channel of the insider preview¹. At this time, the only public mention of XFG by Microsoft was in 2019 at Bluehat Shanghai².

Although XFG has not been released yet, it is nevertheless possible to compile applications with XFG using Visual Studio 2019 Preview while targeting the insider preview version of Windows 10. A few blog posts on how XFG works have been released³, but these mainly consider how XFG can be compiled into a custom application rather than examining common exploitation scenarios in depth.

The aim of this blog post is to cast more light on whether XFG is truly a more secure and hardened version of Control Flow Guard (CFG). We’ll get started with a short recap on how both CFG and XFG work.

Setting The Baseline

CFG was introduced with Windows 10 in 2015 and has undergone several modifications to mitigate vulnerabilities in its implementation. In essence, CFG is a coarse grained Control Flow Integrity (CFI) solution that maintains a bitmap corresponding to every function and when invoked determines if the function in question is a valid call target.

Microsoft has publicly acknowledged that one of the shortcomings of CFG is return address overwrites. This issue will be addressed by Intel CET and the Shadow Stack. XFG has a very similar design to CFG, and thus must also rely on Shadow Stack to protect against return address overwrites.

Since we’re focusing on XFG and not separate security mitigations such as Intel CET and the Shadow Stack, we’ll explore vtable overwrites with valid call targets.

When creating a browser exploit, a common method for obtaining control of the instruction pointer is to overwrite an entry in the objects vtable and invoke the associated method. CFG was actually introduced to mitigate this exact type of exploitation scenario.

Since CFG is a coarse grained CFI solution, a vtable entry can be replaced with a different function pointer, as long as its a valid call target. This means CFG does not consider the call site, only the call target.

To understand this a little better, let’s examine the API NtCreateFile in ntdll.dll and how that is examined by CFG. A CFG check is performed by the function LdrpDispatchUserCallTargetESS, which expects to find the address of NtCreateFile in the RAX register.

To simulate this, we can modify RAX and RIP in WinDBG and step through the first part of LdrpDispatchUserCallTargetESS:

Listing – CFG locating bitmap value

LdrpDispatchUserCallTargetESS uses the function address in RAX as an index into the CFG bitmap and fetches back a 64-bit value.

Next, a bit test is performed to check if the supplied function address is a valid call target. This is done by using the function address again as an index:

Listing – Validating the call target

In this case, we found that NtCreateFile is a valid call target, and LdrpDispatchUserCallTargetES dispatches execution to it through a JMP instruction.

We can sometimes leverage this when developing exploits by overwriting the vtable pointer with the address of a function that is a valid call target. For this to work properly, we would also need to be able to control the arguments for the function, which is out of scope of this blog post.

In summary, CFG is said to be “coarse grained” because it only takes the call target into account, not the call site. This makes it more susceptible to bypasses.

Understanding The Hash

With XFG, Microsoft is attempting to develop and implement a more fine grained CFI solution, according to the talk at Bluehat Shanghai. XFG is meant to take into account both the call target and the call site.

The general concept is that before each use of XFG, the compiler will generate a 55-bit hash based on the function name, number of arguments, the type of arguments, and the return type. This hash will be embedded in the code just prior to the call into XFG.

Below is a code snippet taken from Chakra.dll which makes use of XFG in the insider preview.

Listing – Hash is placed into R10

Just as with CFG, the function address used for the call target is placed in RAX.

The XFG function is called LdrpDispatchUserCallTargetXFG, and we can similarly demonstrate how it works by manually setting RIP to LdrpDispatchUserCallTargetXFG and RAX to NtCreateFile.

Listing – Call site is verified

In the last instruction shown above, the hash in R10 is compared to the value 8 bytes prior to the call target. The compiler will insert the generated hash just prior to each function.

Since the call target will move the hash value into R10 prior to invoking LdrpDispatchUserCallTargetXFG, the two values should match in order to allow execution. If the comparison is successful, execution is dispatched through a JMP instruction.

This use of compile time hashes is much harder to bypass than the coarse grained approach of CFG. Overwriting a vtable with a different function pointer seems nearly impossible as a hash collision is very unlikely, given the use of 55-bits in the hash generation.

Falling Back

At this point, it seems as though XFG has successfully managed to mitigate any attempts at meaningful vtable overwrites and is much more secure than CFG. However, we still need to investigate what happens when the hash comparison fails.

If execution is not dispatched to the call target, the code segment shown below is executed:

Listing – Fetching a bitmap value

We notice that the call target function address is moved into R11 and used as an index into the CFG bitmap. The very same 64-bit CFG bitmap value is moved into R11 at the end of the code segment.

This seems confusing at first, but if we continue execution, we’ll also find the code shown below:

Listing – Dispatching execution based on the bitmap

The call target address is yet again used as an index to check the bitmap value through a bit test. At this point, we should observe that the code is almost identical to that of CFG.

After the bit test, we once again find that NtCreateFile is a valid call target and execution is dispatched to it. This happens even though we did not supply any hash, and the initial hash comparison failed.

In effect, XFG falls back to using CFG when the correct hash is not provided. From the example shown with NtCreateFile, its clear that XFG does not block us from overwriting a vtable with a CFG-valid call target.

Conclusions

At face value XFG, appears to be a much more fine grained CFI solution that CFG and should mitigate most exploitation techniques that attempt to overwrite a vtable.

However, in XFG’s implementation, Microsoft has essentially built-in a security downgrade for cases when hash-based comparison fails. This downgrade means that XFG is not any more secure than CFG, and will be susceptible to the same attacks.

It should be noted that XFG is only available in the insider preview, and may thus undergo changes before a release. At the time of this writing, it has had its current implementation for over six months.

Interested in delving into vulnerability research, exploit development, reverse engineering, and operating system internals?  Explore the following Learning Paths and courses: Exploit Development Essentials, EXP-301, EXP-312, and EXP-401.

About the Author

Morten Schenk is content developer and trainer at Offensive Security with a focus on exploit development and mitigation bypasses on Windows. Morten loves to build exploits against difficult targets and continuously discover new techniques to combat mitigations.