Kwesbaarheid in xterm wat lei tot kode-uitvoering wanneer sekere stringe verwerk word

'n Kwesbaarheid (CVE-2022-45063) is geïdentifiseer in die xterm-terminale emulator, wat toelaat dat dopopdragte uitgevoer word wanneer sekere ontsnapreekse in die terminale verwerk word. Vir 'n aanval in die eenvoudigste geval, is dit genoeg om die inhoud van 'n spesiaal ontwerpte lêer te vertoon, byvoorbeeld deur die kat-hulpmiddel te gebruik, of om 'n reël vanaf die knipbord te plak. printf "\e]50;i\$(raak /tmp/hack-like-its-1999)\a\e]50;?\a" > cve-2022-45063 kat cve-2022-45063

Die probleem word veroorsaak deur 'n fout in die hantering van die kode 50-ontsnapvolgorde wat gebruik word om lettertipe-opsies te stel of te herwin. As die versoekte font nie bestaan ​​nie, gee die bewerking die fontnaam wat in die versoek gespesifiseer is terug. Jy kan nie beheerkarakters direk in die naam invoeg nie, maar die teruggestuurde string kan beëindig word met die volgorde "^G", wat in zsh, wanneer vi-styl lynredigeermodus aktief is, veroorsaak dat 'n lysuitbreidingsbewerking uitgevoer word, wat kan gebruik word om opdragte uit te voer sonder om die Enter-sleutel uitdruklik te druk.

Om die kwesbaarheid suksesvol te ontgin, moet die gebruiker die Zsh-opdragdop gebruik met die opdragreëlredigeerder (vi-cmd-modus) ingestel op "vi"-modus, wat gewoonlik nie by verstek in verspreidings gebruik word nie. Die probleem verskyn ook nie wanneer die xterm-instellings allowWindowOps=false of allowFontOps=false gestel is nie. Byvoorbeeld, allowFontOps=false is op OpenBSD, Debian en RHEL gestel, maar word nie by verstek op Arch Linux toegepas nie.

Te oordeel aan die lys veranderinge en die verklaring van die navorser wat die probleem geïdentifiseer het, is die kwesbaarheid in die xterm 375-vrystelling reggestel, maar volgens ander bronne verskyn die kwesbaarheid steeds in xterm 375 van Arch Linux. U kan die publikasie van regstellings deur verspreidings op hierdie bladsye naspoor: Debian, RHEL, Fedora, SUSE, Ubuntu, Arch Linux, OpenBSD, FreeBSD, NetBSD.

Bron: opennet.ru

Voeg 'n opmerking