KASLR is broken anyway, at least on x86, even with KPTI (a Linux feature to mitigate Meltdown) enabled. See https://www.willsroot.io/2022/12/entrybleed.html, which still runs fine (with some modifications depending on the microarchitecture) on the latest AMD and Intel hardware that we've checked.
(Sorry for the self-plug but) I also wrote a bit about the behavior of PREFETCH recently in case anyone is interested in this sort of thing.
See this example (for Linux on AMD):
I can’t find any mention online of the `SystemTokenInformation` enum member outside of this article, even in this otherwise very comprehensive collection of documented and undocumented values: https://www.geoffchappell.com/studies/windows/km/ntoskrnl/ap...
Seems like SystemTokenInformation might be a very new addition, possibly even Windows 11 only?
I find myself thinking "wow, what an obvious bug. How did Microsoft not catch that?" but then I think back to some of my own extremely obvious bugs. Thankfully my code is much lower impact.
I still think of the lessons learned from a root traverse bug I accidentally coded into one of our internal apps as a jr dev.
You could change the URL of the image, and get any file off the system to download as long as the service account had read access.
Invaluable XP, and really glad everything was behind AD authentication and internal users were trustworthy enough and operating in a network isolated context.
Yeah, having learnt very similar (if not the same) lessons myself the hard way I see great value in being able to fail badly, but with low stakes. I catch loads of bugs like these from jrs before they hit prod but I don't feel like they're learning the fundamentals of security like trust, sanitising inputs, least privilege etc.
That would be an incorrectly configured http server. Not wordpress.
Things used to be distributed with .htaccess files, but only apache uses them and so that got offloaded on "blame the admin for not following documentation." Forgetting that nobody ever adds such to the docs.
I went to check when the bug had been patched, and was left wanting. I however lack the expertise to really appreciate how much danger exists in practice, or for whom. I just know I do have Win11 24H2 and "This leak primitive is particularly useful for Windows versions 24H2 or later"
The information leak in this bug is particularly useful for Windows 24H2 and later only because _prior_ to 24H2, there were immensely simpler methods that made the protection this bypasses (KASLR) completely useless anyway. And KASLR is still mostly useless due to the prefetch exploit linked elsewhere in the thread.
So, it's not that this bug is a _bigger_ problem on Win11 24H2, it's that there were so many _other_ problems prior to Win11 24H2 that nobody would bother with this bug in the first place. You have nothing to worry about from being on Win11 24H2 specifically when it comes to this bug.
And:
This is an information leak bug. No danger exists in practice for anyone from this bug alone. It erodes one very weak layer to a defense-in-depth strategy. It could have been used as part of a chain of exploits to provide the attacker with information (the kernel slide) that they needed, but it just provides a meaningless memory address on its own.
Wow thanks! I didn't even realize that was a link, it looks like just any other bold text in the page. It's weird this page would be published in Sept (if I understand correctly) and not mention the patch, but in any case that's good.
Specifically, it leaks a kernel address inside a security-sensitive structure, which is supposed to be unpredictable / unknowable because the layout of kernel memory is randomized.
If you have another exploit that will write bytes under the attacker’s control to an attacker-supplied kernel address, you will be able to do the Windows equivalent of escalate to root.
There was a large effort either right before or after Server 2003 to harden the Windows codebase as a whole.
Certainly it hasn't been 100% rewritten, that'd make no sense. But I'm not going to guess how much of it /has/ been rewritten because like you guessing, it'd be an uneducated one.
KASLR is broken anyway, at least on x86, even with KPTI (a Linux feature to mitigate Meltdown) enabled. See https://www.willsroot.io/2022/12/entrybleed.html, which still runs fine (with some modifications depending on the microarchitecture) on the latest AMD and Intel hardware that we've checked.
Yeah, there are so many ways to defeat KASLR. We need to treat the randomisation as a road bump, not a mitigation.
Serious red team reports will just have a brief section like "then, we defeat KASLR with [technique]. Next..."
In addition to the original EntryBleed article, https://exploits.forsale/24h2-nt-exploit/ and the corresponding https://github.com/exploits-forsale/prefetch-tool are useful for understanding the same exploit on Windows (which works the exact same way, of course).
(Sorry for the self-plug but) I also wrote a bit about the behavior of PREFETCH recently in case anyone is interested in this sort of thing. See this example (for Linux on AMD):
https://github.com/eigenform/perfect/blob/e5da0c693ba5d1b654...
.. and here's another example in the case of EntryBleed:
https://github.com/eigenform/perfect/blob/e5da0c693ba5d1b654...
I can’t find any mention online of the `SystemTokenInformation` enum member outside of this article, even in this otherwise very comprehensive collection of documented and undocumented values: https://www.geoffchappell.com/studies/windows/km/ntoskrnl/ap...
Seems like SystemTokenInformation might be a very new addition, possibly even Windows 11 only?
I'm pretty sure it's just a small mistake in the article on the exact syscall used to query the token information.
Checked a kernel from November 2024 vs a current one and from I can tell, this used to be the actual mechanism the exploit worked:
Sorry, the article was fixed with the right class and syscall names; somehow, it slipped past review.
I find myself thinking "wow, what an obvious bug. How did Microsoft not catch that?" but then I think back to some of my own extremely obvious bugs. Thankfully my code is much lower impact.
I still think of the lessons learned from a root traverse bug I accidentally coded into one of our internal apps as a jr dev.
You could change the URL of the image, and get any file off the system to download as long as the service account had read access.
Invaluable XP, and really glad everything was behind AD authentication and internal users were trustworthy enough and operating in a network isolated context.
Yeah, having learnt very similar (if not the same) lessons myself the hard way I see great value in being able to fail badly, but with low stakes. I catch loads of bugs like these from jrs before they hit prod but I don't feel like they're learning the fundamentals of security like trust, sanitising inputs, least privilege etc.
sounds like how wordpress used to be. could explore all the folders and get any file of site with something like website.com/content/2010/
That would be an incorrectly configured http server. Not wordpress.
Things used to be distributed with .htaccess files, but only apache uses them and so that got offloaded on "blame the admin for not following documentation." Forgetting that nobody ever adds such to the docs.
It’s interesting that the KB that patches this on Windows 11 (KB5063878) is the same one that was tied up in all the Phison SSD drama.
1) Those patches address a wide range of issues, from bug fixes to feature additions, to security fixes. This is uninteresting.
2) The issue had nothing to do with the patch. It was a coincidence.
It is interesting, that the bundling of updates has accidentally caused a problem.
a) People avoiding the update because one part causes problems
b) A security fix they probably need is only in that update
The update did not cause a problem with SSDs.
Whether or not it was real, it reinforces behaviour like [0].
And dealing with that, is a topic of conversation.
[0] https://news.ycombinator.com/item?id=45050665
I went to check when the bug had been patched, and was left wanting. I however lack the expertise to really appreciate how much danger exists in practice, or for whom. I just know I do have Win11 24H2 and "This leak primitive is particularly useful for Windows versions 24H2 or later"
The information leak in this bug is particularly useful for Windows 24H2 and later only because _prior_ to 24H2, there were immensely simpler methods that made the protection this bypasses (KASLR) completely useless anyway. And KASLR is still mostly useless due to the prefetch exploit linked elsewhere in the thread.
So, it's not that this bug is a _bigger_ problem on Win11 24H2, it's that there were so many _other_ problems prior to Win11 24H2 that nobody would bother with this bug in the first place. You have nothing to worry about from being on Win11 24H2 specifically when it comes to this bug.
And:
This is an information leak bug. No danger exists in practice for anyone from this bug alone. It erodes one very weak layer to a defense-in-depth strategy. It could have been used as part of a chain of exploits to provide the attacker with information (the kernel slide) that they needed, but it just provides a meaningless memory address on its own.
If you follow the CVE link included: https://msrc.microsoft.com/update-guide/vulnerability/CVE-20...
It would seem this was patched in the Aug 12 security patch rollout.
Wow thanks! I didn't even realize that was a link, it looks like just any other bold text in the page. It's weird this page would be published in Sept (if I understand correctly) and not mention the patch, but in any case that's good.
This type of exploit is useful as part of a chain of exploits; it defeats a defense-in-depth protection.
Specifically, it leaks a kernel address inside a security-sensitive structure, which is supposed to be unpredictable / unknowable because the layout of kernel memory is randomized.
If you have another exploit that will write bytes under the attacker’s control to an attacker-supplied kernel address, you will be able to do the Windows equivalent of escalate to root.
Random: Perhaps that full source code leak in 2004 actually helped harden the kernel, long term?
https://betanews.com/2004/02/13/windows-source-leak-traces-b...
KASLR was not present in Windows 2000, which is what this vulnerability breaks through.
That’s one vulnerability.
Lol yep.
I mean, it wasn't like the address space was all that large back then, anyhow.
Trolol?
How much of the core parts of the kernel do you think have been rewritten since?
There was a large effort either right before or after Server 2003 to harden the Windows codebase as a whole.
Certainly it hasn't been 100% rewritten, that'd make no sense. But I'm not going to guess how much of it /has/ been rewritten because like you guessing, it'd be an uneducated one.