#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)
Change History (8)
comment:1 by , 6 years ago
comment:2 by , 6 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Summary: | VirtualBox cannot start VMs on 32-bit x86 builds of the upcoming October 2018 Update of Windows → 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 by , 6 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
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 , 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:6 by , 6 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
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 , 6 years ago
Go for the latest 5.2 Testbuilds - revision 126140 and later should have the fix for the fix.
Previous instances of the same problem: #15337 #13665