VirtualBox 5.0 on Windows

[sarmaa]

I was running VB 4.3.1? on a Windows 7.0 host. I updated it to VB 4.3.3. and even though the update did not generate any errors, I could not start the VM. I saw that VB was showing a 5.0 version on the web page. So, I downloaded and installed that hoping the previous error would be fixed. However still the same error. The GUI shows

Failed to open a session for the virtual machine Centos.

The virtual machine 'Centos' has terminated unexpectedly during startup with exit code -1073741819 (0xc0000005). More details may be available in 'C:\Users\sarmaa\VirtualBox VMs\Centos\Logs\VBoxStartup.log'.

Result Code: E_FAIL (0x80004005)
Component: MachineWrap
Interface: IMachine {f30138d4-e5ea-4b3a-8858-a059de4c93fd}



The following are the last few lines from the VBoxStartup.log file

1d5c.25e0: supR3HardenedMonitor_LdrLoadDll: pName=C:\windows\system32\privman64.dll (Input=privman64.dll, rcNtResolve=0xc0150008) *pfFlags=0xffffffff pwszSearchPath=0000000000000000:<flags> [calling]
1d5c.25e0: supR3HardenedScreenImage/NtCreateSection: cache hit (VINF_SUCCESS) on \Device\HarddiskVolume1\Windows\System32\privman64.dll [lacks WinVerifyTrust]
1d5c.25e0: supR3HardenedDllNotificationCallback: load 0000000180000000 LB 0x0001f000 C:\windows\system32\privman64.dll [fFlags=0x0]
1d5c.25e0: supR3HardenedScreenImage/LdrLoadDll: cache hit (VINF_SUCCESS) on \Device\HarddiskVolume1\Windows\System32\privman64.dll [lacks WinVerifyTrust]
22dc.568: supR3HardNtChildWaitFor[2]: Quitting: ExitCode=0xc0000005 (rcNtWait=0x0, rcNt1=0x0, rcNt2=0x103, rcNt3=0x103, 179 ms, the end);
2310.15fc: supR3HardNtChildWaitFor[1]: Quitting: ExitCode=0xc0000005 (rcNtWait=0x0, rcNt1=0x0, rcNt2=0x103, rcNt3=0x103, 851 ms, the end);

Any help would be appreciated. Thanks in advance.

[Perryg]

BeyondTrust Software ?

Looks like it is not signed. If not the right software then you need to find out what is using this and remove it.

[MikeSchwartz]

I've had the same problem with BeyondTrust, since VirtualBox 4.3.14. (I've posted in some of the 'hardening' threads.)

As far as I can tell, the privman64.dll file is properly signed. I've attached a screenshot showing "This digital signature is OK." If there's a better, or more appropriate, way to check the status of the digital signature, please let me know.

Thanks!

[Perryg]

@ MikeSchwartz,

Click on the view certificate and see if the signing is still valid.

[MikeSchwartz]

The cert was only valid until 11/29/2011. But I hope that's not what's causing the problem. The file was signed on April 14, 2011, so the cert was valid at the time of signing.

[Perryg]

Well the cert is not valid. Have you looked to see if there was an up to date version? Anyway this seems to be the issue and only beyond trust can answer that question for you.

[MikeSchwartz]

I don't believe the cert's expiration date should be the issue. The code was timestamped, and the cert was still valid at the time the code was timestamped.

Here are four references that state that code should continue to be trusted after the expiry date as long as the cert was valid at the time of the timestamp:

From Microsoft's Code Signing Best Practices (doc file, Google cache):

Certificates normally expire after a period of time, such as one year. However, software is typically designed to operate for many years. If the certificate that was used to sign the code expires, the signature cannot be validated and the software might not install or run. To avoid this issue, Microsoft recommends that software publishers timestamp their digital signatures.

A timestamp is an assertion from a trusted source, called a timestamp authority (TSA), that the digital signature’s signed hash was in existence when the timestamp was issued. If the signing certificate was valid at that time, Windows considers the signature to be valid even if the certificate has since expired. If a signature is not timestamped, when the certificate used to sign the software expires, the signature simply becomes invalid.

From Thawte:

Is timestamped code valid after a Code Signing Certificate expires?

Thawte Code Signing for Microsoft Authenticode (Multi-Purpose) allows you to timestamp your signed code. Timestamping ensures that code will not expire when the certificate expires because the browser validates the timestamp. If you use the timestamping service when signing code, a hash of your code is sent to the timestamp server to record a timestamp for your code. A user’s software can distinguish between code signed with an expired certificate that should not be trusted and code that was signed with a Certificate that was valid at the time the code was signed but which has subsequently expired.

From Symantec:

How long does a digital signature last?

Every code signing certificate is purchased with a specific validity period. The digital certificate can be used to sign code as frequently as needed during that validity period. When the digital certificate expires, all digital signatures that depend on that digital certificate expire also unless the signature includes a timestamp. A timestamp option shows when code was signed, allowing customers to verify that the code signing certificate was valid at the time of the digital signature.

From Comodo:

How long can I use my code signing certificate?

Code signing certificates are valid for between one to three years depending on your purchase choice. Providing you take advantage of the time-stamping option, all code that you signed before certificate expiry will continue to be trusted even after the certificate has expired.

[Perryg]

Very well. I will leave you to your investigations.

[MikeSchwartz]

Unfortunately, I'm afraid I don't know where to go next. It appears that VirtualBox (or Windows?) is treating this DLL as untrusted when, as far as I can tell, there's nothing wrong with it, and it should be trusted. Every tool I use says that it's fine, at least on the surface:

• Explorer says "This digital signature is OK"
• Signtool.exe says "Successfully verified"
• Sigcheck.exe says "Verified: Signed"
• Process Explorer says "Verified"

I'd love to be able to narrow down where the problem is. Is it Windows that's rejecting the DLL? Or is it VirtualBox? And what's the reason? Is it the expiration date of the signing cert as we discussed above? Or is it some other reason? Do you know of any way to get more details about the exact reason why the DLL is coming back untrusted?

Thanks,
Mike.

[Perryg]

Well if this were mine I would test but uninstalling beyond trust reboot and see if it all comes together.

[MikeSchwartz]

If I uninstall BeyondTrust, the problem goes away. Which is great... But removing BeyondTrust is really only viable as a troubleshooting step, as my company includes BeyondTrust as a standard component of our desktop environment. I've been telling our users to work around the issue by either using VirtualBox 4.3.12, or by purchasing VMware Workstation.

The problem only appeared when VirtualBox added the security hardening. And it still seems to me that VirtualBox is incorrectly identifying BeyondTrust's privman64.dll as being untrustworthy. I know in those early releases after the hardening (4.3.16, 4.3.18, etc) the VirtualBox devs were quickly resolving incompatibility issues with major antivirus products. I'm not sure what the problems or fixes were for those products, but I keep hoping they'll be able to come up with a similar solution for BeyondTrust.

[mpack]

The fixes involved preventing false positives and crashes. You don't appear to have a false positive or a crash.

If you think that an expired certification should still be considered valid then perhaps you need to raise that in a BugTracker ticket, and link to this discussion.

[D3]

I'm seeing the same error. Sometimes after I reboot my Windows 7 system AND have network adapter disabled in Vbox it will allow the guest to start. Most times it still fails.