<div dir="ltr">Hi,<div dir="ltr"><div class="im"><span style="font-family:arial,sans-serif;font-size:13px"></span><div style="font-family:arial,sans-serif;font-size:13px"><br>We
are graduate students studying Computer Science at Stony Brook
University. We were wondering what is the security concern for
Virtual Box binaries on Linux to require root privilege.</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div></div><div style="font-family:arial,sans-serif;font-size:13px">We
know that /dev/vboxdrv is owned by root and the permissions on that
device are such that only root can open it. However, we are interested
in the underlying security concern to restrict access of this device to
root. We analyzed the ioctls issued by the userspace VirtualBox binaries
to this device. These ioctls seem to be changing the state/memory for a
specific guest VM. Thus, there may not be any concerns of an attacker
exploiting these ioctls to change the state of the host or other
processes on the host as long as the ioctl requests can be
authenticated?</div><div class="im">
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">There
seems to exist a cookie based authentication mechanism for these
requests. However, static cookie values are used - which may explain the
need to restrict these requests to be issued by only root to avoid an
attacker messing with a running VM.</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div></div><div style="font-family:arial,sans-serif;font-size:13px">Moreover,
the different setuid-to-root VirtualBox binaries don't seem to be able
to attach to a running VM. So, an attacker cannot use that interface to
connect to an already running VM. </div><div class="im">
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">If
the /dev/vboxdrv is opened for access to all, a possible attack can be
that the attacker will guess the pSession pointer and use that as an
argument in pReq to send fake ioctl requests for other VMs. However, if
the cookies are randomized and are hard to guess, this attack may be
mitigated by the cookie based authentication or even by adding a file
descriptor or process based authentication.</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">We
are interested in this discussion because we have a paper accepted to
EuroSys '14 that shows how to obviate the need for setuid binaries on
Linux. As a part of continuing this effort for completeness, we are
currently investigating the need of VirtualBox for setuid-to-root and
find ways in which this need can be eliminated.<br>
</div><div style="font-family:arial,sans-serif;font-size:13px"><div><br></div><div>Please let us know if we are missing something or is our understanding correct?</div></div><div style="font-family:arial,sans-serif;font-size:13px">
Thanks in advance for your help and comments.</div><div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">Regards,</div></div><div style="font-family:arial,sans-serif;font-size:13px">
Kavita Agarwal</div><div style="font-family:arial,sans-serif;font-size:13px">CS Graduate Student</div><div style="font-family:arial,sans-serif;font-size:13px">Stony Brook University</div></div><div><div dir="ltr"><br></div>
</div>
</div>