Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
I don't think "airtight hatchway" applies here because what is to say the entry point isn't exploiting w3wp.exe remotely and executing code from the stack. Then let's say a memory page containing FREB code has permission PAGE_EXECUTE_READWRITE set (a plausible possibility for JIT compiling akin to eBPF), providing a convenient (and plausibly deniable) location for an extended amount of malicious code to be stored and executed from. Or w3wp.exe has permission to create a new memory page with PAGE_EXECUTE_READWRITE set and again this is plausibly deniable because FREB may need to do similar for JIT compiling. It it were almost any other process, a memory page set to PAGE_EXECUTE_READWRITE would sound alarm bells (or at least it should).
The second aspect is how well is w3wp.exe isolated? Can and does it use "AppContainer" isolation and is it strict? For example, could code executed by w3wp.exe create a new network socket, execute another process, write to a file in any path even though it shouldn't have a need to do so? Perhaps a different process sample123.exe is compromised, which by itself isn't too much of a problem due to its high degree of isolation. However, sample123.exe has permission to write to a pipe shared with w3wp.exe and can use this permission to exploit a bug in w3wp.exe (not exposed remotely) to allow code to execute with different/higher permissions of w3wp.exe, or using a plausibly deniable PAGE_EXECUTE_READWRITE memory page of w3wp.exe to store and execute code from without immediately sounding alarm bells.
_If_ strong process isolation was in place and working for w3wp.exe and/or sample123.exe, the "airtight hatchway" may not have been breached because whilst malicious code may have been executable from a stack, the malicious code wouldn't have been able to achieve much or anything of concern (can't read files from disk, can't access memory of other processes, can't login to a SQL database and start pulling data of other users, etc, etc).
I'm not sure what the equivalent of "systemd-analyze security" is for Windows, but it'd be well worthwhile for Windows system owners to demand similar easy-to-use tools for auditing the level of isolation of and required interfaces between applications (spoiler: just like a typical Linux system, the results will not be comforting, but seemingly with Windows you wouldn't know). Windows process isolation features introduced over the years are poorly documented, hard to use due to lack of tooling and often not used except for a few high profile applications such as Chromium and Adobe Acrobat. Chromium possibly has one of the best overviews of how sandboxing/process isolation can be achieved in Windows because they would have gone through a lot of pain in being amongst the first to figure it out[1].
[1] https://chromium.googlesource.com/chromium/src/+/HEAD/docs/d...