They discovered a vulnerability in xterm that leads to code execution

Recently the news broke that a vulnerability was found in the xterm terminal emulator (already cataloged under CVE-2022-45063), the problem allows executing shell commands when certain escape sequences are processed in the terminal.

About the problem it is mentioned that is due to an error in the processing of escape code 50 which is used to set or get font options. If the requested font does not exist, the operation returns the name of the font specified in the request.

The problem is in the OSC 50 sequence, which is for configuring and consulting the fountain. If a given source does not exist, it is not set, but a query will return the name that was set. Control characters cannot be included, but the response string can be terminated with ^G. East essentially gives us a primitive to return the text to the terminal and ending with ^G.

Control characters cannot be inserted directly in the name, but the returned string can be terminated with the sequence "^G", which in zsh, when vi-style line edit mode is active, causes a list expansion operation to be performed, which can be used to execute commands without explicitly pressing the Enter key.

For an attack in the simplest case, it is enough to display the content of a specially designed file on the screen, for example, using the cat utility, or pasting a line from the clipboard.

Debian, Red Hat and others disable font operations by default , but users can re-enable them through an option or configuration menu. Also, upstream xterm does does not disable them by default, so some distributions include a vulnerable default setting.

To successfully exploit the vulnerability, the user must use the Zsh shell with the command line editor (vi-cmd-mode) changed to "vi" mode, which is generally not used by default in distributions.

Basically, we need:
zsh
active line edit mode in vi style
copy the trojan's text to the clipboard
paste it in zsh

This can be done automatically, many sites modify the text when it is copied to the clipboard. So I only use the selection buffer, which is not accessed by browsers. Only in gtk3 and in ff in particular do they constantly break for some reason, it's exhausting.

The problem also does not appear when xterm is set to allowWindowOps=false or allowFontOps=false. For example, the configuration allowFontOps=false it is set on OpenBSD, Debian, and RHEL, but is not enforced by default on Arch Linux.

According to the change log and the statement of the researcher who identified the issue, the vulnerability fixed in xterm 375 version, but according to other sources, the vulnerability continues to manifest itself in Arch Linux's xterm 375.

This means that to exploit this vulnerability, the user must be
using Zsh in vi line edit mode (usually via $EDITOR which has "vi" in
it's). While somewhat obscure, this is not entirely unheard of.
configuration.

In that configuration, something like:
printf "\e]50;i\$(touch /tmp/hack-like-its-1999)\a\e]50;?\a" > cve-2022-45063
cat cve-2022-45063 # or another way to deliver this to the victim

Finally, as always, users of affected systems are advised to keep their systems up-to-date, since as they will know when security vulnerabilities are known, developers must fix these flaws, because much of how these flaws can be exploited is disclosed.

It is worth mentioning that font operations are not allowed in the default settings of xterm of some Linux distributions, so not all distributions are prone to this bug. For those interested in following the publication of corrections by distributions, they can do so on these pages: Debian, RHEL, Fedora, SUSE, Ubuntu, Arch Linux, OpenBSD, FreeBSD y NetBSD.

If you are interested in knowing more about it, you can check the details In the following link.