VirtualBox E1000 Guest-to-Host Escape

Re:VirtualBox E1000 Guest-to-Host Escape by viraptor on Tuesday November 06, 2018 @08:54PM (#18396590)

I find that part really weird. These are two extremes - you can easily notify the vendor and give them a month (or whatever period you think is reasonable) to fix the issue if you're not interested in the bounty. Google was pretty successful with enforcing 3 months. VirtualBox may not be a production service where it really matters, but publishing a 0day makes for some stressful days for many ops.

[ Parent | on HN ]

Re:VirtualBox E1000 Guest-to-Host Escape by craftyguy on Tuesday November 06, 2018 @09:17PM (#18396676)

After reading the description of the exploit, it's not clear to me who is at fault. It almost seems like there are several bugs in the Intel E1000 driver, and not VirtualBox. But then again, the hypervisor should probably never allow a guest kernel to escape the VM.

If the issue actually lies with VirtualBox, VirtualBox is owned/maintained by Oracle, and based on other interactions I've seen with Oracle I wouldn't be surprised if others have submitted exploits to them before and they were ignored.

[ Parent | on HN ]

Re:VirtualBox E1000 Guest-to-Host Escape by niklasb on Tuesday November 06, 2018 @09:19PM (#18396685)

The bug is in the VirtualBox code that emulates an Intel E1000 device. There is no driver code involved.

[ Parent | on HN ]

Re:VirtualBox E1000 Guest-to-Host Escape by craftyguy on Tuesday November 06, 2018 @09:25PM (#18396704)

Thanks.

> There is no driver code involved.

Yea I see that step #1 in the 'exploit algo' is to remove the e1000, I missed that earlier:

> An attacker unloads e1000.ko loaded by default in Linux guests and loads the exploit's LKM.

[ Parent | on HN ]