Re: [qubes-users] Article about Qubes OS @ Freedom of the Press Foundation blog
37 views
Skip to first unread message
Joanna Rutkowska
Apr 11, 2014, 1:33:41 PM4/11/14
to Marek Marczykowski-Górecki, qubes...@googlegroups.com
On 04/11/14 19:16, Marek Marczykowski-Górecki wrote:
> [offlist]
>
> On 11.04.2014 18:59, Joanna Rutkowska wrote:
>> On 04/11/14 16:49, Micah Lee wrote:
>>>> 2) When considering an "air-gapped" Qubes AppVM, i.e. an AppVM which has
>>>>> no networking, one should remember about the possibility of the malware
>>>>> in that AppVM to leak secrets using a (sophisticated) covert channel,
>>>>> e.g. via CPU cache, to some other AppVM. This naturally assumes that
>>>>> this other AppVM has also been compromised and that the malware in the
>>>>> "air-gapped" machine cooperates with the malware in the other AppVM
>>>>> (which we assume is network-connected).
>>>>>
>>>>> Such covert channels through CPU cache has been described and even
>>>>> implemented in some "lab environments" and IIRC they might allow for
>>>>> bandwidths of even a few tens of bits/sec. It is unclear to me if such
>>>>> channels could be implemented in a "real world" system, where multiple
>>>>> VMs execute at the same time, each running tens or hundreds of
>>>>> processes, all using the same cache memory, but it's worth keeping in
>>>>> mind. Of course this wold require special malware written specifically
>>>>> to attack Qubes OS, and perhaps even specific Qubes OS version and
>>>>> perhaps specific Qubes OS configuration. Nevertheless might be possible.
>>> I wonder, are there other covert channels that could be used to
>>> communicate between AppVMs, or is CPU cache the only one?
>>>
>>
>> I would expect more timing-based covert channels exploiting things such
>> as common backends (in case of Qubes that would at least be the disk
>> backend), some hypercalls perhaps. There might also a chance that some
>> hypercalls might be used for directly leaking data between VMs, although
>> I would expect these (if exists) to qualify as implementation bugs,
>> which should be easily fixable (in contrast to timing channels which are
>> not easily fixable if we don't want to sacrifice performance of the
>> whole system dramatically). I'm not an expert on cooperative covert
>> channels in VMM systems though.
>
> Assuming two *cooperating* VMs, IMO it is doable to establish not only
> low-bandwidth covert channel, but simple xen shared memory, which would be
> high-bandwidth channel. You need for this:
> 1. the other domain ID (on both sides) - rather easy to guess as it is int <
> 100 in most cases (*),
> 2. grant ref (on "receiving" side), also some small int, looks like <10^6 (**).
>
> The whole operation would be:
> 1. VM1 allocate some memory page, share it to all reasonable domain ids (100
> grants or so)
> 2. VM2 tries to bruteforce domain id of VM1 and grant reference - something
> about 100*10^6 tries, perhaps even less if some hypercall error code allows to
> validate domain id (distinguish invalid domain id from invalid grant reference).
>
> (*) If one of this domains is netvm, it is very likely it has XID 1.
> (**) AFAIR that grant ref is assigned by sharing VM kernel. Maybe if attacker
> control the VM1 kernel, he/she have influence on grant reference number, so
> can use some known value.
>
Ah, that's true. I wonder whether Xen XSM allows to setup a policy on
which VMs could share pages with which VMs? If it did (and I would
expect so), it would be the actual first useful thing in practice that
XSM provides. Perhaps we should investigate this for Qubes R3?
joanna.
> [offlist]
>
> On 11.04.2014 18:59, Joanna Rutkowska wrote:
>> On 04/11/14 16:49, Micah Lee wrote:
>>>> 2) When considering an "air-gapped" Qubes AppVM, i.e. an AppVM which has
>>>>> no networking, one should remember about the possibility of the malware
>>>>> in that AppVM to leak secrets using a (sophisticated) covert channel,
>>>>> e.g. via CPU cache, to some other AppVM. This naturally assumes that
>>>>> this other AppVM has also been compromised and that the malware in the
>>>>> "air-gapped" machine cooperates with the malware in the other AppVM
>>>>> (which we assume is network-connected).
>>>>>
>>>>> Such covert channels through CPU cache has been described and even
>>>>> implemented in some "lab environments" and IIRC they might allow for
>>>>> bandwidths of even a few tens of bits/sec. It is unclear to me if such
>>>>> channels could be implemented in a "real world" system, where multiple
>>>>> VMs execute at the same time, each running tens or hundreds of
>>>>> processes, all using the same cache memory, but it's worth keeping in
>>>>> mind. Of course this wold require special malware written specifically
>>>>> to attack Qubes OS, and perhaps even specific Qubes OS version and
>>>>> perhaps specific Qubes OS configuration. Nevertheless might be possible.
>>> I wonder, are there other covert channels that could be used to
>>> communicate between AppVMs, or is CPU cache the only one?
>>>
>>
>> I would expect more timing-based covert channels exploiting things such
>> as common backends (in case of Qubes that would at least be the disk
>> backend), some hypercalls perhaps. There might also a chance that some
>> hypercalls might be used for directly leaking data between VMs, although
>> I would expect these (if exists) to qualify as implementation bugs,
>> which should be easily fixable (in contrast to timing channels which are
>> not easily fixable if we don't want to sacrifice performance of the
>> whole system dramatically). I'm not an expert on cooperative covert
>> channels in VMM systems though.
>
> Assuming two *cooperating* VMs, IMO it is doable to establish not only
> low-bandwidth covert channel, but simple xen shared memory, which would be
> high-bandwidth channel. You need for this:
> 1. the other domain ID (on both sides) - rather easy to guess as it is int <
> 100 in most cases (*),
> 2. grant ref (on "receiving" side), also some small int, looks like <10^6 (**).
>
> The whole operation would be:
> 1. VM1 allocate some memory page, share it to all reasonable domain ids (100
> grants or so)
> 2. VM2 tries to bruteforce domain id of VM1 and grant reference - something
> about 100*10^6 tries, perhaps even less if some hypercall error code allows to
> validate domain id (distinguish invalid domain id from invalid grant reference).
>
> (*) If one of this domains is netvm, it is very likely it has XID 1.
> (**) AFAIR that grant ref is assigned by sharing VM kernel. Maybe if attacker
> control the VM1 kernel, he/she have influence on grant reference number, so
> can use some known value.
>
Ah, that's true. I wonder whether Xen XSM allows to setup a policy on
which VMs could share pages with which VMs? If it did (and I would
expect so), it would be the actual first useful thing in practice that
XSM provides. Perhaps we should investigate this for Qubes R3?
joanna.
0 new messages