[vbox-dev] Binary client with custom IFramebuffer with 6.1.38

Klaus Espenlaub klaus.espenlaub at oracle.com
Thu Oct 13 20:10:54 UTC 2022

Hi Rūdolfs,

sorry about the long delay... it's been unbelievably busy.

On 2022-09-14 18:12, Rūdolfs Bundulis wrote:
> Hi,
> I had a piece of software using VirtualBox 5.2 that was able to start
> a VM and inject itself via the IFramebuffer interface and capture the
> displayed bitmap. Due to hardening (even though it was so long ago
> that now I am not sure if 5.2 had hardening) I was chowning the
> binaries with root and adding the sticky bit and that seemed to work.

The fundamental approach should still work. The hardening rules are the 
same as before.

> Today I tried to port this to 6.1.38 but sadly when doing the chown +
> setuid by root it does not work - I seem to be unable to obtain the
> VirtualBox API (w/o the chown + setuid thing I get the expected error:
> "VirtualBox kernel driver not accessible, permission problem.
> Re-install VirtualBox. If you are building it yourself, you  should
> make sure it installed correctly and that the setuid bit is set on the
> executables calling VMR3Create."
> When doing the setuid + chown thing I notice that the VBoxSVC is now
> started as root, the /tmp/.vbox-root-ipc seems to be there, what else
> should I look at to understand what is failing? Does the root setuid +
> chown combo somehow disable the client validation by the runtime or is
> this expected and only signed Oracle clients will work? Since sudo
> VirtualBox works fine and can start a machien. Is such a setup even
> possbile with VirtualBox 6.1.38? Or is my only option here building
> w/o hardening?

It should work - but you should've always dropped the root permissions 
before talking to the API. Which also should have been the same as long 
time ago. Being a VM process is pretty tricky, and requires doing 
everything at the right time and with the necessary permissions.

I wonder if you should actually rethink your approach and go for running 
the VM in headless mode, and let your piece of code 'attach' to the 
console. This has been introduced in VirtualBox 5.1 already, and it 
means that the UI 'showing' the screen content is a separate process, 
which doesn't need to be hardened.

Your code should be rather similar, and while there's no simple sample 
code (the API documentation generally covers it, but probably the 
information is too spread out to get you going quickly) it should be 
possible to find the relevant code in the VirtualBoxVM code relatively 
easily, because it attaches to the headless VM if you specify the 
--separate parameter. There can be in principle several attached UI's, 
which can come handy in your case, where I assume your custom piece of 
code would process the screen content only. You would still need a 
proper UI, for getting input events etc etc. for the VM.


More information about the vbox-dev mailing list