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.
> 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.