Bob and Alice in Kernel-land - Part 3

· 842 words · 4 minute read

BSOD

This is the last part of a 3-part series on Bob and Alice in Kernel-land. You can find Part 1 here and Part 2 here.

CrowdStrike podcast “Adversary Universe Podcast” just released a new episode entitled “The Kernel’s Essential Role in Cybersecurity Defense” featuring Adam Myers w/ Alex Ionescu, who is the original architect of the CrowdStrike Falcon kernel agent and also known for being the co-author of “Windows Internals” book and to be among the most knowledgeable people when it comes to understanding how the Windows (or any other OS tbh) kernel works.

This blogpost is a summary of the episode and my thoughts about it, as well as a look into the future of kernel-level security. Alex makes some very interesting points, some of which I had already touched upon in my previous write-ups, such as the increased complexity of the kernel and the challenges it presents for defenders. I’ll share my notes and thoughts below, as I really think this episode will age very well over the next 10 years or so.

Here are the main points discussed in the podcast episode with Alex Ionescu:

  1. The Windows Kernel
  • Described as the “brain” of the operating system, controlling everything on the computer
  • Has full access to hardware, CPU, and all running processes
  • If anything goes wrong with the kernel, the whole computer crashes
  • Windows kernel is relatively small (10 MB file) compared to modern applications
  • Windows has a very rich and open ecosystem for hardware and software compatibility
  1. Windows Driver Ecosystem
  • Over a million unique Windows drivers are built every month. This really makes the figure I shared in Part 2 that focused on mini filters of this series look small.
  • Huge variety of third-party drivers all using the same interfaces
  • Windows uses a monolithic kernel where all drivers operate in the same “sandbox”
  • If one driver malfunctions, it can affect the entire system
  • Microsoft has built safeguards like kernel patch protection and code signing requirements
  1. Kernel Security Measures
  • Windows was first OS to introduce strong kernel safeguards (starting with Windows XP 64-bit)
  • Kernel patch protection (PatchGuard) introduced to prevent unauthorized modifications
  • Kernel mode code signing enforced since Windows Vista
  • Windows 11 uses a hypervisor to provide additional protection even against the kernel itself
  • Other protections include kernel shadow stacks and various mitigation technologies
  1. Bring Your Own Vulnerable Driver (BYOVD) Attacks
  • Major threat to kernel security model
  • Attackers can exploit vulnerabilities in third-party drivers to gain unauthorized kernel access
  • Microsoft maintains a Known Vulnerable Driver blocklist, but it’s a constant cat-and-mouse game
  • Unknown vulnerable drivers can be exploited by attackers before they’re discovered and blocked by Microsoft’s blocklist.
  1. Comparison to Other Operating Systems
  • Linux and macOS kernels are larger in file size but include more built-in functionality
  • Windows separates many components into individual driver files (ntfs, netio, etc.) for easier servicing
  • Linux uses a modular approach but still operates as a monolithic kernel in practice
  • True microkernels are mainly used in real-time operating systems and specialized environments
  1. Four Pillars of Kernel-based Security Products introduced by Alex Ionescu at the Microsoft Endpoint Security Summit.
  • Visibility and Telemetry: Some data can only be collected from kernel level
  • Enforcement: Inline blocking of malicious activities requires kernel access
  • Tamper Prevention: Protecting security product from manipulation needs kernel-level control
  • Performance: Processing security decisions in the kernel is more efficient than user space
  1. Challenges with Linux Kernel Security
  • Linux Security Modules (LSMs) are powerful but designed to be statically compiled
  • Many variations of Linux kernels make it difficult to maintain compatibility
  • eBPF allows some kernel-level functionality from user space but with limitations
  1. Microsoft Security Summit
  • Brought together security vendors, government observers, and Microsoft leadership
  • Focus on collaboration against common adversaries despite market competition
  • Discussed potential changes to Windows kernel ecosystem and security product development
  • Emphasis on maintaining Windows' open platform while improving security
  1. Legacy Windows Systems
  • Many organizations still rely on older Windows versions (7, XP)
  • Advice includes implementing better deployment practices and security policies
  • Best Effort approach.
  1. Rust in Kernel Development
  • Possible to compile Rust code for kernel use across different operating systems
  • Lacks mature ecosystem of libraries (crates) for Windows kernel development. (WIP)
  • Microsoft working on basic support, but not yet ready for production use
  • Potential for improved safety and performance in kernel code

Closing thoughts 🔗

The episode is a great summary of the current state of kernel-level security and the challenges that defenders face. It also highlights the importance of collaboration between vendors, Microsoft and the broader security community to address these challenges.

The variety of operating systems and kernels also explains why kernel-level forensics such as memory analysis is challenging due to the need to maintain different versions. Even when using Microsoft crash dumps formats which would default to debugging symbols.

It’s interesting to see that even with all the work Microsoft has done in the area, there is still much work to be done and new areas to explore.

Looking forward to see what new security products will emerge from this collaboration and what new areas of research will be pursued.

bug kernel