Re: [qubes-devel] Security concerns with split-gpg1 to split-gpg2 migration

[Demi Marie Obenour]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Wed, Jul 13, 2022 at 01:56:54PM +0200, Simon Gaiser wrote:
> [ Sorry for the previous mail with broken white space, hopefully fixed
> now. Really annoying that Google Groups still prevents using PGP/MIME. ]

Yeah, *especially* when one wants to attach files.

> Demi Marie Obenour:
> > split-gpg2 [1] is the planned replacement for split-gpg1 [2].  It has
> > several advantages, such as much lower attack surface, support for all
> > of gpg(1)’s options, and support for key management operations.
> > However, the last is also a potential security concern.
> > 
> > Right now, a compromised frontend VM can sign or decrypt messages with
> > any key in the backend VM, but it *cannot* sign or revoke keys.  This
> > limitation is also useful, since a mail client (for example) has no
> > need to perform these operations.  However it is difficult for
> > split-gpg2 to enforce this restriction.
> > 
> > The technical reason for this restriction is that the “type” byte in
> > an OpenPGP signature of a message is always 0 or 1, but other
> > signatures use different types.  The type of a signature is part of
> > the signed data, so it is not possible to pretend that a signature of
> > one type is a signature of another type.  The type of a signature that
> > GnuPG will generate depends on the options passed to it, but
> > split-gpg1 only allows a subset of these options.  The subset of
> > options passed by split-gpg1 only allow signatures of type 0 or 1 to
> > be created, and those are only valid as signatures of messages.
> > 
> > Unfortunately, split-gpg2 does not see the data being signed!  It only
> > sees the hash of that data.  Therefore, split-gpg2 has no idea what
> > type of signature it is making: it could be a signature on a binary
> > document, a signature of a key and user ID, or even something that is
> > not an OpenPGP signature at all.  For instance, gpgsm also uses
> > gpg-agent, and so is also supported by split-gpg2.  It generates CMS
> > (Cryptographic Message Syntax, also known as S/MIME) signatures, which
> > are different than OpenPGP signatures.
> 
> Correct. You need to think of split-gpg2 as a smartcard (that has one
> acknowledge button). There are indeed things that are not possible with
> the splt-gpg2 architecture that are possible with split-gpg1, for
> example showing the data you are about to sign (only useful in a few
> cases).

In some ways, the situation might actually be worse.  I am not sure if a
smartcard will allow using a signing key for decryption or visa versa.
I know that split-gpg2 will.

> For such special cases I would recommend to use neither split-gpg
> variants and instead use a dedicated qrexec service that just does the
> needed operations. This also makes other things like for example an
> audit log much easier. Of course you loose the "gpg drop-in" feature of
> both split-gpg variants.

I agree.  I have just such a service that I use for signing git commits
and RPM packages.  I should clean it up and publish it at some point.
It is only 60 lines of Python, and much of that duplicates what qrexec
policy can already do.  This *will* require an array of client-side
wrapper scripts to adapt various programs, but this can be worked
around.  The wrapper script used for split-gpg1 might be a basis for
some of these.

> > The best solution that I have come up with is to not allow the
> > frontend to use any key it wishes, but only allow it to use a subset
> > of keys.
> 
> Exactly!
> 
> > Migrating from split-gpg1 to split-gpg2 would involve generating a
> > subkey that is capable of signing data, but is *not* capable of
> > certification (signing other keys, revoking keys, etc). split-gpg2
> > would then be configured to only allow the frontend to use this
> > subkey, *not* the main key.  The frontend could still generate
> > signatures of other keys with this subkey, but these signatures are
> > not valid.  If a program trusts these signatures, then either it has
> > imported a key controlled by the frontend (in which case the frontend
> > could have just generated its own key) or the program has a security
> > vulnerability.
> > 
> > Sadly, split-gpg2 does not have support for this — yet.  There is no
> > fundamental reason such support cannot be added, but right now
> > split-gpg2 (like split-gpg1) either allows all access or denies all
> > access.
> 
> That's not quite true. Yes they don't provide an option to filter keys,
> beyond not importing them to your GNUPGHOME (I consider that a feature,
> due to reduced complexity). But what you seem to have missed is that
> GnuPG has native support for exactly this scenario, see the
> --export-secret-subkeys option.
> 
> From the manpage:
> 
> --export-secret-keys
> --export-secret-subkeys
> [...]
> 
> The second form of the command has the special property to
> render the secret part of the primary key useless; this is a GNU
> 

[qubes-devel] XSAs released on 2022-07-12

[Andrew David Wong]

Dear Qubes Community,

The Xen Project has released one or more Xen Security Advisories (XSAs).
The security of Qubes OS *is affected*.
Therefore, *user action is required*.


XSAs that affect the security of Qubes OS (user action required)


The following XSAs *do affect* the security of Qubes OS:

- XSA-407

Please see *QSB-083* for the actions users must take in order to
protect themselves, as well as further details about these XSAs:




XSAs that do not affect the security of Qubes OS (no user action required)
--

The following XSAs *do not affect* the security of Qubes OS, and no user 
action is necessary:


- (none)


Related links
-

- Xen XSA list: 
- Qubes XSA tracker: 
- Qubes security pack (qubes-secpack): 


- Qubes security bulletins (QSBs): 


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2022/07/13/xsas-released-on-2022-07-12/

--
Andrew David Wong
Community Manager
The Qubes OS Project
https://www.qubes-os.org

--
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/70a17d1f-0935-2fac-77ca-b2c95c5f4f21%40qubes-os.org.

[qubes-devel] QSB-083: Retbleed: Arbitrary speculative code execution with return instructions (XSA-407)

[Andrew David Wong]

Dear Qubes Community,

We have just published Qubes Security Bulletin (QSB) 083: Retbleed:
Arbitrary speculative code execution with return instructions (XSA-407).
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-083 in the qubes-secpack:



In addition, you may wish to:

- Get the qubes-secpack: 
- View all past QSBs: 
- View the XSA Tracker: 

```

 ---===[ Qubes Security Bulletin 083 ]===---

 2022-07-12

  Retbleed

Arbitrary speculative code execution
 with return instructions (XSA-407)


User action required
-

Users must install the following specific packages in order to address
the issues discussed in this bulletin:

  For Qubes 4.0, in dom0:
  - Xen packages, version 4.8.5-43

  For Qubes 4.1, in dom0:
  - Xen packages, version 4.14.5-6

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. [1] Once available, the packages are to be installed
via the Qubes Update tool or its command-line equivalents. [2]

Dom0 must be restarted afterward in order for the updates to take
effect.

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.


Summary


On 2022-07-12, the Xen Project published XSA-407, "Retbleed -
arbitrary speculative code execution with return instructions" [3]:

| Researchers at ETH Zurich have discovered Retbleed, allowing for
| arbitrary speculative execution in a victim context.
|
| For more details, see:
|   https://comsec.ethz.ch/retbleed
|
| ETH Zurich have allocated CVE-2022-29900 for AMD and CVE-2022-29901 for
| Intel.
|
| Despite the similar preconditions, these are very different
| microarchitectural behaviours between vendors.
|
| On AMD CPUs, Retbleed is one specific instance of a more general
| microarchitectural behaviour called Branch Type Confusion.  AMD have
| assigned CVE-2022-23816 (Retbleed) and CVE-2022-23825 (Branch Type
| Confusion).
|
| For more details, see:
|   https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1037
|
| On Intel CPUs, Retbleed is not a new vulnerability; it is only
| applicable to software which did not follow Intel's original
| Spectre-v2 guidance.  Intel are using the ETH Zurich allocated
| CVE-2022-29901.
|
| For more details, see:
| 
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00702.html
| 
https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/return-stack-buffer-underflow.html

|
| ARM have indicated existing guidance on Spectre-v2 is sufficient.


Impact
---

This is yet another speculative execution issue, which allows an
attacker to infer content of memory they shouldn't have access to. This
includes one VM extracting secrets from another. Any VM can perform this
attack on an affected hardware.

AMD systems based on Zen 1 - Zen 2 microarchitectures are affected.
Specifically those are AMD Ryzen processors with model names 1xxx - 4xxx
and some 5xxxU [4]. Zen 3 microarchitecture (AMD Ryzen 5xxx or newer)
are not affected.

Pre-existing Xen mitigations on Intel machines are effective to prevent
this issue, so Intel systems are not affected.

Credits


See the original Xen Security Advisory.


References
---

[1] https://www.qubes-os.org/doc/testing/
[2] https://www.qubes-os.org/doc/how-to-update/
[3] https://xenbits.xen.org/xsa/advisory-407.html
[4] Unlike other 5xxxU models, Ryzen 3 5300U, Ryzen 5 5500U and
Ryzen 7 5700U are Zen 2, not Zen 3. See
https://en.wikipedia.org/wiki/Zen2
https://en.wikipedia.org/wiki/Zen3

--
The Qubes Security Team
https://www.qubes-os.org/security/

```

This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2022/07/13/qsb-083/

--
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/e75410c2-43d0-b625-d599-0e09f769b635%40qubes-os.org.

Re: [qubes-devel] Security concerns with split-gpg1 to split-gpg2 migration

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, Jul 13, 2022 at 01:56:54PM +0200, Simon Gaiser wrote:
> [ Sorry for the previous mail with broken white space, hopefully fixed
> now. Really annoying that Google Groups still prevents using PGP/MIME. ]
> 
> Demi Marie Obenour:
> > split-gpg2 [1] is the planned replacement for split-gpg1 [2].  It has
> > several advantages, such as much lower attack surface, support for all
> > of gpg(1)’s options, and support for key management operations.
> > However, the last is also a potential security concern.
> > 
> > Right now, a compromised frontend VM can sign or decrypt messages with
> > any key in the backend VM, but it *cannot* sign or revoke keys.  This
> > limitation is also useful, since a mail client (for example) has no
> > need to perform these operations.  However it is difficult for
> > split-gpg2 to enforce this restriction.
> > 
> > The technical reason for this restriction is that the “type” byte in
> > an OpenPGP signature of a message is always 0 or 1, but other
> > signatures use different types.  The type of a signature is part of
> > the signed data, so it is not possible to pretend that a signature of
> > one type is a signature of another type.  The type of a signature that
> > GnuPG will generate depends on the options passed to it, but
> > split-gpg1 only allows a subset of these options.  The subset of
> > options passed by split-gpg1 only allow signatures of type 0 or 1 to
> > be created, and those are only valid as signatures of messages.
> > 
> > Unfortunately, split-gpg2 does not see the data being signed!  It only
> > sees the hash of that data.  Therefore, split-gpg2 has no idea what
> > type of signature it is making: it could be a signature on a binary
> > document, a signature of a key and user ID, or even something that is
> > not an OpenPGP signature at all.  For instance, gpgsm also uses
> > gpg-agent, and so is also supported by split-gpg2.  It generates CMS
> > (Cryptographic Message Syntax, also known as S/MIME) signatures, which
> > are different than OpenPGP signatures.
> 
> Correct. You need to think of split-gpg2 as a smartcard (that has one
> acknowledge button). There are indeed things that are not possible with
> the splt-gpg2 architecture that are possible with split-gpg1, for
> example showing the data you are about to sign (only useful in a few
> cases).
> 
> For such special cases I would recommend to use neither split-gpg
> variants and instead use a dedicated qrexec service that just does the
> needed operations. This also makes other things like for example an
> audit log much easier. Of course you loose the "gpg drop-in" feature of
> both split-gpg variants.
> 
> > The best solution that I have come up with is to not allow the
> > frontend to use any key it wishes, but only allow it to use a subset
> > of keys.
> 
> Exactly!
> 
> > Migrating from split-gpg1 to split-gpg2 would involve generating a
> > subkey that is capable of signing data, but is *not* capable of
> > certification (signing other keys, revoking keys, etc). split-gpg2
> > would then be configured to only allow the frontend to use this
> > subkey, *not* the main key.  The frontend could still generate
> > signatures of other keys with this subkey, but these signatures are
> > not valid.  If a program trusts these signatures, then either it has
> > imported a key controlled by the frontend (in which case the frontend
> > could have just generated its own key) or the program has a security
> > vulnerability.

My primary concern is a case like this:
1. Somebody either uses split-gpg1 or simply wants to protect their
private keys from being extracted and used without authorization.
2. With split-gpg2, an attacker controlling client VM can generate own
key and get it signed with your primary key.
3. They can then push new subkeys to some keyserver to have them
distributed.

At this point, it isn't that helpful that you still control your primary
key, attacker have a subkey they fully control and you may be not even
aware of that. If they manage the key distribution part, nobody else
will see anything suspicious.

> > Sadly, split-gpg2 does not have support for this — yet.  There is no
> > fundamental reason such support cannot be added, but right now
> > split-gpg2 (like split-gpg1) either allows all access or denies all
> > access.
> 
> That's not quite true. Yes they don't provide an option to filter keys,
> beyond not importing them to your GNUPGHOME (I consider that a feature,
> due to reduced complexity). But what you seem to have missed is that
> GnuPG has native support for exactly this scenario, see the
> --export-secret-subkeys option.
> 
> From the manpage:
> 
> --export-secret-keys
> --export-secret-subkeys
> [...]
> 
> The second form of the command has the special property to
> render the secret part of the primary key useless; this is a GNU
> extension to OpenPGP and other implementations 

Re: [qubes-devel] Security concerns with split-gpg1 to split-gpg2 migration

[Simon Gaiser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

[ Sorry for the previous mail with broken white space, hopefully fixed
now. Really annoying that Google Groups still prevents using PGP/MIME. ]

Demi Marie Obenour:
> split-gpg2 [1] is the planned replacement for split-gpg1 [2].  It has
> several advantages, such as much lower attack surface, support for all
> of gpg(1)’s options, and support for key management operations.
> However, the last is also a potential security concern.
> 
> Right now, a compromised frontend VM can sign or decrypt messages with
> any key in the backend VM, but it *cannot* sign or revoke keys.  This
> limitation is also useful, since a mail client (for example) has no
> need to perform these operations.  However it is difficult for
> split-gpg2 to enforce this restriction.
> 
> The technical reason for this restriction is that the “type” byte in
> an OpenPGP signature of a message is always 0 or 1, but other
> signatures use different types.  The type of a signature is part of
> the signed data, so it is not possible to pretend that a signature of
> one type is a signature of another type.  The type of a signature that
> GnuPG will generate depends on the options passed to it, but
> split-gpg1 only allows a subset of these options.  The subset of
> options passed by split-gpg1 only allow signatures of type 0 or 1 to
> be created, and those are only valid as signatures of messages.
> 
> Unfortunately, split-gpg2 does not see the data being signed!  It only
> sees the hash of that data.  Therefore, split-gpg2 has no idea what
> type of signature it is making: it could be a signature on a binary
> document, a signature of a key and user ID, or even something that is
> not an OpenPGP signature at all.  For instance, gpgsm also uses
> gpg-agent, and so is also supported by split-gpg2.  It generates CMS
> (Cryptographic Message Syntax, also known as S/MIME) signatures, which
> are different than OpenPGP signatures.

Correct. You need to think of split-gpg2 as a smartcard (that has one
acknowledge button). There are indeed things that are not possible with
the splt-gpg2 architecture that are possible with split-gpg1, for
example showing the data you are about to sign (only useful in a few
cases).

For such special cases I would recommend to use neither split-gpg
variants and instead use a dedicated qrexec service that just does the
needed operations. This also makes other things like for example an
audit log much easier. Of course you loose the "gpg drop-in" feature of
both split-gpg variants.

> The best solution that I have come up with is to not allow the
> frontend to use any key it wishes, but only allow it to use a subset
> of keys.

Exactly!

> Migrating from split-gpg1 to split-gpg2 would involve generating a
> subkey that is capable of signing data, but is *not* capable of
> certification (signing other keys, revoking keys, etc). split-gpg2
> would then be configured to only allow the frontend to use this
> subkey, *not* the main key.  The frontend could still generate
> signatures of other keys with this subkey, but these signatures are
> not valid.  If a program trusts these signatures, then either it has
> imported a key controlled by the frontend (in which case the frontend
> could have just generated its own key) or the program has a security
> vulnerability.
> 
> Sadly, split-gpg2 does not have support for this — yet.  There is no
> fundamental reason such support cannot be added, but right now
> split-gpg2 (like split-gpg1) either allows all access or denies all
> access.

That's not quite true. Yes they don't provide an option to filter keys,
beyond not importing them to your GNUPGHOME (I consider that a feature,
due to reduced complexity). But what you seem to have missed is that
GnuPG has native support for exactly this scenario, see the
- --export-secret-subkeys option.

- From the manpage:

--export-secret-keys
--export-secret-subkeys
[...]

The second form of the command has the special property to
render the secret part of the primary key useless; this is a GNU
extension to OpenPGP and other implementations can not be
expected to successfully import such a key. Its intended use is
in generating a full key with an additional signing subkey on a
dedicated machine. This command then exports the key without the
primary key to the main machine.

> There are various workarounds, but all of them are more complex than I
> would like.
> 
> What are people’s thoughts on this issue?  In the short term, one
> option is to use split-gpg2 as the backend for split-gpg1, which works
> fine. However, split-gpg1 is a maintenance hog with a lot of attack
> surface, so migrating entirely to split-gpg2 is definitely preferred.
> 
> [1]: https://github.com/QubesOS/qubes-app-linux-split-gpg2
> [2]: https://github.com/QubesOS/qubes-app-linux-split-gpg> 
-BEGIN PGP SIGNATURE-

Re: [qubes-devel] Security concerns with split-gpg1 to split-gpg2 migration

[Simon Gaiser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Demi Marie Obenour:

> split-gpg2 [1] is the planned replacement for split-gpg1 [2].  It has

> several advantages, such as much lower attack surface, support for all

> of gpg(1)’s options, and support for key management operations.

> However, the last is also a potential security concern.

> 

> Right now, a compromised frontend VM can sign or decrypt messages with

> any key in the backend VM, but it *cannot* sign or revoke keys.  This

> limitation is also useful, since a mail client (for example) has no

> need to perform these operations.  However it is difficult for

> split-gpg2 to enforce this restriction.

> 

> The technical reason for this restriction is that the “type” byte in

> an OpenPGP signature of a message is always 0 or 1, but other

> signatures use different types.  The type of a signature is part of

> the signed data, so it is not possible to pretend that a signature of

> one type is a signature of another type.  The type of a signature that

> GnuPG will generate depends on the options passed to it, but

> split-gpg1 only allows a subset of these options.  The subset of

> options passed by split-gpg1 only allow signatures of type 0 or 1 to

> be created, and those are only valid as signatures of messages.

> 

> Unfortunately, split-gpg2 does not see the data being signed!  It only

> sees the hash of that data.  Therefore, split-gpg2 has no idea what

> type of signature it is making: it could be a signature on a binary

> document, a signature of a key and user ID, or even something that is

> not an OpenPGP signature at all.  For instance, gpgsm also uses

> gpg-agent, and so is also supported by split-gpg2.  It generates CMS

> (Cryptographic Message Syntax, also known as S/MIME) signatures, which

> are different than OpenPGP signatures.



Correct. You need to think of split-gpg2 as a smartcard (that has one

acknowledge button). There are indeed things that are not possible with

the splt-gpg2 architecture that are possible with split-gpg1, for

example showing the data you are about to sign (only useful in a few

cases).



For such special cases I would recommend to use neither split-gpg

variants and instead use a dedicated qrexec service that just does the

needed operations. This also makes other things like for example an

audit log much easier. Of course you loose the "gpg drop-in" feature of

both split-gpg variants.



> The best solution that I have come up with is to not allow the

> frontend to use any key it wishes, but only allow it to use a subset

> of keys.



Exactly!



> Migrating from split-gpg1 to split-gpg2 would involve generating a

> subkey that is capable of signing data, but is *not* capable of

> certification (signing other keys, revoking keys, etc). split-gpg2

> would then be configured to only allow the frontend to use this

> subkey, *not* the main key.  The frontend could still generate

> signatures of other keys with this subkey, but these signatures are

> not valid.  If a program trusts these signatures, then either it has

> imported a key controlled by the frontend (in which case the frontend

> could have just generated its own key) or the program has a security

> vulnerability.

> 

> Sadly, split-gpg2 does not have support for this — yet.  There is no

> fundamental reason such support cannot be added, but right now

> split-gpg2 (like split-gpg1) either allows all access or denies all

> access.



That's not quite true. Yes they don't provide an option to filter keys,

beyond not importing them to your GNUPGHOME (I consider that a feature,

due to reduced complexity). But what you seem to have missed is that

GnuPG has native support for exactly this scenario, see the

- --export-secret-subkeys option.



- From the manpage:



--export-secret-keys

--export-secret-subkeys

[...]



The second form of the command has the special property to

render the secret part of the primary key useless; this is a GNU

extension to OpenPGP and other implementations can not be

expected to successfully import such a key. Its intended use is

in generating a full key with an additional signing subkey on a

dedicated machine. This command then exports the key without the

primary key to the main machine.



> There are various workarounds, but all of them are more complex than I

> would like.

> 

> What are people’s thoughts on this issue?  In the short term, one

> option is to use split-gpg2 as the backend for split-gpg1, which works

> fine. However, split-gpg1 is a maintenance hog with a lot of attack

> surface, so migrating entirely to split-gpg2 is definitely preferred.

> 

> [1]: https://github.com/QubesOS/qubes-app-linux-split-gpg2

> [2]: https://github.com/QubesOS/qubes-app-linux-split-gpg> 

-BEGIN PGP SIGNATURE-

iQJRBAEBCgA7FiEE3E8ezGzG3N1CTQ//kO9xfO/xly8FAmLOsMEdHHNpbW9uQGlu