VirtualBox

Ticket #19060 (closed defect: fixed)

Opened 17 months ago

Last modified 14 months ago

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

Reported by: Captain Crunch Owned by:
Component: other Version: VirtualBox 6.0.14
Keywords: hardening Cc:
Guest type: all Host type: Windows

Description

Look at the source code here:

https://www.virtualbox.org/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.virtualbox.org/ticket/13659

Attachments

resecheduled-not.log Download (1.1 KB) - added by Captain Crunch 17 months ago.
6.0.15-hardening-wl_hook64.dll.log Download (16.0 KB) - added by Captain Crunch 16 months ago.
hardening log (VB 6.0.15)

Change History

Changed 17 months ago by Captain Crunch

comment:1 Changed 17 months ago by janitor

  • Summary changed from Bug in todo rescheduling in upR3HardenedWinVerifyCacheProcessWvtTodos() to Bug in todo rescheduling in supR3HardenedWinVerifyCacheProcessWvtTodos()

comment:2 Changed 17 months ago by bird

  • Status changed from new to closed
  • Resolution set to fixed
  • Summary changed from Bug in todo rescheduling in supR3HardenedWinVerifyCacheProcessWvtTodos() to Bug in todo rescheduling in supR3HardenedWinVerifyCacheProcessWvtTodos() - fixed in SVN

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.

Changed 16 months ago by Captain Crunch

hardening log (VB 6.0.15)

comment:3 Changed 16 months ago by 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.)

Last edited 16 months ago by Captain Crunch (previous) (diff)

comment:4 Changed 14 months ago by 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.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use