5 ms·
So I suppose if we're going to be exceptionally paranoid, we would run everything on virtual machines. Unless I'm missing something, even if a process in a VM
by maxander 10y ago
So I suppose if we're going to be exceptionally paranoid, we would run everything on virtual machines. Unless I'm missing something, even if a process in a VM managed to trigger a physical nonideality on the physical machine granting access to supervisor mode, it would still be in user-mode on the VM. Then at least other clever things would have to be done to get out of the VM sandbox and into exposed physical-machine supervisor space.
Of course, if we're going to be paranoid, we should probably assume that the CIA and their friends have already come up with something even more nefarious that goes through these countermeasures like tissue-paper.
- Jabbles 10y agoOnce you have control of the supervisor you could just bitflip something within the VM to give you root there, if you needed it. Or you could just read/write arbitrary memory.
- maxander 10y agoBut you don't have control of the supervisor if the attacking process is confined to the VM, do you? You certainly don't have access to the VM's supervisor mode, since its "chip" wouldn't have this sort of physical vulnerability.
- Avernar 10y agoDepends on the type of VM. A VM emulating the same type of processor just runs the client code direct on the processor. What stops the client code from messing with the reat of the system, which includes the VM supervisor code, is the processor's protection circuitry. If client code does the exploit to kick the processor into supervisor or hypervisor mode it will be running client code in that elevated mode. Priveliged instructions would no longer trap to the VM's supervisor or host OS. Now if the VM is emulating the client's individual instructions, which is the usual for running code for a different type of CPU, then it's a different story. Under pure emulation it wouldn't work. The exploit would have to know what the host CPU architecture was, get the emulator code to trip the extra gate. As you said, all that would do is put the VM supervisor code into the CPU's supervisor mode which it probably is already in if the VM is running bare metal without a host OS. But if the VM use JIT conversion of the instructions for speed then the exploit becomes possible again.
- c_c_c 10y agoHost OS being compromised is one thing. Hardware compromised? VM won't help you