[vbox-dev] Binary client with custom IFramebuffer with 6.1.38
klaus.espenlaub at oracle.com
Thu Oct 13 20:10:54 UTC 2022
sorry about the long delay... it's been unbelievably busy.
On 2022-09-14 18:12, Rūdolfs Bundulis wrote:
> 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