Sie entdeckten eine Schwachstelle in xterm, die zur Ausführung von Code führt

Kürzlich haben die Nachrichten das verbreitet Im xterm-Terminalemulator wurde eine Schwachstelle gefunden (bereits unter CVE-2022-45063 katalogisiert), das Problem ermöglicht das Ausführen von Shell-Befehlen wenn bestimmte Escape-Sequenzen im Terminal verarbeitet werden.

Über das Problem wird das erwähnt ist auf einen Fehler bei der Verarbeitung des Escape-Codes 50 zurückzuführen die verwendet wird, um Schriftartoptionen festzulegen oder abzurufen. Wenn die angeforderte Schriftart nicht vorhanden ist, gibt die Operation den Namen der in der Anforderung angegebenen Schriftart zurück.

Das Problem liegt in der OSC 50-Sequenz, die zur Konfiguration und Beratung dient der Brunnen. Wenn eine angegebene Quelle nicht existiert, wird sie nicht gesetzt, sondern eine Abfrage gibt den eingestellten Namen zurück. Steuerzeichen können nicht sein enthalten, aber der Antwortstring kann mit ^G abgeschlossen werden. Ost gibt uns im Wesentlichen ein Primitiv, um den Text an das Terminal zurückzugeben und endet mit ^G.

Steuerzeichen können nicht direkt eingefügt werden im Namen, aber der zurückgegebene String kann mit der Sequenz "^G" abgeschlossen werden, was in zsh, wenn der Zeilenbearbeitungsmodus im vi-Stil aktiv ist, bewirkt, dass eine Listenerweiterungsoperation ausgeführt wird, die verwendet werden kann, um Befehle auszuführen, ohne explizit die Eingabetaste zu drücken.

Für einen Angriff im einfachsten Fall Es reicht aus, den Inhalt einer speziell entworfenen Datei anzuzeigen auf dem Bildschirm, beispielsweise mit dem cat-Dienstprogramm, oder durch Einfügen einer Zeile aus der Zwischenablage.

Debian, Red Hat und andere deaktivieren Font-Operationen standardmäßig , aber Benutzer können sie wieder aktivieren über ein Options- oder Konfigurationsmenü. Auch Upstream xterm tut dies deaktiviert sie nicht standardmäßig, daher enthalten einige Distributionen a Anfällige Standardkonfiguration.

Um die Schwachstelle erfolgreich auszunutzen, Der Benutzer muss die Zsh-Shell verwenden, wobei der Befehlszeilen-Editor (vi-cmd-mode) in den „vi“-Modus geändert wurde, das in Distributionen im Allgemeinen nicht standardmäßig verwendet wird.

Grundsätzlich benötigen wir:
zsh
aktiver Zeilenbearbeitungsmodus im vi-Stil
Kopieren Sie den Text des Trojaners in die Zwischenablage
füge es in zsh ein

Dies kann automatisch erfolgen, viele Websites ändern den Text, wenn er in die Zwischenablage kopiert wird. Ich verwende also nur den Auswahlpuffer, auf den Browser nicht zugreifen. Nur in gtk3 und insbesondere in ff brechen sie aus irgendeinem Grund ständig ab, es ist anstrengend.

Das Problem tritt auch nicht auf, wenn xterm auf eingestellt ist allowWindowOps=false oder allowFontOps=false. Zum Beispiel die Konfiguration allowFontOps=false Es ist auf OpenBSD, Debian und RHEL eingestellt, wird aber nicht standardmäßig auf Arch Linux erzwungen.

Laut dem Änderungsprotokoll und der Aussage des Forschers, der das Problem identifiziert hat, ist die Schwachstelle in xterm 375-Version behoben, Anderen Quellen zufolge manifestiert sich die Schwachstelle jedoch weiterhin in Xterm 375 von Arch Linux.

Dies bedeutet, dass der Benutzer diese Schwachstelle ausnutzen muss
Verwenden von Zsh im vi-Zeilenbearbeitungsmodus (normalerweise über $EDITOR, das "vi" enthält
es ist). Dies ist zwar etwas obskur, aber nicht völlig unbekannt.
Konfiguration

In diesem Setup so etwas wie:
printf "\e]50;i\$(touch /tmp/hack-like-its-1999)\a\e]50;?\a" > cve-2022-45063
cat cve-2022-45063 # oder eine andere Möglichkeit, dies dem Opfer zu übermitteln

Schließlich wird den Benutzern betroffener Systeme wie immer empfohlen, ihre Systeme auf dem neuesten Stand zu halten, denn wie Sie wissen werden, wenn Sicherheitslücken bekannt werden, müssen Entwickler diese Fehler beheben, da viel davon offengelegt wird, wie diese Fehler ausgenutzt werden können.

Es lohnt sich das zu erwähnen Font-Operationen sind in den Standardeinstellungen von nicht erlaubt xterm von einige Linux-Distributionen, Daher sind nicht alle Distributionen anfällig für diesen Fehler. Wer daran interessiert ist, die Veröffentlichung von Korrekturen durch Distributionen zu verfolgen, kann dies auf diesen Seiten tun: Debian, RHEL, Fedora, SUSE, Ubuntu, Arch Linux, OpenBSD, FreeBSD y NetBSD.

Wenn Sie daran interessiert, mehr darüber zu erfahrenkönnen Sie die Details überprüfen im folgenden Link.