Opened 10 years ago
Last modified 5 years ago
#13659 new defect
Hardened protection incorrectly get name of injected signed (!) dll and can't verify signature, so rejecting it
| Reported by: | John Dan | 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 (5)
Change History (30)
comment:1 by , 10 years ago
comment:2 by , 10 years ago
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'. ...
follow-up: 4 comment:3 by , 10 years ago
Please: Could you attach the complete VBoxStartup.log file?
by , 10 years ago
| Attachment: | VBoxStartup.zip added |
|---|
Full VBoxStartup.log with garbarge read from memory
comment:4 by , 10 years ago
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 by , 10 years ago
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'.
by , 10 years ago
| Attachment: | wl_hook.zip added |
|---|
wl_hook.dll (signed, but not validated by VirtualBox)
comment:6 by , 10 years ago
Just as experiment I decide, that maybe you Hardened code a problems with parsing ShortNames (instead of LFN), I made the following things:
- 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)
- 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)
- 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:
- Incorrect module name getting (garbage in memory) -- see a start of the ticket, logs, etc.
- Incorrect (garbaged) status returning after checking the file LdrLoadDll = -23021 (0xffffa613)
- Rejecting signed wl_hook.dll! (See attached archive with this dll for checking).
follow-up: 8 comment:7 by , 9 years ago
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 by , 9 years ago
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 by , 9 years ago
"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.
follow-up: 11 comment:10 by , 9 years ago
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 by , 8 years ago
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...
follow-up: 15 comment:14 by , 7 years ago
Robert, please use the Attach file button to add re-attach the log file.
by , 7 years ago
| Attachment: | VBoxHardening.log added |
|---|
vbxox log taken from samsung laptop with i7 cpu
comment:15 by , 7 years ago
Replying to frank:
Robert, please use the Attach file button to add re-attach the log file.
by , 5 years ago
| Attachment: | hardening-wl_hook.log added |
|---|
comment:16 by , 5 years ago
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?
follow-up: 19 comment:17 by , 5 years ago
Related discussion (and answer) in the forums: https://forums.virtualbox.org/viewtopic.php?f=6&t=95296
comment:18 by , 5 years ago
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.
follow-up: 20 comment:19 by , 5 years ago
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!"
follow-up: 21 comment:20 by , 5 years ago
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 by , 5 years ago
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 by , 5 years ago
There's no way to change your nickname, not even an easy one for the admins... :(
by , 5 years ago
| Attachment: | good-sig-still-fails.log added |
|---|
Hardening log of good signature that's still blocked by VB
comment:23 by , 5 years ago
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:
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 by , 5 years ago
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.
comment:25 by , 5 years ago
This related bug:
https://www.virtualbox.org/ticket/19060#comment:3
has been fixed, but the DLL injection is still not working. I've added details in the other ticket because I think the problem may be related to the handling that should be run upon fWinVerifyTrust succeeding.
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 ...