4 ms·
> if I spin up a VM with networking disabled I feel pretty confident I can run anything safely, even malware is not going to escape. You are putting too much f
by fleventynine 3y ago
> if I spin up a VM with networking disabled I feel pretty confident I can run anything safely, even malware is not going to escape.
You are putting too much faith in your VM monitor to keep you safe. There's a lot of attack surface in (for example) QEMU peripherals, and there's plenty of examples of VM escape [1]. CrosVM is probably the only publicly available VMM I'd be willing to trust, and even then I'd be nervous running state-sponsored malware on a machine with important data.
[1] https://www.google.com/search?q=qemu+vm+escape https://www.google.com/search?q=qemu+vm+escape
- monocasa 3y agoI'd probably trust firecracker too since it was designed specifically to avoid qemu's attack surface and runs in production for Amazon.
- bonzini 3y agoWhile QEMU uses C, which is not great, it has on its side 15+ years of hardening by the KVM developers. The problem with QEMU is not so much insecurity, it's that it contains the kitchen sink. However, most of the exploits you'll find in QEMU are against configurations that are never used in real world virtualization scenarios where guests are untrusted. You can recognize them because hardware not commonly used with untrusted guests does not get a CVE. For a while, slirp was the remaining major issue because it was used way beyond the original intention. But now it's been tamed and there's also passt, a much higher performance and much more secure implementation of user-mode networking.
- ungamedplayer 3y ago> You can recognize them because hardware not commonly used with untrusted guests does not get a CVE. This is not true. Even non default configuration of any software or hardware that contains a security vulnerability can get a CVE. It has in the past and will again in the future. Source: I have assigned over 2000 cves for the kernel.
- bonzini 3y agoYes, and the policy of QEMU is to not assign CVEs for bugs that would generally be hit only when QEMU is used as a development platform, as opposed to using it to offer virtualization services. https://www.qemu.org/contribute/security-process/ https://www.qemu.org/contribute/security-process/ We are colleagues by the way. :)
- worthless-trash 3y ago> We are colleagues by the way. :) I'm aware, I see you comment here regularly. QEMU doesn't have to assign CVE's but any other CNA can. I do not believe that its good security or even good practice to negotiate out of exploitable flaws. Its a dis-service to users. I don't have enough skin in the game to change upstream QEMU's mind on this, systems in exploitable configurations are just as exploitable with or without a CVE assigned. People with exploitable configurations now just can't find out there is a problem.
- surajrmal 3y agoLuckily android is using crosvm