Detekterede en sårbarhed i xterm, der fører til kodekørsel

For nylig brød nyheden det der blev fundet en sårbarhed i xterm-terminalemulatoren (allerede katalogiseret under CVE-2022-45063), problemet tillader udførelse af shell-kommandoer når visse escape-sekvenser behandles i terminalen.

Om problemet nævnes det skyldes en fejl i behandlingen af ​​escape-kode 50 som bruges til at indstille eller få skrifttypeindstillinger. Hvis den anmodede skrifttype ikke findes, returnerer handlingen navnet på den skrifttype, der er angivet i anmodningen.

Problemet er i OSC 50-sekvensen, som er til konfiguration og rådgivning springvandet. Hvis en given kilde ikke eksisterer, er den ikke sat, men en forespørgsel returnerer det navn, der blev angivet. Kontroltegn kan ikke være inkluderet, men svarstrengen kan afsluttes med ^G. Øst i det væsentlige giver os en primitiv til at returnere teksten til terminalen og slutter med ^G.

Kontroltegn kan ikke indsættes direkte i navnet, men den returnerede streng kan afsluttes med sekvensen "^G", som i zsh, når vi-stil linjeredigeringstilstand er aktiv, bevirker, at der udføres en listeudvidelsesoperation, som kan bruges til at udføre kommandoer uden eksplicit at trykke på enter-tasten.

For et angreb i det enkleste tilfælde, det er nok at vise indholdet af en specialdesignet fil på skærmen, for eksempel ved at bruge katteværktøjet eller indsætte en linje fra udklipsholderen.

Debian, Red Hat og andre deaktiverer skrifttypeoperationer som standard , men brugere kan genaktivere dem gennem en valgmulighed eller konfigurationsmenu. Det gør upstream xterm også deaktiverer dem ikke som standard, så nogle distributioner inkluderer en Sårbar standardkonfiguration.

For at kunne udnytte sårbarheden, brugeren skal bruge Zsh-skallen med kommandolinjeeditoren (vi-cmd-tilstand) ændret til "vi"-tilstand, som generelt ikke bruges som standard i distributioner.

Grundlæggende har vi brug for:
zsh
aktiv linjeredigeringstilstand i vi-stil
kopier trojanerens tekst til udklipsholderen
indsæt det i zsh

Dette kan gøres automatisk, mange websteder ændrer teksten, når den kopieres til udklipsholderen. Så jeg bruger kun udvælgelsesbufferen, som ikke er tilgået af browsere. Kun i gtk3 og især i ff går de konstant i stykker af en eller anden grund, det er udmattende.

Problemet vises heller ikke, når xterm er sat til allowWindowOps=falsk eller allowFontOps=falsk. For eksempel konfigurationen allowFontOps=falsk det er indstillet på OpenBSD, Debian og RHEL, men håndhæves ikke som standard på Arch Linux.

Ifølge ændringsloggen og erklæringen fra den forsker, der identificerede problemet, er sårbarheden rettet i xterm 375 version, men ifølge andre kilder fortsætter sårbarheden med at manifestere sig i Arch Linux's xterm 375.

Det betyder, at brugeren skal være det for at udnytte denne sårbarhed
ved at bruge Zsh i vi-linjeredigeringstilstand (normalt via $EDITOR, som har "vi" i
det er). Selvom det er noget uklart, er dette ikke helt uhørt.
konfiguration.

I den opsætning, noget som:
printf "\e]50;i\$(touch /tmp/hack-like-its-1999)\a\e]50;?\a" > cve-2022-45063
cat cve-2022-45063 # eller en anden måde at levere dette til offeret

Endelig anbefales det, som altid, brugere af berørte systemer at holde deres systemer opdateret, for som du vil vide, når sikkerhedssårbarheder er kendt, skal udviklere rette disse fejl, fordi meget af, hvordan disse fejl kan udnyttes, afsløres.

Det er værd at nævne det skrifttypeoperationer er ikke tilladt i standardindstillingerne for xterm af nogle Linux-distributioner, så ikke alle distributioner er tilbøjelige til denne fejl. For dem, der er interesseret i at følge offentliggørelsen af ​​rettelser efter distributioner, kan de gøre det på disse sider: Debian, RHEL, Fedora, SUSE, Ubuntu, Arch Linux, OpenBSD, FreeBSD y NetBSD.

Hvis du er interesseret i at vide mere om det, kan du kontrollere detaljerne I det følgende link.