VirtualBox

Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#17977 closed defect (fixed)

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:
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 (1)

VBoxHardening.log (37.8 KB ) - added by Jon K 6 years ago.
VBoxHardening.log from crash repro

Download all attachments as: .zip

Change History (8)

comment:1 by Jon K, 6 years ago

Previous instances of the same problem: #15337 #13665

by Jon K, 6 years ago

Attachment: VBoxHardening.log added

VBoxHardening.log from crash repro

comment:2 by bird, 6 years ago

Resolution: fixed
Status: newclosed
Summary: VirtualBox cannot start VMs on 32-bit x86 builds of the upcoming October 2018 Update of WindowsVirtualBox 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 by Jon K, 6 years ago

Resolution: fixed
Status: closedreopened

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 by Klaus Espenlaub, 6 years ago

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 by bird, 6 years ago

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

comment:6 by bird, 6 years ago

Resolution: fixed
Status: reopenedclosed

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 by Klaus Espenlaub, 6 years ago

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.

© 2024 Oracle Support Privacy / Do Not Sell My Info Terms of Use Trademark Policy Automated Access Etiquette