CVE-2023-23420
NT Kernel (Registry), use-after-free in transacted key rename
Summary
| Field | Value |
|---|---|
| Driver | ntoskrnl.exe |
| Vulnerability Class | Use-After-Free |
| Exploited ITW | No |
| CVSS | 7.8 |
The Story
This is another finding from j00ru's landmark Project Zero registry audit, and it demonstrates a vulnerability class that is specific to transactional systems: state corruption during transaction commit or rollback. j00ru presented a working exploit at both BlueHat 2023 and OffensiveCon 2024, making this one of the most thoroughly demonstrated registry exploitation chains.
The bug also has an unusual distinction in terms of Microsoft's response: rather than attempting a targeted fix, Microsoft removed transacted key rename support entirely.
When Renames and Transactions Collide
The vulnerability sits in the kernel's handling of transacted registry key renames. When a key rename operation is performed inside a transaction, the kernel frees and reallocates key node cells in the hive. Under normal circumstances, this reallocation is handled correctly. But a specific sequence of transacted renames can leave a dangling pointer to a freed key node cell. The freed cell's memory is available for reuse, but the transaction's internal tracking still holds a reference to the old location.
When the transaction commits or rolls back, the kernel accesses the stale key node reference. If the freed cell has been reclaimed by a new allocation, the kernel reads attacker-controlled data from what it believes is a valid key node structure.
The vulnerability is reachable through standard registry APIs (RegRenameKey inside a transaction) without elevated privileges. The key insight is that transacted operations add a temporal dimension to registry operations: the kernel must maintain consistent state across multiple steps that can be interleaved with other operations, and this consistency maintenance is where the lifetime error occurs.
From Freed Cell to Kernel R/W
After the use-after-free on the key node cell, the attacker reclaims the freed memory with registry values of matching size. Operations on the stale key node reference now read the attacker's planted data, providing a kernel read/write primitive through the confused type interpretation. j00ru demonstrated the full chain from the transacted rename UAF through reclaim to SYSTEM escalation at both conferences.
Patch Analysis
Microsoft's response is noteworthy: rather than attempting a targeted fix for the specific rename sequence, they removed transacted key rename support entirely. The rename operation inside a registry transaction now returns an error, eliminating the vulnerable code path completely. This is the most decisive fix possible for a vulnerability, removing the feature that enables it, and it suggests Microsoft assessed the complexity of correctly implementing transacted renames to be higher than the value of supporting the feature.
Broader Significance
CVE-2023-23420 has two significant implications. First, it demonstrates that transactional subsystems (the registry, NTFS, the kernel transaction manager) are a rich source of use-after-free bugs because they must manage object lifetimes across commit/rollback boundaries, a fundamentally difficult problem. Second, Microsoft's decision to remove the feature rather than fix the bug signals that some kernel code paths are complex enough that correct patching is not cost-effective. For researchers, this suggests that other rarely-used transactional features in the Windows kernel may harbor similar lifetime errors.