On Thursday, January 18, 2018 at 7:00:42 PM UTC+1, Nik H wrote:
> On Jan 16, 2018, at 2:56 AM, Vít Šesták <…@v6ak.com> wrote:
> > 
> > * If an application does not mitigate Spectre and attacker finds useful 
> > entry point, attacker can read memory of the application (but nothing more).
> > * If VM kernel does not mitigate Spectre and attacker finds useful entry 
> > point, attacker can probably read memory of whole VM (but other VMs are not 
> > affected).
> > * If Xen does not mitigate Spectre and attacker finds useful entry point, 
> > attacker can probably read memory of whole system.
> 
> Can you explain why you think that Spectre can't escape the container (VM)? 
> It seems that is the main issue, Spectre escapes the container.

It depends on what you mean by VM escape. Sure, both Meltdown and Spectre are 
about reading memory that should not be accessible. From your description 
below, I believe you have confused those two.

The reason why Spectre is much harder to actually exploit than Meltdown: For 
Meltdown, you just use your own code to read the memory. With Spectre, you have 
to use (and find!) a victim's code to perform innocently-looking operations.

Meltdown allows attacker to read any address in her address space. That's not 
always whole physical address space, but in case of Xen PV x64 domains, it is 
the case.

Spectre allows to read the memory in a different way. Imagine the _victim_ has 
code like this:

if((i > 0) &&(i < a_length)) {
    return a[i];
} else {
    return NULL; // or any other error code
}

This looks like a perfect code that prevents overreads and underreads. But an 
attempt to overread/underread will affect cache. Fortunatelly, such simple code 
is not much useful. The attacker rather needs something like this: 
foo[bar[index]]. Even with all the proper bounds checks (that will cause the 
code not to execute in traditional sense), attacker might try to perform 
overflow/underflow by using index variable out of range. But CPU might try to 
execute the branch speculatively (because the condition is usually satisfied), 
which can cause a read of arbitrary out-of-bounds bar[index]. The read of the 
value would be probably benign on its own, but then, it tries to load data from 
foo array based on this value, which might cause cache fetch depending on value 
of bar[index]. The attacker has not won yet, she has to determine what part of 
memory was loaded into cache. This can be done using timing attack.

Another interesting part of Spectre is branch target injection. I remember some 
double fetch vulnerability that can cause bad jump due to race condition 
(TOCTOU issue). With Spectre, attacker can try to abuse this for bad 
speculative jump even if there is no race condition possible.

But my main point is that for Spectre attack, the fact that nobody has cared 
about that when writing the software is not enough for successful exploitation. 
Actually, one needs to find a suitable code that processes some attacker's 
input in a suitable way. Moreover, the attacker needs some precise measurement, 
so passing some malicious input to some queue in order to be processed by code 
that can trigger speculative out-of-bounds read can be impractical.

> I read the whitepaper and what Spectre is doing is, it's accessing memory it 
> should not have access to, and then uses a few simple tricks to extract the 
> data it should not have access to. This happens on a processor level so any 
> bounds checks that are outside the CPU core will not prevent that.

That's true for both Spectre and Meltdown. But the fact that bounds checks 
aren't enough does not mean that those attack cannot be mitigated in software 
elsehow.

> Given the nature of the attack, I do not think that hardware virtualization 
> would stop this attack.

If this is about Spectre, you are right, hardware virtualization does not stop 
it on its own. For Meltdown, the situation is a bit different: Hardware 
virtualization makes the VM not to have the address outside the VM mapped in 
its address space. Trying to access the memory outside the VM is not prevented 
by bounds check, it is prevented by the simple fact that they have no address. 
Note that this AFAIU does not prevent attacking VM's kernel from VM's process, 
it just prevents attacking hypervisor from VM.


> I found various snippets of information hinting at this as well, but again, 
> I'd be happy to be wrong! But, if I am right, then qubes isolation is 
> compromised.

Well, you are mostly right. But maybe we should divide it to base system (e.g., 
Xen and dom0) and single VMs.

The base system is unfortunately affected by Meltdown, because it mostly does 
not use hardware virtualization. (Qubes 4 is quite better there, but still not 
perfect.) It might be also vulnerable to Spectre attacks, but I am not sure if 
they are practical.

Single VMs might be vulnerable to both (unless patched). Meltdown vulnerability 
is usually not much an issue there, because Qubes does not utilize user 
separation within a VM much. (But probably Chrome sandbox can see something it 
should not see. It cannot use Meltdown to see other processes, just some kernel 
memory.) And Spectre is quite omnipresent.

Regards,
Vít Šesták 'v6ak'

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/76e3d890-2c55-461d-a049-f56e431df707%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to