VirtualBox

Ticket #13659 (new defect)

Opened 5 years ago

Last modified 2 years 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

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.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use