Non-driver certificates not handled correctly by hardening (OpenText SOCKS)

[Lars Hupfeldt]

I had originally raised an issue with OpenText socks that theri DLL was not signed and so did not work with VirtualBox. They have now provided a signed version, but it is not signed with a driver certificate. According to OpenText support VirtualBox is not handling the signing check correctly. Some of my correspondance with OpenText support pasted below.

---

---

Hello Lars,

In regards to ticket #3056978, I received input from Engineering. This issue appears to be related to the third party application.

According to Engineering: If you used signtool, it would show DLL is properly signed. Note, using the default option, will show a trust error because the default assumes driver signing and this is a not a driver with signed catalog file. You need to use /pa argument for the signing to show as valid. Since you use SigCheck (Sysinternals), you do not need to use any parameters to show the DLL is signed

C:\Users\xx>sigcheck64 "c:\Program Files\Open Text\SOCKS Client\*" > C:\xx\sigcheck_socks.14.0.16.txt

(Refer to the output in the attached file.)

The root issue is that Virtualbox process will have HumSOCKS.dll injected into its process space (this is simply how SOCKS works on Windows). On startup it does a complicated self-validation on itself and all loaded DLLs in the main process space. Essentially the rules force that all DLLs need to be signed properly (or a couple of other exceptions for specific location and owner of file). It appears that their code fails the same way that signtool does without the /pa flag and ultimately will not start up when we are in their process space because of that. In one sense this is correct behavior because there's no signed catalog file for us at all but it's definitely unwanted because it should not apply that logic for 3rd party dlls that are not drivers.

This appears to be a long standing issue with VirtualBox - check out https://www.virtualbox.org/ticket/13659. The corrupted path it starts out as is not a problem for us but the exact same issue with failed trust for a correctly signed DLL is the main issue left.

Regards, OpenText Support

---

To: support@… Subject: Re: FW: OTCS Ticket 3056978 Socks 14: VirtualBox does not work when SocksClient is installed

Hi, I have tried your recommendation of importing the certificate. I also tried disabling the virus scanner. I also tried importing the intermediate certificate and tried loosening some policy settings, but nothing solves the problem. SHA-256 certificates show up fine in Windows and the patch required for support is installed. The error I'm getting in the VBoxHardening.log is:

14a4.1a9c: supHardenedWinVerifyImageByHandle: -> -23021 (\Device\HarddiskVolume1\Program Files\Open Text\SOCKS Client\HumSOCKS.dll) WinVerifyTrust
14a4.1a9c: Error (rc=0):
14a4.1a9c: supR3HardenedScreenImage/LdrLoadDll: rc=Unknown Status -23021 (0xffffa613) fImage=1 fProtect=0x0 fAccess=0x0 \Device\HarddiskVolume1\Program Files\Open Text\SOCKS Client\HumSOCKS.dll: None of the 1 path(s) have a trust anchor.: \Device\HarddiskVolume1\Program Files\Open Text\SOCKS Client\HumSOCKS.dll 
14a4.1a9c: supR3HardenedWinVerifyCacheInsert: \Device\HarddiskVolume1\Program Files\Open Text\SOCKS Client\HumSOCKS.dll
14a4.1a9c: Error (rc=0): 
14a4.1a9c: supR3HardenedMonitor_LdrLoadDll: rejecting 'C:\Program Files\Open Text\SOCKS Client\HumSOCKS.dll' (C:\Program Files\Open Text\SOCKS Client\HumSOCKS.dll): rcNt=0xc0000190
14a4.1a9c: supR3HardenedMonitor_LdrLoadDll: returns rcNt=0xc0000190 'C:\Program Files\Open Text\SOCKS Client\HumSOCKS.dll'

[Lars Hupfeldt]

I also tested with 5.1.23r116680

[Martin M]

I can't see any further changes to this ticket. So I would like a new update to it. We need a reply so Lars can complete his work for us.

[Lars Hupfeldt]

Any progress?

[Martin M]

I have to ask the same question. Any updates?

Btw, I forgot to link my profile with our company Support Identifier: x [censored by Klaus - support identifiers are not to be made public, if you have a support contract with Oracle covering VirtualBox you should use the official My Oracle Support channels]

Hope that helps.

[Lars Hupfeldt]

Hi Frank,

I know we keep pushing for this and you are probably very busy with the 5.2 beta release, but this issue is a complete blocker for us. It would be nice is we could get some acknowledgement that this is being looked into.

[dzakharov]

It is possible to run Windows 7 Guest and press F8 after this select non-checking signature mode and OpenText Socks client should work, at least this is my current workaround. I tried to export VirtualBox image to VMWare player, but VMWare player freezes from time to time.

[Lars Hupfeldt]

Our problem is on the host, we are running Windows host and a Linux VM. Is there any workaround for that?

[Lars Hupfeldt]

Hi Oracle. Is it possible to get some update on this ticket? We really need this issue resolved!

[Klaus Espenlaub]

This needs a bit more patience - the devs who would know about this very sensitive code area are currently unavailable. The root certs which are allowed are definitely not only the driver root cert, but it could be that Microsoft's own signatures are trusted in addition for DLLs only.

The ideal solution would be not having any 3rd party DLLs in the VirtualBox VM processes. This would avoid hardening trouble. Is it really necessary to have the socks client code active in a VM process? This habit of injecting DLLs everywhere is a gigantic security hazard, and unless Microsoft finds a way to get rid of this for good there's no way to have any amount of security on the Windows platform.

The point is that a DLL can be signed by the vendor, and still VirtualBox has no reason to trust the DLL's code. It could attack VirtualBox, trying to make use of the additional powers of a hypervisor. It would be trust without a way to revoke it in a sensible fashion.

[Lars Hupfeldt]

Klaus, this ticket is two months old, so I think we have been fairly patient, but I'm happy to finally get some response.

It is absolutely necessary for us to have the OpenText SOCKS DLL loaded. Without it we do not have access to any of the servers we need for our work. And we need it for using both the VM and other programs running on the host.

To me it feels like pseudo security to have VirtualBox check the signing of a DLL, which I have anyway loaded into the network layer of my host. If this DLL was compromised it could destroy both the host and the VM. There may be other scenarios where it makes sense for VirtualBox to check. Couldn't a feature be added to manually whitelist DLLs or to add approved certificates? We would be very happy to get such a feature. We don't need a UI to configure it, please just give us some kind of a quick fix.

[Socratis]

Replying to larsh:

To me it feels like pseudo security to have VirtualBox check the signing of a DLL, which I have anyway loaded into the network layer of my host. If this DLL was compromised it could destroy both the host and the VM.

I'm not a guru, but a DLL doesn't necessarily need to have compromised your host before it gets loaded. You could be a simple user, or a guest, running an app (unknowingly) from the %APPDATA%, the %LOCALAPPDATA% or the %TEMP% directory (like many viruses do), load that DLL, inject it into VirtualBox, which has some contexts running as System and ... kaboom. You just compromised the whole server, even though you were a guest.

As long as the scenario that I described above exists, Oracle cannot afford to *not* do something about it.

On the other hand you could talk to the OpenTextSocks people and ask them to *not* attach themselves like a leach on each and every process they encounter. They need to attach themselves to Notepad? And Minesweeper? Seriously? Or have a exclusion list of processes not to attach to. That would make more sense.

Couldn't a feature be added to manually whitelist DLLs or to add approved certificates?

No, because that would defeat the whole purpose. The rogue process could whitelist itself. It's like all the viruses that respect themselves, the first thing they do is to "cut the power cable from the alarm" by killing all known antivirus processes.

Does that make sense?

PS. I'm not affiliated with Oracle.

[Lars Hupfeldt]

OpenText was chosen as the company SOCKS solution. Whether it is the best solution or not, I don't know. An exclusion list in OpenText would defeat the purpose, which is to make it work with VirtualBox. I would love to not have to use SOCKS, but I have to.

I don't see how adding approved certificates defeats the purpose. This would have to be done as Admin on the host. In fact my Windows host already has such a feature, but still I'm not able to make VirtualBox work.

I thought you were from Oracle, thank you for clarifying this. So still no response from Oracle :(

[Socratis]

Replying to larsh:

I don't see how adding approved certificates defeats the purpose. This would have to be done as Admin on the host.

If you can find a waterproof mechanism where a virus couldn't do the same, I'm all ears. A virus that has system access that is.

In fact my Windows host already has such a feature, but still I'm not able to make VirtualBox work.

I'm not sure which feature you're referring to, would you mind clarifying?

I thought you were from Oracle, thank you for clarifying this. So still no response from Oracle :(

Oracle or not, it doesn't matter. It's understanding the ifs and the whys that matters. And if you've done a little bit of operating system security, you'd give the same answer yourself. ;)

Now, mind you that the Oracle people have to secure the software while it being open source. That's a tough one, ask the Firefox guys. You can't simply go and say "if OpenText then allow". No. There's got to be a bulletproof mechanism in place (since Windows forgot about that little detail). And that mechanism has to be open and public. And that mechanism is called "proper signing". Or, another way is "don't mess with my process". Pick one...

[Lars Hupfeldt]

A virus with system access? In this case you have lost already!

Windows allows you to add certificates and CAs.

OpenText is signed, but not with a driver certificate. According to OpenText support, OpenText is not a driver, so should not have to be signed with a driver certificate.

[Socratis]

Replying to larsh:

A virus with system access? In this case you have lost already''

But that doesn't mean that you know about it. See my previous comment about guest access.

Windows allows you to add certificates and CAs.

So would a virus. If it's not a certified certificate server, all bets are off.

OpenText is signed, but not with a driver certificate. According to OpenText support, OpenText is not a driver, so should not have to be signed with a driver certificate.

Then that would leave only option 2 as a viable option. Do not mess with my process. Simple. If you want access to my own memory area, you'd better be signed.