Spurious #DB exceptions with the "MOV SS" and "POP SS" instructions (CVE-2018-8897)

A statement in the System Programming Guide of the Intel 64 and IA-32 Architectures Software Developer's Manual (SDM) was mishandled in the development of some or all operating-system kernels, resulting in unexpected behavior for #DB exceptions that are deferred by MOV SS or POP SS , as demonstrated by (for example) privilege escalation in Windows, macOS, some Xen configurations, or FreeBSD, or a Linux kernel crash. The MOV SS and POP SS instructions inhibit interrupts (including NMIs), data breakpoints, and single step trap exceptions until the instruction boundary following the next instruction (SDM Vol. 3A; section 6.8.3). Note that debug exceptions are not inhibited by the interrupt enable ( EFLAGS.IF ) system flag (SDM Vol. 3A; section 2.3). If the instruction following the MOV SS or POP SS instruction is an instruction like SYSCALL , SYSENTER , INT 3 , etc. that transfers control to the operating system at CPL < 3, the debug exception is delivered after the transfe

Enumerating process, thread, and image load notification callback routines in Windows

Most people are familiar with the fact that Windows contains a wide variety of kernel-mode callback routines that driver developers can opt into to receive various event notifications. This blog post will explain exactly how some of these function under the hood. In particular, we'll investigate how the process creation and termination callbacks ( nt!PsSetCreateProcessNotifyRoutine , nt!PsSetCreateProcessNotifyRoutineEx , and nt!PsSetCreateProcessNotifyRoutineEx2 ), thread creation and termination callbacks ( nt!PsSetCreateThreadNotifyRoutine and nt!PsSetCreateThreadNotifyRoutineEx ), and image load notification callbacks ( nt!PsSetLoadImageNotifyRoutine ) work internally. Furthermore, we'll release a handy WinDbg script that will let you enumerate these different types of callbacks.

Detecting debuggers by abusing a bad assumption within Windows

This blog post will go over an assumption made over a decade ago by Microsoft when dealing with software breakpoints that can be used to reveal the presence of most (all publicly available?) usermode and kernelmode debuggers.

Exploring Windows virtual memory management

In a previous post , we discussed the IA-32e 64-bit paging structures, and how they can be used to turn virtual addresses into physical addresses. They're a simple but elegant way to manage virtual address mappings as well as page permissions with varying granularity of page sizes. All of which is provided by the architecture. But as one might expect, once you add an operating system like Windows into the mix, things get a little more interesting. The problem of per-process memory In Windows, a process is nothing more than a simple container of threads and metadata that represents a user-mode application. It has its own memory so that it can manage the different pieces of data and code that make the process do something useful. Let's consider, then, two processes that both try to read and write from the memory located at the virtual address 0x00000000`11223344 . Based on what we know about paging, we expect that the virtual address is going to end up translating into the

Breaking backwards compatibility: a 5 year old bug deep within Windows

Microsoft has a great track record of maintaining support for legacy software running under Windows. There is an entire compatibility layer baked into the OS that is dedicated to fixing issues with decades old software running on modern iterations of Windows. To learn more about this application compatibility infrastructure, I'd recommend swinging over to Alex Ionescu's blog . He has a great set of posts describing the technical details on how user (even kernel ) mode shimming is implemented. With all of that said, it's an understatement to say that Microsoft takes backwards compatibility seriously. Occasionally, the humans at Microsoft make mistakes. Usually, though, they're very quick to address these problems. This blog post will go over an unnoticed bug that was introduced in Windows 8 with a documented Win32 API. At the time of this post, this bug is still present in Windows 10 (Creator's Update) and has been around for over 5 years. Forgotten Win32 AP