Information
- Language: English
- Conference: Microsoft BlueHat
- Location: Redmond, USA
- Date: October 2023
- Speaker(s): Mateusz ‘j00ru’ Jurczyk
Slides
Video
Abstract
The registry is one of the oldest subsystems still present in the Windows kernel, dating back to Windows 95 / Windows NT 3.1 and around 30 years old. Despite its long history, it is alive and well today as it continues to serve as the main configuration storage for both the system and third party applications, and even gets regular updates to meet the ever-changing requirements of modern OS-es (such as containerization support). From a security perspective, the code’s versatility and kernel privileges make it a prime target for memory corruption and local privilege escalation attacks. Indeed, as of early 2022, the registry already did have an existing track record of security issues, but the extent of it didn’t seem proportional to how complex – and frankly, fascinating – the inner workings of the registry seemed to be. Seeing this, I set out to better understand the mechanics of the codebase and maybe discover a bug or two along the way. Fast forward to 2023, and this seemingly simple exercise turned into a multi-month effort that has yielded over 35 CVEs so far, ranging from classical memory corruption issues to particularly registry-specific bug patterns.
In this talk, I will discuss my approach to reverse-engineering and systematically auditing the configuration manager, give an overview of both the fundamentals and more advanced features of the registry, and present some of the most entertaining bugs and quirks found in the process. Mechanisms like predefined keys, registry virtualization, lightweight transactions or layered keys come from different eras and have very little to do with each other, but interesting things start to happen when you make them interact. For example, what happens when you:
- open a registry key,
- which is subject to registry virtualization and transparently redirected to a different key,
- which turns out to be a symbolic link that points to yet another registry path,
- all of the above in the scope of a transaction,
- while another thread is trying to delete that same key,
- while it has other differencing hives overlaid on top of it?
These are the types of questions I will try to answer in this presentation, concluded by a demonstration of how to successfully turn registry bugs into reliable kernel exploits.