VirtualBox

Ticket #17977 (closed defect: fixed)

Opened 2 months ago

Last modified 3 weeks ago

VirtualBox cannot start VMs on 32-bit x86 builds of the upcoming October 2018 Update of Windows => fixed in svn

Reported by: Jon K Owned by:
Priority: major Component: other
Version: VirtualBox 5.2.18 Keywords:
Cc: Guest type: all
Host type: Windows

Description

The October 2018 Update has added a new pointer-sized field to the end of IMAGE_LOAD_CONFIG_DIRECTORY32 & IMAGE_LOAD_CONFIG_DIRECTORY64 structures and for some DLLs, this field is set to point to an opaque blob. Such DLLs are being rejected by VirtualBox (see excerpt below from VBoxHardening.log).

Is there a way to update the validation in VirtualBox to accept this new field being nonzero? The 32-bit structure has increased from 160 to 164 bytes. The 64-bit structure has increased from 256 to 264 bytes.

Additionally, is it possible to make the validation work with future changes to these data structures? Windows has expanded these in the past and may do so again in the future.

VBoxHardening.log excerpt:

f50.274c: supR3HardenedWinVerifyCacheProcessImportTodos: Processing 'msvcrt.dll'...
f50.274c: supR3HardenedWinVerifyCacheProcessImportTodos: 'msvcrt.dll' -> '\Device\HarddiskVolume2\Windows\System32\msvcrt.dll' [rcNtRedir=0xc0150008]
f50.274c: supHardenedWinVerifyImageByHandle: -> -626 (\Device\HarddiskVolume2\Windows\System32\msvcrt.dll)
f50.274c: Error (rc=0):
f50.274c: supR3HardenedScreenImage/Imports: rc=Unknown Status -626 (0xfffffd8e) fImage=1 fProtect=0x0 fAccess=0x0 \Device\HarddiskVolume2\Windows\System32\msvcrt.dll: Grown load config (160 to 164 bytes) includes non-zero bytes: ec ef 12 10
f50.274c: supR3HardenedWinVerifyCacheInsert: \Device\HarddiskVolume2\Windows\System32\msvcrt.dll
f50.274c: supR3HardenedMonitor_LdrLoadDll: pName=C:\Windows\system32\Wintrust.dll (rcNtResolve=0xc0150008) *pfFlags=0x0 pwszSearchPath=00000801:<flags> [calling]
f50.274c: supR3HardenedDllNotificationCallback: load   772a0000 LB 0x000c0000 C:\Windows\System32\msvcrt.dll [fFlags=0x0]
f50.274c: supR3HardenedScreenImage/LdrLoadDll: cache hit (Unknown Status -626 (0xfffffd8e)) on \Device\HarddiskVolume2\Windows\System32\msvcrt.dll [lacks WinVerifyTrust]
f50.274c: Error (rc=0):
f50.274c: supR3HardenedScreenImage/LdrLoadDll: cached rc=Unknown Status -626 (0xfffffd8e) fImage=1 fProtect=0x0 fAccess=0x0 cHits=1 \Device\HarddiskVolume2\Windows\System32\msvcrt.dll
f50.274c: Fatal error:
f50.274c: supR3HardenedDllNotificationCallback: supR3HardenedScreenImage failed on 'C:\Windows\System32\msvcrt.dll' / '\??\C:\Windows\System32\msvcrt.dll': 0xc000019

Attachments

VBoxHardening.log Download (37.8 KB) - added by Jon K 2 months ago.
VBoxHardening.log from crash repro

Change History

comment:1 Changed 2 months ago by Jon K

Previous instances of the same problem: #15337 #13665

Changed 2 months ago by Jon K

VBoxHardening.log from crash repro

comment:2 Changed 7 weeks ago by bird

  • Status changed from new to closed
  • Resolution set to fixed
  • Summary changed from VirtualBox cannot start VMs on 32-bit x86 builds of the upcoming October 2018 Update of Windows to VirtualBox cannot start VMs on 32-bit x86 builds of the upcoming October 2018 Update of Windows => fixed in svn

Should be fixed in SVN now. Will try get a build out before long, but it's a lot more work these days due to microsoft's current signing requirements.

comment:3 Changed 3 weeks ago by Jon K

  • Status changed from closed to reopened
  • Resolution fixed deleted

I see that 5.2.20 just came out and this doesn't seem to be fixed, so I'm reopening the ticket. I understand if it's currently landing in 6.0, but is there a way to get it included in a 5.2 release, considering it is pretty severe?

comment:4 Changed 3 weeks ago by klaus

The fix definitely made it to 5.2.20. Wonder why it didn't really help...

BTW, we have the test builds exactly for double checking this early, and we would've thought that there are either more complaints or someone would confirm the fix.

comment:5 Changed 3 weeks ago by bird

Could you attach the VBoxHardening.log from a 5.2.20 run.

comment:6 Changed 3 weeks ago by bird

  • Status changed from reopened to closed
  • Resolution set to fixed

Klaus pointed me to one on the forum. Seems they linker put the wrong structure value in the optional header, so another check triggered. Fixed in SVN (and backported to 5.2). Next test build / release will include the fix.

comment:7 Changed 3 weeks ago by klaus

Go for the latest 5.2 Testbuilds - revision 126140 and later should have the fix for the fix.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use