Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NT OS Kernel Information Disclosure Vulnerability

crowdfense.com

Post reply on HN
Print view View original

31–37 of 37 posts

Re: NT OS Kernel Information Disclosure Vulnerability

#31

Post by musjleman »

dcrazy wrote: post #30

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:

  Thread #1 looping
    NtQueryInformationToken(TokenAccessInformation, InfoBuffer);
  
  Thread #2 looping
    Ptr = *(InfoBuffer + SidHashOffset);
    if (IsValidCanonicalKernelPtr(Ptr))
      done

Re: NT OS Kernel Information Disclosure Vulnerability

#32

Post by voidsec »

dcrazy wrote: post #30

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?

Sorry, the article was fixed with the right class and syscall names; somehow, it slipped past review.

Re: NT OS Kernel Information Disclosure Vulnerability

#33

Post by bjackman »

anematode wrote: post #20

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..."

Re: NT OS Kernel Information Disclosure Vulnerability

#34

Post by jcalvinowens »

anematode wrote: post #20

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.

It still has some benefit: there's randomization within the kernel, knowing the base isn't always enough.

Re: NT OS Kernel Information Disclosure Vulnerability

#35

Post by DaiPlusPlus »

privatelypublic wrote: post #22
lawlessone wrote: post #17

Earlier quoted context omitted.

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.

> That would be an incorrectly configured http server. Not wordpress.

Nah, it's WordPress, or more specifically: the sorry state of its community plugins.

Re: NT OS Kernel Information Disclosure Vulnerability

#36

Post by DaiPlusPlus »

lysace wrote: post #23
p_ing wrote: post #19

Earlier quoted context omitted.

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?

> How much of the core parts of the kernel do you think have been rewritten since?

Does refactoring count as rewriting, though?

I've poked-around the NT kernels for XP, XPx64, Vista, 7 SP1, and Win10 22H2[1] in Ghidra as part of a personal quest to find out why my Intel motherboard's XHCI (USB) controller drops random mouse HID packets, and even though the overall structure noticeably changes between releases after zooming-in I'll eventually find the same familiar blocks of code or patterns-of-blocks-of-code all referencing each other like before... just with even more new layers of indirection added in each Windows release.

A good example of this is to compare the disassembly for ntosknrl before - and after - Microsoft added Virtualization-based-security and "Virtual Trust Levels" to the kernel (I forget the exact version, but I think sometime in 2017?): prior to that, Windows' kernel-mode handling of its USER-component's hardware IO (mouse, keyboard, etc) was still fairly recognizable compared to even Windows XP; but post-VTL I saw how the "useful" program-code for processing local user input is wrapped in massive amounts of redirection back-and-forth through the hypervisor when VTL is enabled - it left me feeling like they moved a mountain just for this one single, Enterprise-y, feature while accepting the runtime overhead of all the extra branches and virtual-calls going on (which are trivial and of no consequence on modern hardware); so while I can't fault anyone at MS on the kernel team for their approach, it's a reminder that progress does not come cheap - or without compromises.

I wonder if Microsoft wrapped all the indirection gubbins in #ifdefs to elide it all from their gaming-edition build of Windows 11 for their Steamdeck compete ("ROG Xbox Ally") - I'd like to poke around that OS at some point to see (or maybe they've gone all-in on hypervisor-based security because that's how the Xbox now works?)

[1] Remember kids, keep your own backups of pdb symbols! Microsoft doesn't offer ISO downloads of PDBs to match your install media; now they're all download-on-demand with no guarantees of future availability of symbols for any binaries shipping today: it means debug symbols are now ephemeral and will be highly treasured by collectors in the distant future.

Re: NT OS Kernel Information Disclosure Vulnerability

#37

Post by lysace »

DaiPlusPlus wrote: post #36
lysace wrote: post #23

Earlier quoted context omitted.

Trolol? How much of the core parts of the kernel do you think have been rewritten since?

> How much of the core parts of the kernel do you think have been rewritten since? Does refactoring count as rewriting, though? I've poked-around the NT kernels for XP, XPx64, Vista, 7 SP1, and Win10 22H2[1] in Ghidra as part of a personal quest to find out why my Intel motherboard's XHCI (USB) controller drops random mouse HID packets, and even though the overall structure noticeably changes between releases after z…

> I'll eventually find the same familiar blocks of code or patterns-of-blocks-of-code all referencing each other like before... just with even more new layers of indirection added in each Windows release.

Thanks for the confirmation. Realistically this is to be expected for a codebase like this.

Post reply on HN