From 8487e4ef0807830f2f4659fd9283b1300bfac921 Mon Sep 17 00:00:00 2001 From: doomy Date: Fri, 26 Apr 2024 02:20:03 -0400 Subject: [PATCH] unpaid labor --- content/24h2-nt-exploit/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/24h2-nt-exploit/index.md b/content/24h2-nt-exploit/index.md index eeb86e2..3ef86fb 100644 --- a/content/24h2-nt-exploit/index.md +++ b/content/24h2-nt-exploit/index.md @@ -139,7 +139,7 @@ _Our exploit is complete :)_ As I mentioned at the start, and would like to emphasize again, without having access to the source code and compiler it’s basically impossible to know exactly what led to the two bugs described here being introduced. As a security researcher, these kinds of bugs appearing from nowhere are a nice surprise, but for the vendor I believe these can highlight the risk of applying seemingly inconsequential changes to existing code. -## KASLR: A Long Way to Go +### KASLR: A Long Way to Go KASLR was trivial on Windows for so long that any change is going to be an improvement. Microsoft’s attitude toward KASLR also suggests that they don’t regard it as a meaningful mitigation, given that they [neither service nor award bounty for KASLR bypasses](https://www.microsoft.com/en-us/msrc/windows-security-servicing-criteria). The decision to disable KVA shadowing in Windows 11 also weakens the isolation of kernel memory from user mode. While the elimination of many classic KASLR leaks will certainly create a little extra work for exploit developers I don’t believe it poses a real challenge. I’m sure in the future we’ll see more KASLR bypasses as well that don’t require any side-channel trickery ;)