On Thu, Jan 18, 2018 at 3:49 PM, Vít Šesták
> 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.)

Err, I'm not sure this is the case. I suspect it is not due to all
guest-physical memory being mapped in the guest kernel's direct map.

- https://cs.brown.edu/~vpk/papers/ret2dir.sec14.pdf

> And Spectre is quite omnipresent.

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 
For more options, visit https://groups.google.com/d/optout.

Reply via email to