Skip to main content

SWAPGS Attack: A Spectre Variant


With the recent developments of Spectre [1] and Meltdown [1] as we discussed in class, it should come to no surprise that various odd methods of accessing kernel memory through user level permissions have popped up.  One such interesting method utilizes the SWAPGS instruction, called the SWAPGS Attack, found by Bitdefender researchers just a few months ago [2].  This article will explore what the attack is, how to exploit it on existing hardware and operating systems, and what mitigations can be implemented for current hardware.

SWAPGS Attack Overview

The SWAPGS Attack, as the name implies, utilizes the SWAPGS instruction.  This instruction swaps two Model Specific Registers (MSRs), IA32_GS_BASE and IA32_GS_KERNEL_BASE, which point to the user mode's per-thread data structure and kernel mode per-thread data structure respectively.  In Windows, the addresses stored in these registers are used to quickly access information about the current Thread Information Block (TIB), a data structure which stores things such as the thread ID, stack base address, and stack size limit.

The introduction of the GS register as part of the Intel 8086 processor was to give programs access to 1MB of memory, rather than 64KB using what is called Segmentation.  Segmentation essentially splits the memory up into 16 byte chunks, and a segment offset can be converted into a linear memory address.  This feature is completely unused in modern operating systems in favor of newer page table methods.  The GS register is now used for pointing to the start location of the TIB in Windows and an a similar structure on Linux systems.

The SWAPGS instruction was added with the x86-64 architecture extension, and is intended to maintain compatibility between the newer ISA while older Segmentation instructions were retired.  One important item to note with SWAPGS is that the instruction can only be called in kernel mode, and is only ever intended to be used by the operating system.

A basic overview of an attack that will be explored in the next section involves how the SWAPGS instruction can be speculated on.  That is, there are certain pieces of kernel code that can speculatively run a SWAPGS instruction with user defined addresses, which can load kernel memory into cache.  This is effectively leaking information about what is and is not in kernel memory, just as earlier variants of Spectre.

Exploiting SWAPGS

To do this, the researchers at Bitdefender first found gadgets (Return Oriented Programming gadgets) that exist inside the Windows NT Kernel.  One such gadget they explored exists in the exception handler of the TIB listed below:



The intended usage of this code was unclear to the researchers, as it was never reached in any testing.  However, as a ROP gadget it is extremely useful, since the SWAPGS instruction can be speculated on, and no later instruction will serialize the execution.  This will allow us to later to speculate that SWAPGS should run, when in fact it should not.

Next, the attacker needs to allocate a value V, which will be our attacking value we are testing its existence in kernel memory for.  Then, before reaching the SWAPGS, we must modify the current IA32_GS_BASE to be the address K, which is the address in kernel memory we want to examine.  We then train our branch predictor to speculatively execute SWAPGS using known methods, details of which are not the focus of this article.  Next, we create a page fault to transition from user to kernel mode, which will subsequently load the value Q from address K (line 6).  Finally, once control has returned back to the user mode, we can check if the address of V is in cache, and if so, we know that V was in the kernel address space.

Mitigations

Since SWAPGS can execute speculatively, one simple way operating system developers can prevent this attack from occurring is to force serialization of SWAPGS instructions.  This would only require a memory fence (such as LFENCE) to prevent SWAPGS from speculatively executing on attacker addresses.

Another option presented is modifying the IA32_GS_BASE to a known value before calling SWAPGS.  This would prevent an attacker from setting their own GS base value for later examination, but would be difficult for operating system developers to implement due to the number of various situations that must be handled.

Yet another software approach they describe utilizes  Supervisory Mode Access Prevention (SMAP).  Essentially, SMAP prevents kernel mode from accessing user mode memory.  This would prevent a user mode address input to GS_BASE from being used in kernel mode.

Finally, the best solution would require a hardware change, which is disallowing speculative execution on SWAPGS.  This is the only sure way to prevent attacks of this sort on future applications, but could take a long time to implement and become prevalent enough.

Thankfully, the researchers also report that Microsoft has patched known speculative SWAPGS calls, so the impact of this attack should be greatly minimized.

Conclusion

We first explored what the SWAPGS instruction is and detailed its use cases as well as its origin in computing.  We then examined a real world gadget in the Windows NT Kernel exception handler and showed how one could potentially leak information about the kernel memory to the user space.  Finally, we described some mitigations that could be implemented to thwart an attack of this kind.

In my opinion, this bug is extremely interesting especially when looking at the history of why the GS register and related instructions even exist in the first place.  It is understood that the GS register was originally developed to extend an application's addressable memory, but I do find it odd that a more sophisticated setup for thread information has not been implemented.  Moreso, it is quite interesting to me that the GS register is essentially used as a quick access pointer rather than its original purpose now.  In any case, the bug exists because of both speculative execution and the original need for extending application memory in the late 70s.

References

[1] https://meltdownattack.com/
[2] https://www.bitdefender.com/business/swapgs-attack.html

Comments

Post a Comment

Popular posts from this blog

Angr: A Multi-Architecture Binary Analysis Toolkit

This blog is quoted from several angr blogs and documentations, click  here  and  here . angr is a multi-architecture binary analysis toolkit, with the capability to perform dynamic symbolic execution (like Mayhem, KLEE, etc.) and various static analyses on binaries. We've tried to make using angr as pain-free as possible - our goal is to create a user-friendly binary analysis suite, allowing a user to simply start up iPython and easily perform intensive binary analyses with a couple of commands. That being said, binary analysis is complex, which makes angr complex. This documentation is an attempt to help out with that, providing narrative explanation and exploration of angr and its design. Several challenges must be overcome to programmatically analyze a binary. They are, roughly: Loading a binary into the analysis program. Translating a binary into an intermediate representation (IR). Performing the actual analysis. This could be: A partial or full-prog...
Post a Comment
Read more

Introduction to Meltdown and Escaping the Chrome Sandbox

R untime isolation and sandboxed environments are central to modern application security, but the most commonly used ones may not be as secure as we hope. Overview The general idea of isolated or sandboxed environments is to give a program a limited scope in which to operate. Instead of allowing a given program to use any of a machine’s resources, physical or virtual, you restrict its environment such that it can only access aspects of the system that the sandbox designer has decided are available for use by the program. This is not unlike putting your child in a literal sandbox with high walls – they are free to do whatever they want with all the sand, toys, and tools inside, but cannot interact with the environment outside. Isolation principles are in play at pretty much every aspect of modern computing. For example, last week a classmate wrote a blog on WannaCry, an exploit in Windows SMB older and unpatched versions of Windows. Without going into the detail...
Post a Comment
Read more

Information Side Channel

By Elaine Cole and Jarek Millburg An information side channel can be used to gain information about the system or data that it processes. A side-channel attack identifies a physical or micro-architectural signal that leaks such desired information and monitors and analyzes that signal as the system operates. While there are many different types of information side channels and even more ways to maliciously exploit them, this blog explores a recent publication that leverages information side channels within IoT devices to aid crime scene investigators in real-time. In this blog, we provide an overview of the general attack procedure, and explore two of the many forms of side channel attacks. Side Channel Attack General Procedure While there are many different forms of side channels, at a high level, a side channel attack requires the following: 1. identify a side channel:  The attacker must first identify  a physical or micro-architectural signal that leaks...
Post a Comment
Read more