We have just published Qubes Security Bulletin (QSB) 087: Qrexec: Injection of unsanitized data into log output. 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 087 ]===--- 2022-11-23 Qrexec: Injection of unsanitized data into log output 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, standalones and dom0: - qrexec packages version 4.1.19 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.  Once available, the packages are to be installed via the Qubes Update tool or its command-line equivalents.  Summary -------- Due to a bug in qrexec , a malicious qube that is allowed to call a qrexec service inside of another qube can inject unsanitized data into the log output of a process that handles incoming qrexec calls in the receiving qube. This log output may end up in `/var/log/qubes/qrexec.*.log`, `~/.xsession-errors`, or systemd's journal. Impact ------- An attacker could use this vulnerability in order to inject malicious data, such as terminal control codes, into log output in the hope that this data will be processed in a unsafe way, for example, by writing it directly to a potentially-vulnerable terminal emulator. In the default Qubes OS configuration, for example, there are qrexec services like `qubes.WindowIconUpdater` that any qube can call in dom0. An attacker who gains control of an untrusted qube could inject data containing malicious terminal control sequences into `/var/log/qubes/qrexec.*.log` in dom0. If the user views that log in a terminal emulator in a way that doesn't filter terminal escape codes (by simply using `cat` on the file, for example), the malicious data might then exploit a hypothetical bug in the terminal emulator. Note that this attack scenario, as described, has several layered requirements: 1. The user must voluntarily open a log file containing malicious data (or otherwise take action that causes the log file data to be parsed). 2. There must exist an independent vulnerability in the user's terminal emulator or in whichever program parses the log. (In other words, the attacker must chain independent vulnerabilities together.) 3. If using a terminal emulator, a command-line tool that does not filter control codes must be used. (`journalctl` prevents the display of unsafe sequences by default, but many other tools do not.) To be clear, the scenario in which the attacker uses the `qubes.WindowIconUpdater` service in order to exploit a hypothetical bug in a terminal emulator is just one conceivable scenario for how an attacker might exploit the vulnerability described in this bulletin. It is not the only way in which this vulnerability could be exploited, and the requirements listed for this scenario may not necessarily apply to other scenarios featuring different types of attacks (for example, using other qrexec services and exploiting other software that handles log output). Rather, this example is merely intended as an aid for understanding the nature of the vulnerability. Discussion ----------- Qubes OS features a framework known as "qrexec," which allows different qubes to communicate with each other in a controlled manner.  These interactions are restricted by the system's RPC policies.  In particular, qrexec can be used to allow less trusted qubes to communicate with more trusted qubes, including dom0. Normally, the calling side can send data to the remote services' standard input and receive its standard output, standard error, and exit code data. Since it handles untrusted data flows, qrexec is designed under the assumption that an adversary will use it in order to launch an attack against one qube from another qube. Therefore, qrexec treats incoming data as untrusted and carefully sanitizes it. For example, when qrexec output is connected to a terminal, `qrexec-client` and `qrexec-client-vm` remove terminal control sequences. However, due to a mistake in qrexec message type handling, the calling side can send data marked as "standard error" (`MSG_DATA_STDERR`), and the remote side will print it to the standard error of the process handling incoming qrexec connections. This data flow was not expected. Such messages should be rejected, as they are expected only in the other direction. Consequently, this data is not appropriately sanitized, and potentially-malicious data may end up in log output. Credits -------- This issue was discovered by Demi Marie Obenour. References -----------  https://www.qubes-os.org/doc/testing/  https://www.qubes-os.org/doc/how-to-update/  https://www.qubes-os.org/doc/qrexec/  https://www.qubes-os.org/doc/qrexec-internals/  https://www.qubes-os.org/doc/rpc-policy/ -- The Qubes Security Team https://www.qubes-os.org/security/