WARNING! WARNING! WARNING!

while security is important so is availability/uptime/downtime.

upgrades especially of kernel and virtualbox need to be handled with SPECIAL care.

Because a lot can go wrong.

I would go so far and NOT recommend upgrades of production systems.

  1. Rather get a new server(instance)
  2. reinstall from scratch with latest kernel/virtualbox
  3. move the VMs to the new server
    • to move VMs in Virtualbox works like this: (you will need a lot of harddisk space)
      1. shutdown VM
      2. completely clone the VM_ into a new instance so you only have two files to move *.vbox and *.vdi
      3. alternatively clone into a mounted directory of the new server (change settings of „main vm directory“)
      4. so you can transfer and clone at the same time
      5. simply „doubleclick“ the *.vbox to register transfered vm on new server
    • this way you can inform your customers of the maintenance and lose no data and have little downtime (as long as it takes to clone and transfer the vms)

atleast: make sure nobody is working at the server at the moment of upgrade or download a backup of all VMs prior to updating the host system – it is very risky and you risk that the server might not be available for some days.

security guide:

https://www.virtualbox.org/manual/ch13.html

keep your software updated!

this is what we are going to do:

upgrading virtualbox: also change the virtual nic!

while you are on it: change all virtual network cards to something that is not Intel PRO/1000 MT Desktop (82540EM) (m1000), like paravirtualized (needs the vbox guest drivers!)

Host OS: any, the bug is in a shared code base.

Guest OS: any.

VM configuration: default (the only requirement is that a network card is Intel PRO/1000 MT Desktop (82540EM) and a mode is NAT).

How to protect yourself

Until the patched VirtualBox build is out you can change the network card of your virtual machines to PCnet (either of two) or to Paravirtualized Network. If you can’t, change the mode from NAT to another one. The former way is more secure.

Introduction

A default VirtualBox virtual network device is Intel PRO/1000 MT Desktop (82540EM) and the default network mode is NAT. We will refer to it as E1000.

The E1000 has a vulnerability allowing an attacker with root/administrator privileges in a guest to escape to a host ring3. Then the attacker can use existing techniques to escalate privileges to ring 0 via /dev/vboxdrv.

Vulnerability Details

E1000 101

To send network packets a guest does what a common PC does: it configures a network card and supplies network packets to it. Packets are of data link layer frames and of other, more high level headers. Packets supplied to the adaptor are wrapped in Tx descriptors (Tx means transmit). The Tx descriptor is data structure described in the 82540EM datasheet (317453006EN.PDF, Revision 4.0). It stores such metainformation as packet size, VLAN tag, TCP/IP segmentation enabled flags and so on.

The 82540EM datasheet provides for three Tx descriptor types: legacy, context, data. Legacy is deprecated I believe. The other two are used together. The only thing we care of is that context descriptors set the maximum packet size and switch TCP/IP segmentation, and that data descriptors hold physical addresses of network packets and their sizes. The data descriptor’s packet size must be lesser than the context descriptor’s maximum packet size. Usually context descriptors are supplied to the network card before data descriptors.

To supply Tx descriptors to the network card a guest writes them to Tx Ring. This is a ring buffer residing in physical memory at a predefined address. When all descriptors are written down to Tx Ring the guest updates E1000 MMIO TDT register (Transmit Descriptor Tail) to tell the host there are new descriptors to handle.

src: https://github.com/MorteNoir1/virtualbox_e1000_0day

upgrading virtualbox:

WARNING! While it is a good idea to keep all software on your system as up to date as possible – updates might actually break functionality!

hence:

1. BACKUP your System (do a snapshot)

2. UPDATE/UPGRADE

3. test functionality – problems? restore backup

4. you might also need to upgrade the VirtualBox Additions inside of every VM.

i would recommend using a test-server, move one „in production“ vm to the test-server… run it with the latest virtualbox version and if it runs well you might can also upgrade the production server.

# shutdown / supsend all running virtual machines
vboxmanage list runningvms | sed -r 's/.*\{(.*)\}/\1/' | xargs -L1 -I {} VBoxManage controlvm {} acpipowerbutton

# what version is installed?
vboxmanage --version
5.2.20r125813

# via yum it does not seem to work while vbox service is running
yum update
Total download size: 76 M
Is this ok [y/d/N]: y
Downloading packages:
No Presto metadata available for virtualbox
VirtualBox-5.2-5.2.22_126460_el7-1.x86_64.rpm                                                                                                                                 |  76 MB  00:00:01     
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction

---> A copy of VirtualBox is currently running. <---
Please close it and try again.

Please note that it can take up to ten seconds for VirtualBox (in particular
the VBoxSVC daemon) to finish running.
error: %pre(VirtualBox-5.2-5.2.22_126460_el7-1.x86_64) scriptlet failed, exit status 1
Error in PREIN scriptlet in rpm package VirtualBox-5.2-5.2.22_126460_el7-1.x86_64
  Verifying  : VirtualBox-5.2-5.2.22_126460_el7-1.x86_64                                                                                                                                         1/2 
VirtualBox-5.2-5.2.20_125813_el7-1.x86_64 was supposed to be removed but is not!
  Verifying  : VirtualBox-5.2-5.2.20_125813_el7-1.x86_64                                                                                                                                         2/2 

Failed:
  VirtualBox-5.2.x86_64 0:5.2.20_125813_el7-1                                                       VirtualBox-5.2.x86_64 0:5.2.22_126460_el7-1                                                      

Complete!

service_list_all |grep vbox
vboxautostart-service.service                 enabled 
vboxballoonctrl-service.service               enabled 
vboxdrv.service                               enabled 
vboxweb-service.service                       enabled 
[root@server user]# systemctl status vboxdrv.service 
● vboxdrv.service - VirtualBox Linux kernel module
   Loaded: loaded (/usr/lib/virtualbox/vboxdrv.sh; enabled; vendor preset: disabled)
   Active: active (exited) since Tue 2018-11-06 11:15:23 CET; 1 weeks 3 days ago
    Tasks: 0

Nov 06 11:15:21 domain.com systemd[1]: Starting VirtualBox Linux kernel module...
Nov 06 11:15:22 domain.com vboxdrv.sh[961]: vboxdrv.sh: Starting VirtualBox services.
Nov 06 11:15:23 domain.com systemd[1]: Started VirtualBox Linux kernel module.

systemctl stop vboxdrv.service

# still no luck with the upgrade
ps uax|grep VBox
root      1079  0.0  0.0      0     0 ?        I<   Nov06   0:00 [iprt-VBoxWQueue]
root      1080  0.0  0.0      0     0 ?        S    Nov06   0:00 [iprt-VBoxTscThr]
root      3122  0.1  0.0 286000 10520 ?        S    Nov06  15:08 /usr/lib/virtualbox/VBoxXPCOMIPCD
root      3210  0.2  0.5 1440392 93880 ?       Sl   Nov06  43:36 /usr/lib/virtualbox/VBoxSVC --auto-shutdown
user      3307  0.2  0.0 212268 10572 ?        S    Nov06  35:33 /usr/lib/virtualbox/VBoxXPCOMIPCD
user      3313  0.4  0.3 1167984 53588 ?       Sl   Nov06  66:00 /usr/lib/virtualbox/VBoxSVC --auto-shutdown
root      9425  0.0  0.0 112720  2328 pts/0    S+   17:23   0:00 grep --color VBox

# it simply took a while for VBoxSVC to quit
# otherwise i would recommend to kill it
killall VBoxSVC
# now the update works

vboxmanage --version
5.2.22r126460

# now you probably should restart the server
# it should be up to date
systemctl status vboxdrv.service 
● vboxdrv.service - VirtualBox Linux kernel module
   Loaded: loaded (/usr/lib/virtualbox/vboxdrv.sh; enabled; vendor preset: disabled)
   Active: active (exited) since Fri 2018-11-16 17:31:54 CET; 2 days ago
  Process: 990 ExecStart=/usr/lib/virtualbox/vboxdrv.sh start (code=exited, status=0/SUCCESS)
    Tasks: 0

Nov 16 17:31:50 domain.com systemd[1]: Starting VirtualBox Linux kernel module...
Nov 16 17:31:50 domain.com vboxdrv.sh[990]: vboxdrv.sh: Starting VirtualBox services.
Nov 16 17:31:54 domain.com systemd[1]: Started VirtualBox Linux kernel module.

lsmod|grep vbox
vboxpci                28672  0 
vboxnetadp             28672  0 
vboxnetflt             32768  0 
vboxdrv               507904  6 vboxpci,vboxnetadp,vboxnetflt

# you can try to rerun driver / service installation 
/usr/sbin/vboxconfig
/usr/lib/virtualbox/vboxdrv.sh setup

dmesg|grep vbox
[ 10.377923] vboxdrv: loading out-of-tree module taints kernel.
[ 10.382934] vboxdrv: Found 8 processor cores
[ 10.399281] vboxdrv: TSC mode is Invariant, tentative frequency 3400002896 Hz
[ 10.399381] vboxdrv: Successfully loaded version 5.2.22 (interface 0x00290001)
[ 11.385837] vboxpci: IOMMU not found (not registered)
[ 23.915438] vboxdrv: 0000000087c0612e VMMR0.r0
[ 24.215703] vboxdrv: 0000000060a2625a VBoxDDR0.r0
[ 555.565028] vboxdrv: 0000000087c0612e VMMR0.r0
[ 555.644683] vboxdrv: 0000000060a2625a VBoxDDR0.r0

escaping virtualbox?

„While VirtualBox is a popular general-purpose hypervisor, it is more commonly used for desktop virtualization. Compared to other products, VirtualBox has more extensive and reliable support for exotic or rare guest operating systems, such as OS/2 and Haiku.

Support for the VirtualBox guest driver is also being integrated into the Linux kernel, as of version 4.16. Work on mainlining the shared folder driver is also underway, though this is not anticipated to be ready in time—it is expected to be added in the merge window for kernel 4.17. The next step for Red Hat’s Hans de Goede is landing the „vboxsf“ driver for VirtualBox guest shared folder support. The shared folder driver depends upon vboxguest and the patches for review are now on the mailing list, but likely will be too late for getting into Linux 4.16.

For server and cloud operations, hypervisors such as KVM and VMware are more common, as are container apps such as Docker.“

https://www.techrepublic.com/article/10-new-vm-escape-vulnerabilities-discovered-in-virtualbox/

xen and quemu guest escape thanks to virtual floppy drivers

„A critical vulnerability called Venom (Virtualized Environment Neglected Operations Manipulation) has been discovered by Jason Geffner at the security firm CrowdStrike. The vulnerability is in a specific component in the open source virtualization package QEMU (which is also incorporated in other virtualization software such as Xen and KVM). Venom is a „VM escape“ vulnerability that renders the host platform, all other VMs operating on the host platform, and any device operating on the host platform’s network potentially vulnerable.

In comparison to other VM escape vulnerabilities, the vector used in Venom is used in default configurations, is not limited to a single virtualization platform, and allows for direct arbitrary code execution, according to CrowdStrike. The particularly vexing aspect is that the flaw exists in the virtual floppy disk controller (FDC) code in QEMU, which was added in 2004. While peripherally important for the time, modern production environments likely rarely utilize virtual floppy disk support.

According to Petr Matousek at Red Hat, „This flaw arises because of an unrestricted indexed write access to the fixed size FIFO memory buffer that FDC emulation layer uses to store commands and their parameters.“ Some commands in QEMU’s virtual FDC fail to reset the index in a timely manner, or even at all — in which case, further writes made to the FDC can become out-of-bounds. As the attacker has full control over the stored values and nearly full control of the write length, this can be exploited to allow arbitrary commands to be executed from inside the host virtualization process.“ (src)

links:

https://www.virtualbox.org/sdkref/

VirtualBox 6.0 Beta for testing!

Please do NOT use this VirtualBox Beta release on production machines!
A VirtualBox Beta release should be considered a bleeding-edge release
meant for early evaluation and testing purposes.

You can download the binaries here:

http://download.virtualbox.org/virtualbox/6.0.0_BETA2

Please do NOT open bug reports at our public bugtracker but use our
VirtualBox Beta Feedback forum at

https://forums.virtualbox.org/viewforum.php?f=15

to report any problems with the Beta. Please concentrate on reporting
regressions since VirtualBox 5.2!

Version 6.0 will be a new major release. Please see the forum at

https://forums.virtualbox.org/viewtopic.php?f=15&t=90315

for an incomplete list of changes.

Thanks for your help!
Michael

src: http://www.tuxmachines.org/node/117508

 

tweets:

security researcher niklas:

 

admin