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