So on desktop, 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.
What's the current state of the art for Android virtualization? Let's assume we're talking about the newest Pixel and newest Android version. Is there any way to safely run malware or the Facebook app in some sort of air-gapped container and throw it away when you're done?
> 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.
While 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.
> 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.
Yes, 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.
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.
The question is whether something is exploitable or just a crash. It is also a disservice to user to worry them about having to do an immediate update and evacuation of all hosts because of an out of bounds access in Gravis Ultrasound emulation.
Would any crash in GCC be a vulnerability because compilers are fed untrusted source code? Perhaps, but in practice godbolt.org is going to be the only case in which you care.
Crashes are classifed as a denial of service, which is CVE. Imagine how mad any cloud host would be if they found you could crash the host from the guest.
> Would any crash in GCC be a vulnerability because compilers are fed untrusted
> source code? Perhaps, but in practice godbolt.org is going to be the only
> case in which you care.
"Untrusted" is one those other fine lines that makes assigning and rating difficult and not something that is taken lightly. Compiling software as a user with additional capabilities, could escalate an attackers position assuming they can inject code into the tree to be built. It would be easier to abuse 'make' to execute code, however this is different than the qemu use case.
The QMEU "development" case could (and likely is) someones regular runtime use case. I dont see a clean way for the qmeu team to communicate this, and even if they did, privesc is privsec. Until we as an industry have a clear definition of what we will and wont "support" and users are familiar with the expectations, we're stuck with the hand we've been dealt.
Hopefully that all makes sense, none of it is said to antagonise or draw hate.
Crashing the host kernel is DoS. Crashing QEMU from the guest is bad because a use-after-free could be a possible avenue for privesc. But if an assertion failure can be triggered from the guest kernel, in the end it's just another way for a virtual machine to terminate itself. It sucks but it is not security sensitive.
> Is there any way to safely run malware or the Facebook app in some sort of air-gapped container and throw it away when you're done?
User profiles can be used in this exact way. Guest user if you intend to install+wipe it right away (though this will prove cumbersome eventually due to having to reinstall the app every time, etc). There is a significant isolation benefit to them, though not currently virtualized. With the isolation can come usability issues. Like transferring files from one profile to another.
They can very slow however (slow to load+setup, and switch between, I mean. when you're inside its effectively a separate, fresh, OS install).
You're thinking of ChromeOS I think, which uses a combination of containers and virtualization (via the same VMM in this article) for Linux and Android apps..
What's the current state of the art for Android virtualization? Let's assume we're talking about the newest Pixel and newest Android version. Is there any way to safely run malware or the Facebook app in some sort of air-gapped container and throw it away when you're done?