VirtualBox

Ticket #13659 (new defect)

Opened 5 years ago

Last modified 8 days ago

Hardened protection incorrectly get name of injected signed (!) dll and can't verify signature, so rejecting it

Reported by: JDan Owned by:
Component: host support Version: VirtualBox 4.3.20
Keywords: hardened Cc:
Guest type: all Host type: Windows

Description

Hardened protection incorrectly get name of injected signed (!) dll and can't verify signature, so rejecting it.

VirtualBox since 4.3.14 (all builds, including 4.3.20/4.3.21 - the most updated) are incompatible with Outpost Firewall Pro v6.7.x and others, that used "WL_HOOK.DLL" module to inject to all processes to get some information in RING3 (usermode).

WL_HOOK.DLL is digitally signed (!) (I can attach this file, if needed), and must be allowed even by hardened rules. But VirtualBox incorrectly recognize a path to it. There is a bug in VirtualBox getting/parsing path information in some cases of modules inject or other (probably, is because of special inject technics, that used). Please see a VBoxStartup.log:

...
e4.11ec: supR3HardenedScreenImage/NtCreateSection: cache hit (Unknown Status 22900 (0x5974)) on \Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume3\WINDOWS\system32\imm32.dll [lacks WinVerifyTrust]
e4.11ec: supR3HardenedMonitor_LdrLoadDll: returns rcNt=0x0 hMod=76290000 'E:\WINDOWS\system32\IMM32.DLL'
e4.11ec: supHardenedWinVerifyImageByHandle: -> -23021 (\Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume3\Program Files\Outpost Firewallц╜ОцХоц╝атБжцб┤тБетА▒цЕ░цб┤чМитАйцЕицХ╢цДачРачХ▓чС│цДацНоц╜ит╣▓тА║фСЬчЩецНйх▒ецЕИцС▓цедцн│ц╡Дц╜ЦчХмцХнх▒│цбРчН╣цНйц▒бц╡Дц╜ЦчХмцХнх▒│ц▒ВцНпхЩлц▒пц╡╡уНехБЬц╜▓чЙзц╡бфШац▒йчНеф╜ЬчС╡ц╜░чС│фШачЙйчЭец▒бюЩмш║╜щЧжюЪоъВ╝шЗвюЪжыТбшЗвюКеыЖАшЧжюЪ░ыТбш│зюКиъжАшЧжюЪиыЪХшУжюЮаъВРщЧзюЮ▓ыОСшУжюЪаъ║Ны╖жюКиыК╣шГв┬║)
e4.11ec: Error (rc=0):
e4.11ec: supR3HardenedScreenImage/LdrLoadDll: rc=Unknown Status -23021 (0xffffa613) fImage=1 fProtect=0x0 fAccess=0x0 \Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume3\Program Files\Outpost Firewallц╜ОцХоц╝атБжцб┤тБетА▒цЕ░цб┤чМитАйцЕицХ╢цДачРачХ▓чС│цДацНоц╜ит╣▓тА║фСЬчЩецНйх▒ецЕИцС▓цедцн│ц╡Дц╜ЦчХмцХнх▒│цбРчН╣цНйц▒бц╡Дц╜ЦчХмцХнх▒│ц▒ВцНпхЩлц▒пц╡╡уНехБЬц╜▓чЙзц╡бфШац▒йчНеф╜ЬчС╡ц╜░чС│фШачЙйчЭец▒бюЩмш║╜щЧжюЪоъВ╝шЗвюЪжыТбшЗвюКеыЖАшЧжюЪ░ыТбш│зюКиъжАшЧжюЪиыЪХшУжюЮаъВРщЧзюЮ▓ыОСшУжюЪаъ║Ны╖жюКиыК╣шГв┬║: None of the 1 path(s) have a trust anchor.: \Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume3\Program Files\Outpost Firewallц╜ОцХоц╝атБжцб┤тБетА▒цЕ░цб┤чМитАйцЕицХ╢цДачРачХ▓чС│цДацНоц╜ит╣▓тА║
e4.11ec: supR3HardenedWinVerifyCacheInsert: \Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume3\Program Files\Outpost Firewallц╜ОцХоц╝атБжцб┤тБетА▒цЕ░цб┤чМитАйцЕицХ╢цДачРачХ▓чС│цДацНоц╜ит╣▓тА║фСЬчЩецНйх▒ецЕИцС▓цедцн│ц╡Дц╜ЦчХмцХнх▒│цбРчН╣цНйц▒бц╡Дц╜ЦчХмцХнх▒│ц▒ВцНпхЩлц▒пц╡╡уНехБЬц╜▓чЙзц╡бфШац▒йчНеф╜ЬчС╡ц╜░чС│фШачЙйчЭец▒бюЩмш║╜щЧжюЪоъВ╝шЗвюЪжыТбшЗвюКеыЖАшЧжюЪ░ыТбш│зюКиъжАшЧжюЪиыЪХшУжюЮаъВРщЧзюЮ▓ыОСшУжюЪаъ║Ны╖жюКиыК╣шГв┬║
e4.11ec: Error (rc=0):
e4.11ec: supR3HardenedMonitor_LdrLoadDll: rejecting 'e:\progra~1\outpos~1\wl_hook.dll': rcNt=0xc0000190
e4.11ec: supR3HardenedMonitor_LdrLoadDll: returns rcNt=0xc0000190 'e:\progra~1\outpos~1\wl_hook.dll'
...

Please see a lot of garbage (binary garbage like "ц╜ОцХоц╝атБжцб┤тБетА▒цЕ░ц" and so on) after "\Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume3\Program Files\Outpost Firewall" string, instead of normal dll name path.

The real path to wl_hook.dll is E:\Program Files\Outpost Firewall Pro\wl_hook.dll

So it must be like: "\Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume3\Program Files\Outpost Firewall\wl_hook.dll"

But you had incorrectly get/parsed data. It seems like buffer contain a garbarge or like string's ending-zero is missed or something, so you are reading garbage memory.

After you are got that garbarge-containing-path you a providing it to a system function WinVerifyTrust to check digital signature of this "file". But path is invalid (garbaged/damaged), so Windows function cannot find the file and check digital signature and returns an error.

After getting this error, you are REJECTING to load this .dll.

And after that, we have a problems to use VM. Because Outpost Firewall cannot read information about process without this R3-dll injected to VM's process, so it can't get correct ProcessName and can't allow/create_rule to any network or other activity from VM, so it is UNUSABLE.

Please fix path retreiving/parsing or this inject method allowing and allow WL_HOOK.DLL (digitally signed) to inject to your process.

Attachments

VBoxStartup.zip Download (41.9 KB) - added by JDan 5 years ago.
Full VBoxStartup.log with garbarge read from memory
wl_hook.zip Download (286.8 KB) - added by JDan 5 years ago.
wl_hook.dll (signed, but not validated by VirtualBox)
VBoxHardening.log Download (25.0 KB) - added by Robert Fernando 2 years ago.
vbxox log taken from samsung laptop with i7 cpu
hardening-wl_hook.log Download (3.9 KB) - added by Captain Crunch 3 weeks ago.
good-sig-still-fails.log Download (1.1 KB) - added by Captain Crunch 8 days ago.
Hardening log of good signature that's still blocked by VB

Change History

comment:1 Changed 5 years ago by JDan

Of course, all other Windows apps and OS components show this dll correctly (and path to this .dll). How it seems in modules list normally? For example, in explorer.exe. Windows parsing path to the module correctly. Any software showing modules - showing them correctly, including "wl_hook.dll":

    Modules:
      Base      Size    Path, version, description
      01000000  104000 E:\WINDOWS\Explorer.EXE      6.00.3790.3959 (srv03_sp2_rtm.070216-1710) Windows Explorer
      7C800000   C3000 E:\WINDOWS\system32\ntdll.dll   5.2.3790.4937 (srv03_sp2_gdr.111121-0236) NT Layer DLL
      77E40000  104000 E:\WINDOWS\system32\kernel32.dll   5.2.3790.5295 (srv03_sp2_qfe.140205-1447) Windows NT BASE API Client DLL
    ...
      71B70000   36000 E:\WINDOWS\system32\UxTheme.dll   6.00.3790.3959 (srv03_sp2_rtm.070216-1710) Microsoft UxTheme Library
      76290000   1D000 E:\WINDOWS\system32\IMM32.DLL   5.2.3790.3959 (srv03_sp2_rtm.070216-1710) Windows IMM32 API Client DLL
      10000000   A4000 e:\progra~1\outpos~1\wl_hook.dll   6.7.2922.10022   Outpost Hooking Module
      00870000    E000 E:\WINDOWS\system32\hplun.dll   1.00.2           HotPlug help module
      77420000  103000 E:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.5190_x-ww_319264BE\comctl32.dll   6.0 (srv03_sp2_qfe.130703-1535) User Experience Controls Library
      75E60000   27000 E:\WINDOWS\system32\apphelp.dll   5.2.3790.3959 (srv03_sp2_rtm.070216-1710) Application Compatibility Client Library
    ...

comment:2 Changed 5 years ago by JDan

OS: Windows 2003 x86

Log from the VirtualBox 4.3.20:

1c74.e9c: Log file opened: 4.3.20r96997 g_hStartupLog=000027d8 g_uNtVerCombined=0x520ece20
1c74.e9c: \SystemRoot\System32\ntdll.dll:
1c74.e9c:     CreationTime:    2009-04-11T22:12:37.671875000Z
1c74.e9c:     LastWriteTime:   2011-11-22T16:29:04.000000000Z
1c74.e9c:     ChangeTime:      2014-10-06T20:29:32.548152200Z
1c74.e9c:     FileAttributes:  0x20
1c74.e9c:     Size:            0xbdc00
1c74.e9c:     NT Headers:      0xe0
1c74.e9c:     Timestamp:       0x4ecbcdd1
1c74.e9c:     Machine:         0x14c - i386
1c74.e9c:     Timestamp:       0x4ecbcdd1
1c74.e9c:     Image Version:   5.2
1c74.e9c:     SizeOfImage:     0xc3000 (798720)
1c74.e9c:     Resource Dir:    0x90000 LB 0x2e250
1c74.e9c:     ProductName:     Microsoft┬о Windows┬о Operating System
1c74.e9c:     ProductVersion:  5.2.3790.4937
1c74.e9c:     FileVersion:     5.2.3790.4937 (srv03_sp2_gdr.111121-0236)
1c74.e9c:     FileDescription: NT Layer DLL
1c74.e9c: \SystemRoot\System32\kernel32.dll:
1c74.e9c:     CreationTime:    2014-02-06T09:25:49.000000000Z
1c74.e9c:     LastWriteTime:   2014-02-06T09:25:49.000000000Z
1c74.e9c:     ChangeTime:      2014-11-27T11:59:13.846304800Z
1c74.e9c:     FileAttributes:  0x20
1c74.e9c:     Size:            0xff000
1c74.e9c:     NT Headers:      0xe8
1c74.e9c:     Timestamp:       0x52f3551e
1c74.e9c:     Machine:         0x14c - i386
1c74.e9c:     Timestamp:       0x52f3551e
1c74.e9c:     Image Version:   5.2
1c74.e9c:     SizeOfImage:     0x104000 (1064960)
1c74.e9c:     Resource Dir:    0x92000 LB 0x6a6c8

...

108c.1a60: supR3HardenedScreenImage/NtCreateSection: cache hit (Unknown Status 22900 (0x5974)) on \Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume3\WINDOWS\system32\imm32.dll [lacks WinVerifyTrust]
108c.1a60: supR3HardenedScreenImage/NtCreateSection: cache hit (Unknown Status 22900 (0x5974)) on \Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume3\WINDOWS\system32\imm32.dll [lacks WinVerifyTrust]
108c.1a60: supR3HardenedMonitor_LdrLoadDll: returns rcNt=0x0 hMod=76290000 'E:\WINDOWS\system32\IMM32.DLL'
108c.1a60: supHardenedWinVerifyImageByHandle: -> -23021 (\Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume3\Program Files\Outpost Firewallц╜ОцХоц╝атБжцб┤тБетА▒цЕ░цб┤чМитАйцЕицХ╢цДачРачХ▓чС│цДацНоц╜ит╣▓тА║фСЬчЩецНйх▒ецЕИцС▓цедцн│ц╡Дц╜ЦчХмцХнх▒│цбРчН╣цНйц▒бц╡Дц╜ЦчХмцХнх▒│ц▒ВцНпхЩлц▒пц╡╡уНехБЬц╜▓чЙзц╡бфШац▒йчНеф╜ЬчС╡ц╜░чС│фШачЙйчЭец▒бюЩмш║╜щЧжюЪоъВ╝шЗвюЪжыТбшЗвюКеыЖАшЧжюЪ░ыТбш│зюКиъжАшЧжюЪиыЪХшУжюЮаъВРщЧзюЮ▓ыОСшУжюЪаъ║Ны╖жюКиыК╣шГв┬║)
108c.1a60: Error (rc=0):
108c.1a60: supR3HardenedScreenImage/LdrLoadDll: rc=Unknown Status -23021 (0xffffa613) fImage=1 fProtect=0x0 fAccess=0x0 \Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume3\Program Files\Outpost Firewallц╜ОцХоц╝атБжцб┤тБетА▒цЕ░цб┤чМитАйцЕицХ╢цДачРачХ▓чС│цДацНоц╜ит╣▓тА║фСЬчЩецНйх▒ецЕИцС▓цедцн│ц╡Дц╜ЦчХмцХнх▒│цбРчН╣цНйц▒бц╡Дц╜ЦчХмцХнх▒│ц▒ВцНпхЩлц▒пц╡╡уНехБЬц╜▓чЙзц╡бфШац▒йчНеф╜ЬчС╡ц╜░чС│фШачЙйчЭец▒бюЩмш║╜щЧжюЪоъВ╝шЗвюЪжыТбшЗвюКеыЖАшЧжюЪ░ыТбш│зюКиъжАшЧжюЪиыЪХшУжюЮаъВРщЧзюЮ▓ыОСшУжюЪаъ║Ны╖жюКиыК╣шГв┬║: None of the 1 path(s) have a trust anchor.: \Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume3\Program Files\Outpost Firewallц╜ОцХоц╝атБжцб┤тБетА▒цЕ░цб┤чМитАйцЕицХ╢цДачРачХ▓чС│цДацНоц╜ит╣▓тА║
108c.1a60: supR3HardenedWinVerifyCacheInsert: \Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume3\Program Files\Outpost Firewallц╜ОцХоц╝атБжцб┤тБетА▒цЕ░цб┤чМитАйцЕицХ╢цДачРачХ▓чС│цДацНоц╜ит╣▓тА║фСЬчЩецНйх▒ецЕИцС▓цедцн│ц╡Дц╜ЦчХмцХнх▒│цбРчН╣цНйц▒бц╡Дц╜ЦчХмцХнх▒│ц▒ВцНпхЩлц▒пц╡╡уНехБЬц╜▓чЙзц╡бфШац▒йчНеф╜ЬчС╡ц╜░чС│фШачЙйчЭец▒бюЩмш║╜щЧжюЪоъВ╝шЗвюЪжыТбшЗвюКеыЖАшЧжюЪ░ыТбш│зюКиъжАшЧжюЪиыЪХшУжюЮаъВРщЧзюЮ▓ыОСшУжюЪаъ║Ны╖жюКиыК╣шГв┬║
108c.1a60: Error (rc=0):
108c.1a60: supR3HardenedMonitor_LdrLoadDll: rejecting 'e:\progra~1\outpos~1\wl_hook.dll' (e:\progra~1\outpos~1\wl_hook.dll): rcNt=0xc0000190
108c.1a60: supR3HardenedMonitor_LdrLoadDll: returns rcNt=0xc0000190 'e:\progra~1\outpos~1\wl_hook.dll'
108c.1a60: supR3HardenedWinVerifyCacheScheduleImports: Import todo: #0 'advapi32.dll'.
...

comment:3 follow-up: ↓ 4 Changed 5 years ago by frank

Please: Could you attach the complete VBoxStartup.log file?

Changed 5 years ago by JDan

Full VBoxStartup.log with garbarge read from memory

comment:4 in reply to: ↑ 3 Changed 5 years ago by JDan

Replying to frank:

Please: Could you attach the complete VBoxStartup.log file?

I'm sure that all related technical info required to analyze/fix the bug is already posted, but OK, I will attach the fullest of the full VBoxStartup.log in zip archive.

comment:5 Changed 5 years ago by JDan

1) This is actual for 4.3.22 too. Nothing is changed at all.


2) Additional information about loaded module:

Module is loaded through App_InitDlls. Please test with it. Here is information from the registry:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows
AppInit_DLLs = "e:\progra~1\outpos~1\wl_hook.dll hplun.dll "

3) Also, please note on this. I found in code of Hardened a lot of NtQueryObject to get a filename. Please note on this from MSDN:

FileName
A UNICODE_STRING structure whose Buffer member points to a read-only
Unicode string that holds the name of the file opened on the volume.
If the volume is being opened, the Length member of the UNICODE_STRING
structure will be zero. Note that the file name in this string is valid
only during the initial processing of an IRP_MJ_CREATE request.
This file name should not be considered valid after the file system
starts to process the IRP_MJ_CREATE request. The storage for the string
pointed to by the Buffer member of the UNICODE_STRING structure is
allocated in paged system memory. For more information about obtaining
a file name, see FltGetFileNameInformation.

Bolded: Note that the file name in this string is valid only during the initial processing of an IRP_MJ_CREATE request

 https://msdn.microsoft.com/en-us/library/ff545834%28v=vs.85%29.aspx

Moreover, this code also ignores (!) the size of returned buffer data (not checked). (You can search for NtQueryObject through the code.

Some sample:

    NTSTATUS rcNt = NtQueryObject(hFile,
                                  ObjectNameInformation,
                                  &uBuf,
                                  sizeof(uBuf) - sizeof(WCHAR),
                                  &cbIgn);
    if (NT_SUCCESS(rcNt))
        uBuf.UniStr.Buffer[uBuf.UniStr.Length / sizeof(WCHAR)] = '\0';
    else
        uBuf.UniStr.Buffer = (WCHAR *)L"TODO3";

4) Also, could you add more debug strings to a logfile VBStartup.log, so I can understand where in code you had get an invalid module name for that .dll. Because currently I have idea about exact location without debugging.

Current logs doesn't give a full way understanding (codeflow), see here (It's not a chinese chars, it is a memory garbage [binary data]):

11c.1338: supR3HardenedMonitor_LdrLoadDll: returns rcNt=0x0 hMod=76290000 'E:\WINDOWS\system32\IMM32.DLL'

11c.1338: supHardenedWinVerifyImageByHandle: -> -23021 (\Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume3\Program Files\Outpost Firewall潎敮漠⁦桴⁥‱慰桴猨 慨敶愠琠畲瑳愠据潨⹲›䑜癥捩履慈摲楤歳浄潖畬敭屳桐獹捩污浄潖畬敭屳求捯噫汯浵㍥停潲牧浡䘠汩獥作瑵潰瑳䘠物睥污躽闦ꂼ臢뒡臢놀藦뒡賧ꦀ藦뚕蓦ꂐ闧뎑蓦꺍뷦늹胢º)

11c.1338: Error (rc=0):

11c.1338: supR3HardenedScreenImage/LdrLoadDll: rc=Unknown Status -23021 (0xffffa613) fImage=1 fProtect=0x0 fAccess=0x0 \Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume3\Program Files\Outpost Firewall潎敮漠⁦桴⁥‱慰桴猨 慨敶愠琠畲瑳愠据潨⹲›䑜癥捩履慈摲楤歳浄潖畬敭屳桐獹捩污浄潖畬敭屳求捯噫汯浵㍥停潲牧浡䘠汩獥作瑵潰瑳䘠物睥污躽闦ꂼ臢뒡臢놀藦뒡賧ꦀ藦뚕蓦ꂐ闧뎑蓦꺍뷦늹胢º: None of the 1 path(s) have a trust anchor.: \Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume3\Program Files\Outpost Firewall潎敮漠⁦桴⁥‱慰桴猨 慨敶愠琠畲瑳愠据潨⹲›

11c.1338: supR3HardenedWinVerifyCacheInsert: \Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume3\Program Files\Outpost Firewall潎敮漠⁦桴⁥‱慰桴猨 慨敶愠琠畲瑳愠据潨⹲›䑜癥捩履慈摲楤歳浄潖畬敭屳桐獹捩污浄潖畬敭屳求捯噫汯浵㍥停潲牧浡䘠汩獥作瑵潰瑳䘠物睥污躽闦ꂼ臢뒡臢놀藦뒡賧ꦀ藦뚕蓦ꂐ闧뎑蓦꺍뷦늹胢º

11c.1338: Error (rc=0):

11c.1338: supR3HardenedMonitor_LdrLoadDll: rejecting 'e:\progra~1\outpos~1\wl_hook.dll' (e:\progra~1\outpos~1\wl_hook.dll): rcNt=0xc0000190

11c.1338: supR3HardenedMonitor_LdrLoadDll: returns rcNt=0xc0000190 'e:\progra~1\outpos~1\wl_hook.dll'

11c.1338: supR3HardenedWinVerifyCacheScheduleImports: Import todo: #0 'advapi32.dll'.

Last edited 5 years ago by JDan (previous) (diff)

Changed 5 years ago by JDan

wl_hook.dll (signed, but not validated by VirtualBox)

comment:6 Changed 5 years ago by JDan

Just as experiment I decide, that maybe you Hardened code a problems with parsing ShortNames (instead of LFN), I made the following things:

  1. I had copied "wl_hook.dll" from "E:\Program Files\Outpost Firewall Pro" to "E:\WINDOWS\system32" (just for experiment; it will not work correctly, because read some configs from its directory)
  1. I had changed in registry:

AppInit_Dlls from: "e:\progra~1\outpos~1\wl_hook.dll hplun.dll " to "wl_hook.dll hplun.dll " So, now, AppInit contain a names without shortnames (~1, etc)

  1. I started the VirtualMachine and got a log:

1450.df8: supR3HardenedMonitor_LdrLoadDll: returns rcNt=0x0 hMod=76290000 'E:\WINDOWS\system32\IMM32.DLL'

1450.df8: supHardenedWinVerifyImageByHandle: -> -23021 (\Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume3\WINDOWS\system32\wl_hook.dll)

1450.df8: Error (rc=0):

1450.df8: supR3HardenedScreenImage/LdrLoadDll: rc=Unknown Status -23021 (0xffffa613) fImage=1 fProtect=0x0 fAccess=0x0 \Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume3\WINDOWS\system32\wl_hook.dll: None of the 1 path(s) have a trust anchor.: \Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume3\WINDOWS\system32\wl_hook.dll

1450.df8: supR3HardenedWinVerifyCacheInsert: \Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume3\WINDOWS\system32\wl_hook.dll

1450.df8: Error (rc=0):

1450.df8: supR3HardenedMonitor_LdrLoadDll: rejecting 'E:\WINDOWS\system32\wl_hook.dll': rcNt=0xc0000190

1450.df8: supR3HardenedMonitor_LdrLoadDll: returns rcNt=0xc0000190 'E:\WINDOWS\system32\wl_hook.dll'

1450.df8: supR3HardenedWinVerifyCacheScheduleImports: Import todo: #0 'advapi32.dll'.


So, now it have no garbage after the directory name. It is correctly displayed (logged). But errors are the same:

a) Garbarged status, really trash - what is it?! I think it is a bug: supR3HardenedScreenImage/LdrLoadDll: rc=Unknown Status -23021 (0xffffa613)

b) And later Hardened rejecting it with: "rcNt=0xc0000190"

That means: #define STATUS_TRUST_FAILURE ((NTSTATUS)0xC0000190L)

But I think, this status is made (provided) by Hardened code, not by OS


So, now we see two or even three issues:

  1. Incorrect module name getting (garbage in memory) -- see a start of the ticket, logs, etc.
  2. Incorrect (garbaged) status returning after checking the file LdrLoadDll = -23021 (0xffffa613)
  3. Rejecting signed wl_hook.dll! (See attached archive with this dll for checking).

comment:7 follow-up: ↓ 8 Changed 4 years ago by Captain Crunch

I've just gotten hit by this bug, as well, the latest VirtualBox, 4.3.28. After wasting several hours trying to reconfigure Outpost (9.x/latest), I tried installing VirtualBox 4.3.12, and that fixed things. So apparently with this bug, Outpost can't detect the process name so the rules all fail?

The OP is obviously an advanced user, so what I would suggest to him is, set up an environment in which you can build VirtualBox - this should be possible since it's open source. Build VB 4.3.12 initially. Then find all the commits between 4.3.12 and 4.3.14 and use a binary search to isolate the bad change. That is, if there are 100 changes total, apply the first 50, if the bug occurs, revert the last 25 of those. otherwise apply another 25. This should allow you to zero in on the bad commit in log(N) iterations, where N is the number of total commits.

Once we know which commit broke things, hopefully we'll also know the developer, and that will put some heat on him to take responsibility and fix it. Or, you could post the bad commit in this thread and see if the community can recommend a fix.

As it stands right now, VB 4.3.28 basically bricks all guest OSes that need internet access, unless I disable my firewall. (That's not going to happen.) It's sad that this showstopper has sat unfixed for 7 months with no one apparently even working on it.

comment:8 in reply to: ↑ 7 Changed 4 years ago by JDan

Replying to Captain Crunch:

I've just gotten hit by this bug, as well, the latest VirtualBox, 4.3.28. After wasting several hours trying to reconfigure Outpost (9.x/latest), I tried installing VirtualBox 4.3.12, and that fixed things. So apparently with this bug, Outpost can't detect the process name so the rules all fail?

The answer is obvious - in VB 4.3.12 there is no annoying Hardened Protection. So, all is working fine. Starting from VB 4.3.14 there is Hardened Protection with the bugs like I wrote above. So we have what we have, and guys from Oracle seems do not want to fix such bugs, that does not allow to use VirtualBox + Outpost + internet connection.

It is a bug in Hardened code, that trying to analyze all modules that are mapped to the VB processes. This code have a bug(s) getting a path to module/checking it is signature. So, it rejecting Outpost module. After that Outpost (without this signed module that must be injected to VB) cannot get ProcessName and some other data, so it is now allowing any connections to internet normally.

comment:9 Changed 4 years ago by Gorilla Fu

"Hardened Protection" isn't a commit, it's a feature. (I suppose it could all have been a single commit, but we want to examine the commit.) The suggestion is to find the exact commit that broke things, and since the project is open source, that should give us a developer name.

Then we can contact that developer via email.

comment:10 follow-up: ↓ 11 Changed 4 years ago by bird

The -23021 error code translates to VERR_CR_X509_CPV_NO_TRUSTED_PATHS, which indicates that we're unable to validate the sign signature of the DLL. Try sigcheck.exe SysInternals/Microsoft on the DLL, if it's not happy about it, you are probably missing some relevant root certificate on your system. (From what I could tell, the main root certificate was an old MD2 signed certificate from VeriSign which system admins may not be too happy to install as MD2 is no longer considered secure.)

PS. The developer's name is vboxsync, according to the timeline. We'll let him know... :-)

comment:11 in reply to: ↑ 10 Changed 3 years ago by JDan

Replying to bird:

The -23021 error code translates to VERR_CR_X509_CPV_NO_TRUSTED_PATHS, which indicates that we're unable to validate the sign signature of the DLL. Try sigcheck.exe SysInternals/Microsoft on the DLL, if it's not happy about it, you are probably missing some relevant root certificate on your system. (From what I could tell, the main root certificate was an old MD2 signed certificate from VeriSign which system admins may not be too happy to install as MD2 is no longer considered secure.)

Dear, bird, did you read a ticket at all? Of course it will return -23021 error, because it got a... GARBAGED BINARY PATH, not a realy path on the disk.

Again, shortly:

The real path to wl_hook.dll is E:\Program Files\Outpost Firewall Pro\wl_hook.dll

So it must be like: "\Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume3\Program Files\Outpost Firewall\wl_hook.dll"

What you are getting in Hardening? See here:

11c.1338: supHardenedWinVerifyImageByHandle: -> -23021 (\Device\HarddiskDmVolumes\PhysicalDmVolumes\BlockVolume3\Program Files\Outpost Firewall潎敮漠⁦桴⁥‱慰桴猨 慨敶愠琠畲瑳愠据潨⹲›䑜癥捩履慈摲楤歳浄潖畬敭屳桐獹捩污浄潖畬敭屳求捯噫汯浵㍥停潲牧浡䘠汩獥作瑵潰瑳䘠物睥污躽闦ꂼ臢뒡臢놀藦뒡賧ꦀ藦뚕蓦ꂐ闧뎑蓦꺍뷦늹胢º) 

(Please move cursor more right and you will see about what I'm talking; See the end of string).

This binary garbage is not a national chars or something. It is BINARY GARBAGE FROM MEMORY.

PS. The developer's name is vboxsync, according to the timeline. We'll let him know... :-)

That is very funny joke, yeah! I'm sure other guys will make haha. For Gorilla Fu: main developer of the hardened protection is a bird. Old version of VB does not have that code at all. But as we can see, he is a really joker. What a funny, invalid signature of file with a binary-garbage-path, yahoo, check the signature of the trash...

comment:12 Changed 3 years ago by frank

JDan, which VirtualBox version does your last comment refer to?

comment:13 Changed 2 years ago by Robert Fernando

I get this with the latest 5.1.22 version.

(removed pasted log)

Last edited 2 years ago by frank (previous) (diff)

comment:14 follow-up: ↓ 15 Changed 2 years ago by frank

Robert, please use the Attach file button to add re-attach the log file.

Changed 2 years ago by Robert Fernando

vbxox log taken from samsung laptop with i7 cpu

comment:15 in reply to: ↑ 14 Changed 2 years ago by Robert Fernando

Replying to frank:

Robert, please use the Attach file button to add re-attach the log file.

Changed 3 weeks ago by Captain Crunch

comment:16 Changed 3 weeks ago by Captain Crunch

This problem is still present in VirtualBox 6.0.14r133895 and is still causing all Internet access from VB guests to be blocked. For some reason, this issue doesn't affect Windows 7 x64, but Windows 7 is EOL as of a few months, so it's becoming critical. (I'm hitting this issue on Windows 8.1 x64 machines.)

I understand why hardening is the default, but the fact that there's no way to turn it off for situations like this is upsetting. If we hit January and I need to migrate to windows 8.1 on all my systems, I guess I'll just have to rebuild VirtualBox from source and disable the hardening code myself to avoid this problem, but that sure sounds like a lot of trouble.

I've attached the hardening log for the DLL in question, wl_hook.dl. I've not attached the full log as I'd need to vet the content to ensure I'm not leaking personal info (paths? IDs?).

After 5 years, can someone fix this please? This doesn't appear to be Outpost's fault. What exactly is "Unknown Status 24202 (0x5e8a)"? Does that code mean something? Is there any additional logging that can be activated to provide more details?

comment:17 follow-up: ↓ 19 Changed 3 weeks ago by socratis

Related discussion (and answer) in the forums:  https://forums.virtualbox.org/viewtopic.php?f=6&t=95296

comment:18 Changed 3 weeks ago by Captain Crunch

Note that the status code I'm getting is > 0. It's an INFO message, and shouldn't prevent loading of the DLL, but that what it's doing, as you can see from the line:

"supR3HardenedWinVerifyCacheProcessWvtTodos: 24202 (was 24202) fWinVerifyTrust=0"

(for a successful load, you'll see "fWinVerifyTrust=1"). So this is a genuine bug that should be fixed by Oracle.

The code 24202 is VINF_CR_DIGEST_DEPRECATED. It's a deprecation INFO, not an error. I think it's most likely reporting the fact that the cert uses SHA1 hashes instead of SHA2/256/512. Perhaps Windows 7 doesn't report this deprecation, leading to the difference in behavior? In any event, it should be fixed.

Last edited 3 weeks ago by Captain Crunch (previous) (diff)

comment:19 in reply to: ↑ 17 ; follow-up: ↓ 20 Changed 3 weeks ago by Captain Crunch

Replying to socratis:

Related discussion (and answer) in the forums:  https://forums.virtualbox.org/viewtopic.php?f=6&t=95296

I assume you're just cross-linking these for benefit of other users. I'm the same guy who started the forums thread. As far as it being "answered," I'm still waiting for your answer on my subsequent followups. Hopefully the answer is, "Good catch. We'll fix that!"

comment:20 in reply to: ↑ 19 ; follow-up: ↓ 21 Changed 3 weeks ago by socratis

Replying to Captain Crunch:

I assume you're just cross-linking these for benefit of other users.

Exactly! Just like I'm going to link the thread to the ticket.

I'm the same guy who started the forums thread.

Even though "Captain Crunch" != "Todd Almighty", it was more than obvious, that's how I managed to link the two... ;)

As far as it being "answered," I'm still waiting for your answer on my subsequent followups. Hopefully the answer is, "Good catch. We'll fix that!"

Discussion will continue in the forums, right.

comment:21 in reply to: ↑ 20 Changed 3 weeks ago by Captain Crunch

Replying to socratis:

Even though "Captain Crunch" != "Todd Almighty", it was more than obvious, that's how I managed to link the two... ;)

I couldn't see any way to change my user name on the forums. If you know how, let me know.

comment:22 Changed 2 weeks ago by socratis

There's no way to change your nickname, not even an easy one for the admins... :(

Changed 8 days ago by Captain Crunch

Hardening log of good signature that's still blocked by VB

comment:23 Changed 8 days ago by Captain Crunch

OK, I've finally got the DLL self-signed with a proper SHA256 certificate, but Virtualbox is still failing the DLL, claiming that it "detected loader lock ownership". From the attached log file, you can see first:

"Detected loader lock ownership: rc=VINF_SUCCESS '\Device\HarddiskVolume6\Program Files\Agnitum\Outpost Firewall Pro\WL_HOO~1.DLL'."

and that causes WinVerifyTrust to get skipped:

"supR3HardenedWinVerifyCacheProcessWvtTodos: 0 (was 0) fWinVerifyTrust=0 for '\Device\HarddiskVolume6\Program Files\Agnitum\Outpost Firewall Pro\WL_HOO~1.DLL' [rescheduled]"

You can see from the source code here:

 https://fossies.org/linux/VirtualBox/src/VBox/HostDrivers/Support/win/SUPHardenedVerifyImage-win.cpp

for the function supHardenedWinVerifyImageTrust() that it will return fWinVerifyTrust false even though a status 0 is returned (usually means success) if it can't call WinVerifyTrust because fOwnsLoaderLock is true. Why can't it run the verification if it owns the loader lock, and how can i fix this?

The log also says "[rescheduling]" but there is no more mention of that DLL in the log so obviously it did NOT reschedule anything.

comment:24 Changed 8 days ago by Captain Crunch

Looking 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. Anyone else agree?

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.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use