De oppdaget en sårbarhet i xterm som fører til kodekjøring

Nylig brøt nyheten det en sårbarhet ble funnet i xterm-terminalemulatoren (allerede katalogisert under CVE-2022-45063), problemet tillater å utføre skallkommandoer når visse escape-sekvenser behandles i terminalen.

Om problemet nevnes det at skyldes en feil i behandlingen av escape-kode 50 som brukes til å angi eller få skriftalternativer. Hvis den forespurte skriften ikke eksisterer, returnerer operasjonen navnet på skriften som er spesifisert i forespørselen.

Problemet er i OSC 50-sekvensen, som er for konfigurering og konsultasjon fontenen. Hvis en gitt kilde ikke eksisterer, er den ikke satt, men en spørring vil returnere navnet som ble angitt. Kontrolltegn kan ikke være det inkludert, men svarstrengen kan avsluttes med ^G. Øst gir oss i hovedsak en primitiv for å returnere teksten til terminalen og slutter med ^G.

Kontrolltegn kan ikke settes inn direkte i navnet, men den returnerte strengen kan avsluttes med sekvensen "^G", som i zsh, når vi-stil linjeredigeringsmodus er aktiv, fører til at en listeutvidende operasjon utføres, som kan brukes til å utføre kommandoer uten eksplisitt å trykke enter-tasten.

For et angrep i det enkleste tilfellet, det er nok å vise innholdet i en spesialdesignet fil på skjermen, for eksempel ved å bruke katteverktøyet, eller lime inn en linje fra utklippstavlen.

Debian, Red Hat og andre deaktiverer fontoperasjoner som standard , men brukere kan aktivere dem på nytt gjennom en alternativ- eller konfigurasjonsmeny. Det gjør også oppstrøms xterm deaktiverer dem ikke som standard, så noen distribusjoner inkluderer en Sårbar standardkonfigurasjon.

For å lykkes med å utnytte sårbarheten, brukeren må bruke Zsh-skallet med kommandolinjeredigering (vi-cmd-modus) endret til "vi"-modus, som vanligvis ikke brukes som standard i distribusjoner.

I utgangspunktet trenger vi:
zsh
aktiv linjeredigeringsmodus i vi-stil
kopier teksten til trojaneren til utklippstavlen
lim den inn i zsh

Dette kan gjøres automatisk, mange nettsteder endrer teksten når den kopieres til utklippstavlen. Så jeg bruker bare utvalgsbufferen, som ikke er tilgjengelig for nettlesere. Bare i gtk3 og i ff spesielt går de i stykker konstant av en eller annen grunn, det er slitsomt.

Problemet vises heller ikke når xterm er satt til allowWindowOps=false eller allowFontOps=false. For eksempel konfigurasjonen allowFontOps=false det er satt på OpenBSD, Debian og RHEL, men håndheves ikke som standard på Arch Linux.

I følge endringsloggen og uttalelsen til forskeren som identifiserte problemet, sårbarheten fikset i xterm 375 versjon, men ifølge andre kilder fortsetter sårbarheten å manifestere seg i Arch Linuxs xterm 375.

Dette betyr at for å utnytte denne sårbarheten, må brukeren være det
bruker Zsh i vi-linjeredigeringsmodus (vanligvis via $EDITOR som har "vi" i
det er). Selv om det er noe uklart, er dette ikke helt uhørt.
konfigurasjon.

I det oppsettet, noe sånt som:
printf "\e]50;i\$(touch /tmp/hack-like-its-1999)\a\e]50;?\a" > cve-2022-45063
cat cve-2022-45063 # eller en annen måte å levere dette til offeret

Til slutt, som alltid, anbefales brukere av berørte systemer å holde systemene sine oppdatert, for som du vil vite når sikkerhetssårbarheter er kjent, må utviklere fikse disse feilene, fordi mye av hvordan disse feilene kan utnyttes avsløres.

Det er verdt å nevne det skriftoperasjoner er ikke tillatt i standardinnstillingene for xterm av noen Linux-distribusjoner, så ikke alle distribusjoner er utsatt for denne feilen. For de som er interessert i å følge publiseringen av rettelser etter distribusjoner, kan de gjøre det på disse sidene: Debian, RHEL, Fedora, SUSE, Ubuntu, Arch Linux, OpenBSD, FreeBSD y NetBSD.

Lur interessert i å vite mer om det, kan du sjekke detaljene I den følgende lenken.