Andy Burns wrote:

Lynn McGuire wrote:

there is an awesome new exploit that might pass them all

Does the does the exploit only work for instances of Windows running
under Hyper-V?

Just because the article mentions "virtual" has nothing to do with
virtual machines, like Hyper-V, VirtualBox, VMware Player, etc.

https://en.wikipedia.org/wiki/Virtual_memory
https://en.wikipedia.org/wiki/Virtual_address_space

The articles says their exploit involved shared code in memory, so it
isn't limited to just Windows but any OS that using paging, like Linux.
The hackers only created a POC for Windows. They just haven't bothered
testing and providing a POC for Linux which is also susceptible.

DLLs (dynamic linked libraries) are one way to share code: any program
can call the same function (method) within the memory-loaded DLL. Under
Linux, they're just called libraries (although DLL is a generic comptuer
term, not just for Windows) and usually have an .so postfix (for Shared
Object). SO is part of ELF (Executable and Linking Format). SOs can be
versioned which eliminated the DLL Hell experienced in Windows. A
Sindows program can statically link (include) a DLL in its code: the
program carries along its own copy of the library to load in its memory
space but that means the program is larger from toting around what could
otherwised be shared. Other DLL Hell mitigations (only in Windows) are
noted at https://en.wikipedia.org/wiki/DLL_Hell#Solutions.

DLL injection is how to get your code into a library before it gets
loaded into memory and then reused by multiple processes. Injected code
can then hook into system API calls; e.g., reading the contents of
encrypted password objects (textboxes that normally don't show the
entered content) that cannot be performed by simply grabbing the
object's value. Once the code gets injected into the DLL, and after the
DLL gets loaded into memory, whatever the code changed or added will
effect all processes calling the same methods in that loaded DLL.

Letting processes share the same code reduces their memory footprint
rather than have every process tote along the same code. Ever notice
all the C runtimes that come with Windows? That's to share that code,
too, rather than bloat every program. The shared code must get loaded
into memory (nothing runs unless in memory - stuff pushed into pages on
the disk aren't running until reloaded into memory). Apparently the
loaded tables with shared coded aren't safeguarded from being rewritten.
Many DLLs are loaded simply by loading Windows; that is, starting
Windows will load many DLLs.

You can use Nirsoft's LoadedDLLsView to see which DLLs are currently
loaded. As I wrote this and then ran LoadedDLLsView, there are 1153
DLLs currently loaded into system RAM. For example, I'm posting here
using 40Tude Dialog (dialog.exe) which loaded the 4dmf.dll library.
However, I doubt any other process would share Dialog's library but some
programmers keep separate their functions in libraries for easier
maintenance of their code. Instead of having to delve into one large
code file, they know by function where to find some code they want to
change, so they keep those functions in libraries (DLLs) and have their
executable load the libs so those functions will be available to the
executable. In the list of loaded DLLs, a count shows how many
processes have links to one, or more, methods within that loaded DLL.
ntdll.dll (for NT kernel functions) has 87 processes currently accessing
methods in that OS DLL, including my Usenet client (Dialog).

Perhaps the reason Lynn mentioned "maybe she should be running Windows
10" is that mitigations might have been implemented in Win10 Redstone 3,
and up, regarding this corruption of shared memory. The table in the
article could be interpreted to identify under which versions of Windows
the author's POC will fail ("X" meaning fail). Since there is no
comment remarking what the table represents or even a title for the
table, I'm not sure what that table is supposed to represent. Do the
X's represent mitigations that were added but the POC circumvented them?
Are the X's simply to list which mitigations were added in each version
of Windows (and not to show which ones were obviated by the POC)? With
no information about what the table represents, there's nothing in the
article that overtly declares any release of Windows 10 is better
protected than earlier versions of Windows regarding the authors' POC.
In the video (https://www.youtube.com/watch?v=QmgbbSPj2j4) at 8:58:20,
although sometimes hard to discern what the speaker says, I think the
speaker said their shared table exploit POC obviates *all* of the
mitigations, even those in the latest of Windows 10. I don't see the
authors claiming Windows 10 Redstone 3+ is protected against their POC.