De upptäckte en sårbarhet i xterm som leder till kodexekvering

Nyligen bröt nyheten ut det en sårbarhet hittades i xterm terminalemulatorn (redan katalogiserad under CVE-2022-45063), problemet tillåter exekvering av skalkommandon när vissa escape-sekvenser bearbetas i terminalen.

Om problemet nämns att beror på ett fel i bearbetningen av escape-kod 50 som används för att ställa in eller hämta teckensnittsalternativ. Om det begärda teckensnittet inte finns returnerar operationen namnet på det teckensnitt som anges i begäran.

Problemet ligger i OSC 50-sekvensen, som är för konfigurering och konsultation fontänen. Om en given källa inte finns är den inte inställd, utan en fråga returnerar namnet som ställts in. Kontrolltecken kan inte vara det ingår, men svarssträngen kan avslutas med ^G. Öst ger oss i huvudsak en primitiv att returnera texten till terminalen och slutar med ^G.

Kontrolltecken kan inte infogas direkt i namnet, men den returnerade strängen kan avslutas med sekvensen "^G", som i zsh, när vi-stil linjeredigeringsläge är aktivt, gör att en listexpanderande operation utförs, som kan användas för att utföra kommandon utan att explicit trycka på enter-tangenten.

För en attack i det enklaste fallet, det räcker med att visa innehållet i en specialdesignad fil på skärmen, till exempel genom att använda kattverktyget eller klistra in en rad från urklippet.

Debian, Red Hat och andra inaktiverar typsnittsoperationer som standard , men användare kan återaktivera dem via en alternativ- eller konfigurationsmeny. Det gör också uppströms xterm inaktiverar dem inte som standard, så vissa distributioner inkluderar en Sårbar standardkonfiguration.

För att framgångsrikt utnyttja sårbarheten, användaren måste använda Zsh-skalet med kommandoradsredigeraren (vi-cmd-läge) ändrad till "vi"-läge, som vanligtvis inte används som standard i distributioner.

I grund och botten behöver vi:
zsh
aktivt linjeredigeringsläge i vi-stil
kopiera trojanens text till urklippet
klistra in det i zsh

Detta kan göras automatiskt, många webbplatser ändrar texten när den kopieras till urklipp. Så jag använder bara urvalsbufferten, som inte nås av webbläsare. Bara i gtk3 och i ff i synnerhet går de ständigt sönder av någon anledning, det är ansträngande.

Problemet visas inte heller när xterm är inställd på allowWindowOps=falskt eller allowFontOps=falskt. Till exempel konfigurationen allowFontOps=falskt den är inställd på OpenBSD, Debian och RHEL, men tillämpas inte som standard på Arch Linux.

Enligt ändringsloggen och uttalandet från forskaren som identifierade problemet, sårbarheten fixad i xterm 375 version, men enligt andra källor fortsätter sårbarheten att manifestera sig i Arch Linuxs xterm 375.

Detta innebär att användaren måste vara det för att utnyttja denna sårbarhet
använder Zsh i vi-radredigeringsläge (vanligtvis via $EDITOR som har "vi" in
dess). Även om det är något obskyrt, är detta inte helt ovanligt.
konfiguration.

I den inställningen, något som:
printf "\e]50;i\$(touch /tmp/hack-like-its-1999)\a\e]50;?\a" > cve-2022-45063
cat cve-2022-45063 # eller annat sätt att leverera detta till offret

Slutligen, som alltid, rekommenderas användare av drabbade system att hålla sina system uppdaterade, för som du vet när säkerhetsbrister är kända måste utvecklare fixa dessa buggar, eftersom mycket av hur dessa buggar kan utnyttjas avslöjas.

Det är värt att nämna det teckensnittsoperationer är inte tillåtna i standardinställningarna för xterm av vissa Linux-distributioner, så alla distributioner är inte utsatta för denna bugg. För de som är intresserade av att följa publiceringen av korrigeringar efter distributioner kan de göra det på dessa sidor: Debian, RHEL, fedora, SUSE, ubuntu, Arch Linux, OpenBSD, FreeBSD y NetBSD.

Om du är det intresserad av att veta mer om detkan du kontrollera detaljerna I följande länk.