QSB #61 Information leak via power sidechannel (XSA-351)

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Dear Qubes Community,

We have just published Qubes Security Bulletin (QSB) #61: Information
leak via power sidechannel (XSA-351). The text of this QSB is
reproduced below. This QSB and its accompanying signatures will always
be available in the Qubes Security Pack (qubes-secpack).

View QSB #61 in the qubes-secpack:

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-061-2020.txt

Learn about the qubes-secpack, including how to obtain, verify, and read
it:

https://www.qubes-os.org/security/pack/

View all past QSBs:

https://www.qubes-os.org/security/bulletins/

View XSA-351 in the XSA Tracker:

https://www.qubes-os.org/security/xsa/#351

```


---===[ Qubes Security Bulletin #61 ]===---

2020-11-10


Information leak via power sidechannel (XSA-351)


Summary
========

On 2020-11-10, the Xen Security Team published Xen Security Advisory
351 (XSA-351) [1] with the following description:

| Researchers have demonstrated using software power/energy monitoring
| interfaces to create covert channels, and infer the operations/data used
| by other contexts within the system.
|
| Access to these interfaces should be restricted to privileged software,
| but it was found that Xen doesn't restrict access suitably, and the
| interfaces are accessible to all guests.
|
| For more information, see:
| https://platypusattack.com
| https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00389.html
|
| An unprivileged guest administrator can sample platform power/energy
| data. This may be used to infer the operations/data used by other
| contexts within the system.
|
| The research demonstrates using this sidechannel to leak the AES keys
| used elsewhere in the system.


Patching
=========

The specific packages that resolve the problems discussed in this
bulletin are as follows:

For Qubes 4.0:
- Xen packages, version 4.8.5-26
For Qubes 4.1:
- Xen packages, version 4.14.0-7

The packages are to be installed in dom0 via the Qube Manager or via
the qubes-dom0-update command as follows:

For updates from the stable repository (not immediately available):
$ sudo qubes-dom0-update

For updates from the security-testing repository:
$ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing

A system restart will be required afterwards.

These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community.

If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new
Xen binaries.


Credits
========

See the original Xen Security Advisory.


References
===========

[1] https://xenbits.xen.org/xsa/advisory-351.html

- --
The Qubes Security Team
https://www.qubes-os.org/security/
```
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl+srmoACgkQ24/THMrX
1yyq8Af/fUy3neIkRJ1JDWX+7y9/o/a/oHOjGZA4ETH+Bu5JnalAxc4w2ts+XkFX
mUAN2Y6bwXmBGMaPjn7MysT3XWINYqz/RVrXbKl9k8Oky0T61HnE0MOGwQeOLXt/
AI/sgRpqK2B6degrbze+0LquzZW/Gxd/4l5diDj+Dop9dPn6EJVz5F4xCNzgRBcl
vPhpXBPN7IwUySCCOx6LdCinYjvTyVeH05dTJA04DZykSaXCullMgOl4i3WKbzgS
+yJFW9/D+NNAtb0Z9+FynvQ3lmIM+OycBsc8LbDv2scMdwakpNeVhCQY1t8I+h6Y
U9u7yjQedhSZpxD586q8zLkBzIXvFA==
=con+
-----END PGP SIGNATURE-----

[Demi M. Obenour]

FYI, I am not sure how to obtain the public key that signed that
message.

Sincerely,

Demi

[unman]

https://www.qubes-os.org/team/
Or search on keyserver

[Demi M. Obenour]

I imported the key, but am trying to figure out how to build a chain
of trust to it. If someone could help me, that would be greatly
appreciated. Once that is done, I will file a PR to the documentation.

Sincerely,

Demi

[Demi M. Obenour]

On 11/12/20 11:49 AM, unman wrote:

I was able to import the key, but am not sure how to build a chain
of trust to it. Once I have managed to build one, I will file a PR

[Andrew Clausen]

Hi Demi,

On Thu, 12 Nov 2020 at 16:26, Demi M. Obenour <demio...@gmail.com> wrote:

FYI, I am not sure how to obtain the public key that signed that
message.

All Qubes keys are available inside the "distribution-gpg-keys" package, which you can install with "dnf install distribution-gpg-keys".  Since this package is signed, it has a pretty good chain of trust built into it.  Since this is a Fedora package, it is also helpful for securely installing Qubes from another Fedora-based distribution.

I have been meaning to update the Qubes documentation about this, but I have been a bit busy!

Kind regards,

Andrew

[Demi M. Obenour]

Thank you! That is quite helpful, although it doesn’t include the
email keys.

Sincerely,

Demi

[Andrew Clausen]

Hi Demi,

On Fri, 13 Nov 2020 at 20:06, Demi M. Obenour <demio...@gmail.com> wrote:

Thank you!  That is quite helpful, although it doesn’t include the
email keys.

Oops, I missed that.  Perhaps we should add in the keys from https://www.qubes-os.org/team ?  I think it would be ideal to not clutter up the package though.  We could just include Marek's key, which presumebly signs all the other ones?

Or alternatively, perhaps security bulletins should be signed with a Qubes project key?

Kind regards,

Andrew

[Andrew David Wong]

Added. Thank you!

https://github.com/QubesOS/qubes-doc/pull/1079/commits/fdcaadaeec4d91edc01bdfd8774c9e27de04260d

> We could just include Marek's key, which presumebly signs all the
other ones?

It does not.

> Or alternatively, perhaps security bulletins should be signed with a
Qubes project key?

QSBs are already signed by individual Qubes Security Team members'
Security Team keys, which are in turned signed by the Qubes Master
Signing Key, so you already have the required chain of trust there.

--
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

[Andrew Clausen]

Hi Andrew,

On Sat, 14 Nov 2020 at 08:29, Andrew David Wong <a...@qubes-os.org> wrote:

> I have been meaning to update the Qubes documentation about this, but I
> have been a bit busy!

Added. Thank you!

https://github.com/QubesOS/qubes-doc/pull/1079/commits/fdcaadaeec4d91edc01bdfd8774c9e27de04260d

Thanks a lot.  I didn't know about this document.  In general, I find it a little hard to follow.  For example, distribution-gpg-keys isn't listed as one of the "several ways to get the Qubes Master Signing Key".  It comes later, where it might be overlooked.  I might have a shot at redrafting this soon.

Anyway, should I include a copy (and link to the original) in the distribution-gpg-keys package?

 

 > Or alternatively, perhaps security bulletins should be signed with a
Qubes project key?

QSBs are already signed by individual Qubes Security Team members'
Security Team keys, which are in turned signed by the Qubes Master
Signing Key, so you already have the required chain of trust there.

That sounds sensible.  Should this be documented in the "verifying signatures" document too?

Kind regards,

Andrew

[Andrew David Wong]

On 11/14/20 6:32 AM, Andrew Clausen wrote:
> Hi Andrew,
>
> On Sat, 14 Nov 2020 at 08:29, Andrew David Wong <a...@qubes-os.org> wrote:
>
>>> I have been meaning to update the Qubes documentation about this, but I
>>> have been a bit busy!
>>
>> Added. Thank you!
>>
>>
>> https://github.com/QubesOS/qubes-doc/pull/1079/commits/fdcaadaeec4d91edc01bdfd8774c9e27de04260d
>>
>
> Thanks a lot. I didn't know about this document. In general, I find it a
> little hard to follow. For example, distribution-gpg-keys isn't listed as
> one of the "several ways to get the Qubes Master Signing Key".

Oh, true. I'll also add it to that list.

> It comes later, where it might be overlooked.

I think it also makes sense to mention it later, since it concerns
authenticating the key.

> I might have a shot at redrafting this soon.
>

I'm a bit surprised that you find it hard to follow *in general*. I'm
curious what you have in mind.

> Anyway, should I include a copy (and link to the original) in the
> distribution-gpg-keys package?
>

The "Verifying Signatures" document? I'd generally recommend linking to
the original rather than making a copy, since the copy will probably
become desyncrhonized from the original over time.

>
>> > Or alternatively, perhaps security bulletins should be signed with a
>> Qubes project key?
>>
>> QSBs are already signed by individual Qubes Security Team members'
>> Security Team keys, which are in turned signed by the Qubes Master
>> Signing Key, so you already have the required chain of trust there.
>>
>
> That sounds sensible. Should this be documented in the "verifying
> signatures" document too?
>

No, that's already documented here:

https://www.qubes-os.org/security/pack/#how-to-obtain-verify-and-read