Bug in todo rescheduling in supR3HardenedWinVerifyCacheProcessWvtTodos() - fixed in SVN

[Captain Crunch]

Look at the source code here:

https://www.215389.xyz/svn/vbox/trunk/src/VBox/HostDrivers/Support/win/SUPR3HardenedMain-win.cpp

in the function supR3HardenedWinVerifyCacheProcessWvtTodos(), I'm thinking the handling of the linked list for rescheduling is botched.

For example, I see pReschedule initialized to NULL, but I don't see anywhere else in that method where it's assigned. Then near the end of the method, its value is checked, which would seem to be pointless since it's always going to be NULL.

For context, see https://www.215389.xyz/ticket/13659

[bird]

Thanks for the report! The code looks like it couldn't make up its mind which way to approach the rescheduling list, and ended up with non-working code. I've committed a fix which should appear in the public SVN before long, test builds tagged r134806 or later will also include it.

[Captain Crunch]

hardening log (VB 6.0.15)

[Captain Crunch]

I tested with the dev release of VirtualBox, 6.0.15, and the specific issue reported is fixed - that the winVerifyTrust call wasn't rescheduled. However, the original problem remains that the injected DLL doesn't seem to be working.

What I notice is that, with no certificate, the DLL doesn't get loaded into VirtualBoxVM.exe at all, as checked by Process Explorer. Once I add the self-signed certificate, then the DLL appears in the process of VirtualBoxVM.exe in Process Explorer, but it still doesn't work.

The interesting piece of evidence is that, this was true before you fixed this bug as well. Even without the reschedule winVerifyTrust call getting made, the DLL got loaded into memory. With your fix, nothing seems to have changed beyond what it was doing before. It still gets loaded into memory but doesn't work. So, my hypothesis is that there's an additional step, after loading, that must be executed to get the injected DLL working. I would guess it's one or more of:

• The DLL initialization routine being called (not too familiar with Windows DLL)
• The DLL's context perhaps isn't being installed
• Some authorization/permissions aren't being set to allow the DLL to access the APIs or memory addresses it needs to run properly

It stands to reason that, with your fix in place, some additional code is running, and I see that it reports fWinVerifyTrust=1 in the log for this DLL. But, the key question is, what happens internally as a result of this to "approve" the DLL? I.e., since it's already loaded, the answer is not "load it." So, what exactly happens when fWinVerifyTrust reports success to allow the DLL to run??? ... because I think that's not happening.

(Note that I've followed up in this ticket rather than the original because I believe the "missing steps" to fully enable/initialize the DLL should be run as a result of the fix you added for this ticket.)

[Captain Crunch]

So when is this getting fixed? What logging do I have to provide to get it fixed?

As I reported, from the hardening logs, we see that after the latest change winVerifyTrust returns 1 indicating it passed verification, but the DLL is never initialized and still doesn't work.

I would ask this specific question to the developers - what should happen once verification passes as reported in the hardening log? Something right? I didn't notice any change in behavior with this fix in place, other than VirtualBox now reporting that it passes verification. You need to call the DLL entry point, right? Looks like that's not happening.

I really don't want to have to debug this myself as I'm not familiar with the code at all so it would take me forever to track down the problem - you a few minutes probably.