QSB-084: Split GPG: GnuPG file descriptor confusion and file existence leak

We have just published Qubes Security Bulletin (QSB) 084: Split GPG: GnuPG file descriptor confusion and file existence leak. 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). More information about QSBs, including a complete historical list, is available here.

             ---===[ Qubes Security Bulletin 084 ]===---


  Split GPG: GnuPG file descriptor confusion and file existence leak

User action required

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

  For Qubes 4.1, in templates and standalones:
  - qubes-gpg-split 2.0.63

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]


Split GPG [3] is designed to isolate private keys from the application
using them in order to protect them from being extracted and to allow
the user to retain control over when they are used. This isolation is
implemented by forwarding calls from an application in a frontend qube,
where `qubes-gpg-client` is executed, to an instance of `gpg` in a
backend qube that holds the private keys, all while allowing only
specific `gpg` options. This option filtering mechanism is designed to
reject options like `--export-secret-keys` that might leak private keys
to the frontend qube. However, it has been discovered that certain
combinations of options allow the frontend qube to access data in the
backend qube in unintended ways.

Two separate types of attack were discovered:

1. Interaction via `--command-fd` allows the frontend qube to check for
   the existence of arbitrary files in the backend qube, including files
   unrelated to GnuPG.

2. Using the same `--*-fd` option several times allows the frontend qube
   to redirect GnuPG input and output to the wrong file descriptor. This
   can be used to:

   - Corrupt files used by GnuPG. (We have confirmed this only in the
     case of `trustdb`, but other files cannot be ruled out.)
   - Issue arbitrary commands to `gpg-agent`, which can be used to
     perform actions like generating new secret keys and deleting
     existing keys.
   - Set various environment variables for the `pinentry` process,
     thereby providing an indirect avenue of attack against this

   However, our testing did not reveal any way to exploit this
   vulnerability in order to read `gpg-agent`'s responses, which means
   that certain actions, such as extracting secret keys, should not be


An attacker controlling a Split GPG frontend qube can check for the
existence of arbitrary files in a backend qube, corrupt the `trustdb`
file in a backend qube, issue arbitrary commands to `gpg-agent` in a
backend qube, and issue arbitrary commands to a smart card daemon in a
backend qube. While this vulnerability can be exploited in order to
generate and delete keys in the backend qube (or on a smart card
attached to the backend qube), it is unlikely that it can be used to
exfiltrate private keys out of the backend qube (or off of a smart card
attached to the backend qube). If this vulnerability were to be chained
with a hypothetical vulnerability in `gpg-agent`, `scdaemon`, or
`pinentry` (or in one of the libraries they use), then arbitrary code
execution could be possible.


This issue was discovered by Demi Marie Obenour.


[1] https://www.qubes-os.org/doc/testing/
[2] https://www.qubes-os.org/doc/how-to-update/
[3] https://www.qubes-os.org/doc/split-gpg/

The Qubes Security Team

This is a companion discussion topic for the original entry at https://www.qubes-os.org/news/2022/08/06/qsb-084/
1 Like