Can't run or install, possible Oracle cert issues (#17524)

[Diggie]

---

[ModEdit; related ticket: #17524: Various VBox binaries use a SHA1-timestamped SHA2 signature]

---

This morning [2018-02-02] I found I could not start any VMs on a VirtualBox installation that has been working fine for months. Unfortunately I don't have a screencap of the error, but I believe it was related to VMM trust issues.

I tried to download and install 5.2.6 fresh (which uninstalled my existing copy, hence no screencap available), and installation fails. The log shows:

Code: Select all

DIFXAPP: ERROR:  Signature verification failed while checking integrity of driver package 'VBoxDrv.inf' ('C:\Program Files\Oracle\VirtualBox\drivers\vboxdrv\VBoxDrv.inf'). (Error code 0x800B0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.)
DIFXAPP: INFO:   Successfully removed '{D3E2F2BB-569F-46A2-836C-BDF30FF1EDF8}' from reference list of driver store entry ''
DIFXAPP: INFO:   RETURN: DriverPackageInstallW  (0x800B0100)
DIFXAPP: ERROR: encountered while installing driver package 'C:\Program Files\Oracle\VirtualBox\drivers\vboxdrv\VBoxDrv.inf'
DIFXAPP: ERROR: InstallDriverPackages failed with error 0x800B0100
DIFXAPP: RETURN: InstallDriverPackages() 2148204800 (0x800B0100)
CustomAction MsiInstallDrivers returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Action ended 7:40:19: InstallFinalize. Return value 3.

If I manually extract VBoxDrv.sys, Windows says of the digital signature for "Oracle America, Inc." with serial "12f0277e0f233b39f9419b06e8cde352", "The integrity of the certificate that signed this file cannot be guaranteed. The certificate may be corrupted or may have been altered". It chains back to a "Verisign" root through "Symantec Class 3 SHA256 Code Signing CA" and Windows seems happy enough with those.

Strangely, I notice the cert that signed the installer is for "Oracle Corporation" and has serial "5cf22fe92eaf604593c8d97addc473c1", and Windows seems fine with that one. I'm not sure why the SHA256 signature on the drivers is using a different certificate.

I don't receive the prompt to always trust software from Oracle that I sometimes saw on older installers.

Running Win 10, 1709, 16299.192. The installer I downloaded (VirtualBox-5.2.6-120293-Win.exe) has SHA265 da7bbcc9806a3f574f1faed5381c6e116b10a7bbb4779913d5446e49fe08fd7d.

[Diggie]

I cross referenced the certificate thumbprint with one on another system that still works, and I get 3b75816d15a6d8f4598e9cf5603f1839ee84d73d, which seems to be valid. I can also take VBoxDrv.sys from that working system and bring it over to the failing system and receive the same warning about the signing certificate's integrity.

So I'm not sure what has happened -- if it's a Windows Update or some other issue, but something overnight has caused my system to no longer like that "Oracle America, Inc." cert.

[Diggie]

I think I found the cause of this. Something set hardened WeakSha1ThirdPartyFlags. I've reset this and everything is working again - installer and VBox itself.

[mpack]

I'm not sure why that would make a difference. The VirtualBox installer for Windows Hosts has both sha1 and sha256 certs. Surely no amount of deprecation of sha1 would make it ignore the presence of an sha256 cert?

[Diggie]

Yes, you would think so, but I can assure you that's what caused it.

I can actually reproduce it with this:

Code: Select all

certutil -setreg chain\Default\WeakSha1ThirdPartyFlags 0x84400000

NB: you might want to -getreg first so you can restore what's there later, or use -delreg to clear the flags completely.

I believe most Win10 systems should have this now:

Code: Select all

certutil -setreg chain\Default\WeakSha1ThirdPartyFlags 0x80040000

Edit: So my system had additionally set CERT_CHAIN_DISABLE_TIMESTAMP_WEAK_FLAG, and the issue is therefore caused by the fact that the SHA256 digest is being timestamped by a SHA1 timestamp server certificate.

Someone should probably improve that. Symantec has a separate SHA256 timestamping resource, I just can't post it because the forum software prevents me posting URLs as a new user.

[socratis]

@Diggie
I din't see any mention about your Win10 host version, revision, build. Could you provide that info? Is that an Insider build? A recently updated installation?

[Diggie]

@socratis It's simply the lastest version they're pushing in the Stable channel, taken from WinVer.

See kb4056892. (Again, not being able to posts URLs is a PITA).

However, the OS version isn't the issue, merely the fact that there's a SHA1 timestamp on some of the SHA256 digests. Instead, the signing utility should use Symantec's SHA256 timestamp resource, which would solve the problem even under more aggressive SHA1 deprecation settings. To be clear, the settings I had on my box were more restrictive than Microsoft is currently setting.

[mpack]

Someone should probably improve that.

Now that you've pinned it down, sounds like it's time to raise a BugTracker ticket. That's the only way to be sure the devs hear about it.

[Diggie]

Done:
https://www.virtualbox.org/ticket/17524

[mpack]

Well done, that's a great ticket. Don't expect the devs to leap into action though, they no doubt have assignments to work on already, and it may be a while before they get around to scanning the latest tickets. But, I wouldn't be surprised to see something this simple fixed in the next couple of maintenance updates.

[Hansi]

This seems like a simple fix, any reason why it hasn't been addressed in 2 years?

[mpack]

Since this is a user discussion forum, and none of us are VirtualBox devs, the answer to that would be "no".

And in any case, I didn't recognize the problem then or now.

[Hansi]

Primary issue would be enterprise setups that prohibit SHA1 code signing cert usage for installed drivers unless by exception. Likely not a common concern but added comment to ticket too. Not sure how responsive the devs are on the ticket system.