Rules for patching VirtualBox VBoxVMM.dll?

Discussions related to using VirtualBox on Windows hosts.
Post Reply
levitation
Posts: 9
Joined: 12. Jul 2018, 08:22

Rules for patching VirtualBox VBoxVMM.dll?

Post by levitation »

I need to modify a few bytes in VBoxVMM.dll. Unfortunately, VirtualBox refuses to start the VM with the modified dll.

My procedure was the following:
0. Closed VirtualBox and also killed VBoxSvc.exe
1. Modify the dll.
2. makecert -r -ss myPrivateCert1 -n "CN=My Company Inc." testCert1.cer
3. makecert -a sha256 -r -ss myPrivateCert256 -n "CN=My Company Inc." testCert256.cer
4. signtool sign /t sometimestampserver_url /s myPrivateCert1 VBoxVMM.dll
5. signtool sign /tr sometimestampserver_url /td sha256 /fd sha256 /as /s myPrivateCert256 VBoxVMM.dll
6. Add both of the generated certificates to Trusted Root CA-s.
7. Set the owner of the VBoxVMM.dll back to SYSTEM.

The timestamp server is timestamp digicert com but I cannot write it here exactly due to forum's security rules.

This procedure does not work even when I skip step 1, so that the updated DLL has only my self-signed certificates, but no other modifications.

I based my assumptions on the text found here: googleprojectzero dot blogspot dot com/2017/08/bypassing-virtualbox-process-hardening.html According to which I understood that it should be enough to sign the file with self-signed certificate, as long as it is added to Trusted Root CA and owned by SYSTEM.

What am I missing here? Is there any other tool or method for patching VirtualBox files (without rebuilding everything)?

The hardening log is attached to the post.

PS. I am not asking how to break the rules, but instead, what are the rules. Are they documented somewhere? I searched the forum, also rest of internet, and all I could guess is that maybe the dll needs to be signed somehow, but which options are acceptable exactly?
Attachments
VBoxHardening.zip
(11.06 KiB) Downloaded 7 times
andyp73
Volunteer
Posts: 1631
Joined: 25. May 2010, 23:48
Primary OS: Mac OS X other
VBox Version: PUEL
Guest OSses: Assorted Linux, Windows Server 2012, DOS, Windows 10, BIOS/UEFI emulation

Re: Rules for patching VirtualBox VBoxVMM.dll?

Post by andyp73 »

levitation wrote:I need to modify a few bytes in VBoxVMM.dll
If you would like to give some more details of what you are trying to achieve then we can perhaps give you some more guidance.

-Andy.
My crystal ball is currently broken. If you want assistance you are going to have to give me all of the necessary information.
Please don't ask me to do your homework for you, I have more than enough of my own things to do.
levitation
Posts: 9
Joined: 12. Jul 2018, 08:22

Re: Rules for patching VirtualBox VBoxVMM.dll?

Post by levitation »

My intention is modifying the bytes that store the CPU microcode revision number returned to VM.
mhanor
Volunteer
Posts: 321
Joined: 7. Oct 2009, 12:40
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: various

Re: Rules for patching VirtualBox VBoxVMM.dll?

Post by mhanor »

When you use a test certificate, you need to boot Windows in testsigning mode, for Windows to trust that certificate.
levitation
Posts: 9
Joined: 12. Jul 2018, 08:22

Re: Rules for patching VirtualBox VBoxVMM.dll?

Post by levitation »

Thanks for the suggestion!
Is it certain that VirtualBox will load the test-signed dll when testsigning is turned on?
I turned testsigning on, rebooted. Tried signing either with my self-generated certificates (sha1 and sha256), or alternatively, with a test signing certificate automatically generated by Visual Studio (a certificate which has previously worked for my self-made drivers' test signing successfully). In both cases the VM starting fails.
I added the -eku "1.3.6.1.5.5.7.3.3" parameter to my manually generated certificates, this did not help either.
I also added all the certificates to Trusted Publishers store, in addition to the Root store.
It looks like either I am doing something wrong with certificate generation or signing, or the test mode is not supported by VirtualBox?
Even when I disable driver signature enforcement in the host machine's boot screen, the VM start still fails. So I am afraid I am unnecessarily spending my time trying out various certificate and signature combinations...
Attachments
VBoxHardening.zip
(12.4 KiB) Downloaded 10 times
mhanor
Volunteer
Posts: 321
Joined: 7. Oct 2009, 12:40
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: various

Re: Rules for patching VirtualBox VBoxVMM.dll?

Post by mhanor »

I've tried it myself. I use a sha1 test certificate with a self-build VirtualBox OSE build. Both hardened and non-hardened builds work. I've just test signed the official VBoxVMM.dll, the VM process starts, but rejects the dll with this message "None of the 1 path(s) have a trust anchor." Why do you need this mod?

Your hardening log doesn't even mention VBoxVMM, something else is happening there.
levitation
Posts: 9
Joined: 12. Jul 2018, 08:22

Re: Rules for patching VirtualBox VBoxVMM.dll?

Post by levitation »

Thanks for trying the situation!
I am sorry, the last log file must have been overwritten before I managed to zip it. I am sending a new correct one where the error is visible (this is with just one possible certificate and signing mode I had used, I also used different certificates and signing modes, but the error was same).

The error you had "None of the 1 path(s) have a trust anchor" was also my original error message in the first try.
When I later enabled test signing and possibly did some of the other tricks mentioned in my previous post, the error message changed to:
"Not valid kernel code signature".

I do not understand, what do you mean by the phrase "both hardened and non-hardened builds work"? I mean, if you get an error launching the VM (as you said you do) then it does not work?

The goal of the patch is that I need to have proper microcode version visible in the VM. As a comparison, VMWare has no problem showing proper microcode data in the VM. I am okay fixing this constant manually, but I need to accomplish this at least somehow.
The VM will apply Spectre related kernel updates based on microcode version. The updates are necessary, since the machine is executing untrusted code which is entered by the random users.
I am a bit confused how far should I go with my explanations. Should I also explain why I need such a machine and what I am going to do with the rest of the time of my life? :)
Attachments
VBoxHardening.zip
(16.28 KiB) Downloaded 4 times
mhanor
Volunteer
Posts: 321
Joined: 7. Oct 2009, 12:40
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: various

Re: Rules for patching VirtualBox VBoxVMM.dll?

Post by mhanor »

Unfortunately, the microcode revision is not all that's required for spectre mitigation. Meltdown mitigation is a kernel only solution, so no microcode is required. Spectre mitigation requires microcode update for the host CPU and exposure of new CPU instructions to the guest, which will only happen if the VirtualBox developers do some work. The OS checks for the new CPU features to use, not for a particular microcode revision.
levitation
Posts: 9
Joined: 12. Jul 2018, 08:22

Re: Rules for patching VirtualBox VBoxVMM.dll?

Post by levitation »

Thanks for the clarification!

Do you know, is anybody working on the Spectre microcode compatibility update for VirtualBox? When could it be ready for testing?

Also, it still would be interesting to know - is there any way to replace VirtualBox dll-s with custom signed ones? Is the only way forward signing with kernel code signing certificate issued from global authorities? Or is test signing somehow available after all?
andyp73
Volunteer
Posts: 1631
Joined: 25. May 2010, 23:48
Primary OS: Mac OS X other
VBox Version: PUEL
Guest OSses: Assorted Linux, Windows Server 2012, DOS, Windows 10, BIOS/UEFI emulation

Re: Rules for patching VirtualBox VBoxVMM.dll?

Post by andyp73 »

Have you tried looking at the --spec-ctrl on|off option for the "VBoxManage --modifyvm" command. The documentation states: "this setting enables/disables exposing speculation control interfaces to the guest, provided they are available on the host. Depending on the host CPU and workload, enabling speculation control may significantly reduce performance."

-Andy.
My crystal ball is currently broken. If you want assistance you are going to have to give me all of the necessary information.
Please don't ask me to do your homework for you, I have more than enough of my own things to do.
levitation
Posts: 9
Joined: 12. Jul 2018, 08:22

Re: Rules for patching VirtualBox VBoxVMM.dll?

Post by levitation »

Thanks. I was not aware of this option. I turned it on.
The results are:

In Windows 10 VM both of the Spectre mitigations are successfully enabled (after turning on the above mentioned option).

Unfortunately, in Ubuntu VM nothing has changed, installed all updates and rebooted, no improvement.

And in CentOS VM the command
grep ' spec_ctrl ' /proc/cpuinfo
yields non-empty result (as a comparison, without enabling the option the result was empty). So this is an improvement.

Still, the the Spectre mitigations are not enabled in CentOS.
As a comparison, in VMWare the CentOS VM is able to enable the Spectre mitigations, so it definitely should be possible with CentOS VM.

Partial output from
sh spectre-meltdown-checker.sh in VirtualBox CentOS VM:

CVE-2018-3640 [rogue system register read] aka 'Variant 3a'
* CPU microcode mitigates the vulnerability: NO
> STATUS: VULNERABLE (an up-to-date CPU microcode is needed to mitigate this vulnerability)

> How to fix: The microcode of your CPU needs to be upgraded to mitigate this vulnerability. This is usually done at boot time by your kernel (the upgrade is not persistent across reboots which is why it's done at each boot). If you're using a distro, make sure you are up to date, as microcode updates are usually shipped alongside with the distro kernel. Availability of a microcode update for you CPU model depends on your CPU vendor. You can usually find out online if a microcode update is available for your CPU by searching for your CPUID (indicated in the Hardware Check section). The microcode update is enough, there is no additional OS, kernel or software change needed.

CVE-2018-3639 [speculative store bypass] aka 'Variant 4'
* Mitigated according to the /sys interface: NO (Vulnerable)
* Kernel supports speculation store bypass: YES (found in /proc/self/status)
> STATUS: VULNERABLE (Your CPU doesn't support SSBD)


VMWare CentOS VM's output is attached as an image file.

Update: under VMWare the Ubuntu also applies the patches correctly, so "spectre-meltdown-checker.sh" prints "NOT VULNERABLE". Though
"grep ' spec_ctrl ' /proc/cpuinfo" yields empty result even there.

Update 2: It looks like "ssbd" CPU flag is one of the flags that is missing in VirtualBox VM, but is present in VMWare's.
Looking at spectre-meltdown-checker.sh I would assume that setting this flag enables both of the missing Spectre mitigations.

So then only one question remains - how to turn on "ssbd" flag in VirtualBox VM-s?
Maybe this is also relevant: https://lwn.net/Articles/755193/
Looks like spec_ctrl and ssbd should both be enabled.

When Googleing
ssbd site:www.virtualbox.org
The result is empty.
Googleing
spec_ctrl site:www.virtualbox.org
yields results.
So I would conclude that currently VirtualBox is not aware of the "ssbd" CPU feature flag. Are there any plans regarding that?
Attachments
VMWare CentOS Spectre mitigation OK.png
VMWare CentOS Spectre mitigation OK.png (10.95 KiB) Viewed 2389 times
levitation
Posts: 9
Joined: 12. Jul 2018, 08:22

Re: Rules for patching VirtualBox VBoxVMM.dll?

Post by levitation »

Just for the clarification: my problem is not solved since I am not using Windows 10 guest (for which the problem did solve), but instead mainly CentOS guest, and sometimes also Ubuntu guest.
mhanor
Volunteer
Posts: 321
Joined: 7. Oct 2009, 12:40
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: various

Re: Rules for patching VirtualBox VBoxVMM.dll?

Post by mhanor »

You need to educate yourself more on these types of vulnerabilities. The running software components (OS, user applications) must implement various mitigation techniques, if the situation requires it (e.g. the software is using encryption keys, that are supposed to be private). In your case, that's the guest OS/guest user applications. It's not enough for VirtualBox to expose the new CPU instructions. What secrets are you holding on your guest, that you need this so bad?
levitation
Posts: 9
Joined: 12. Jul 2018, 08:22

Re: Rules for patching VirtualBox VBoxVMM.dll?

Post by levitation »

As I already explained, the guest is executing random untrusted code (in user mode). I do not wish that this user mode code is able to escalate itself to root level or even further to the host level.
I am really confused by your last question... Of course the security hole needs to be patched and mitigated! Everybody is doing that right now.
The Spectre bug needs to be mitigated and guest's CentOS of course does support those mitigations - I just demostrated that with a screenshot from a CentOS guest running inside VMWare, or was this not sufficient to conclude the OS support? (I later produced a similar screenshot also in Ubuntu guest under VMWare).
The problem is that VirtualBox is not exposing SSBD flag (and of course, potentially also the relevant instructions, I cannot confirm the latter). So it looks like it is now enough that VirtulBox exposes these instructions and the guest OS will be much more fine afterwards.
Did I misinterpret something here?
Last edited by levitation on 18. Jul 2018, 00:41, edited 1 time in total.
mhanor
Volunteer
Posts: 321
Joined: 7. Oct 2009, 12:40
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: various

Re: Rules for patching VirtualBox VBoxVMM.dll?

Post by mhanor »

These vulnerabilities are not escalation vulnerabilities. It's obvious you haven't really read on them, if you're assume it's able to do privilege escalation. They are disclosure of information type of vulnerabilities. Regarding SSBD, it's recent news, you'll have to wait for VirtualBox devs to resolve that. Before they do that, have you checked if is your host is patched for SSBD? For example, Gigabyte has patched only a few of older motherboards for this vulnerability.
Post Reply