libVTE visszagörgetési puffer probléma miatt érzékeny adatok szivároghatnak ki

( trey | 2012. 03. 12., h - 13:48 )
Bug

Mark Krenz nemrég egy, a libVT 0.21.6-os és újabb verzióiban jelen levő, biztonsági problémát okozó tervezési hiányosságra hívta fel a figyelmet. Mivel a libVTE által implementált virtual terminal widget-et számos terminal emulátor - pl. gnome-terminal, terminator, xfce4-terminal, guake, evilvte, lilyterm, sakura, termit - használja, a probléma érinti ezeket a szoftvereket. A problémás commit-ot 2009. szeptember 7-én követte el Behdad Esfahbod. Krenz 2011. novemberében fedezte fel a fenti videón demonstrált hibát, majd hibabejelentést tett a GNOME Bugzilla-ba. Szintén jelezte a hibát Behdad Esfahbod-nak is, aki nem válaszolt a megkeresésre. Közben kiderült, hogy korábban már Daniel Gillmor felhívta Esfahbod figyelmét erre a gondra, de akkor Esfahbod azt közölte, hogy már nem szándékozik a jövőben fejleszteni a libVT-t.

A probléma teljes leírása itt.

( andrewjsi | 2012. 03. 12., h - 14:11 )

A betyárját... akkor ezért kerreg a winyóm, miközben ssh-val távoli gépen véletlenül cat-olok egy több száz megás logot :)

0 szavazat

( saxus | 2012. 03. 12., h - 15:28 )

"pl. gnome-terminal, terminator, xfce4-terminal, guake, evilvte, lilyterm, sakura, termit"

:) Ilyenkor jó, hogy Az Nagy Linuxos Változatosság az esetek 99%-ában kimerül a libek elé tolt frontendek változatosságában.

----------------
Lvl86 Troll

0 szavazat

Felhasználói szempontból majdnem mindegy, ráadásul van egy pár nem libvte-s terminál is.
Azt nem tudom, hogy ebből mennyire lehet következtetéseket levonni más szoftvereket illetően. Az tény, hogy a médialejátszók elég nagy százaléka gstreamer vagy phonon, bár felteszem windowson se írja meg mindenki a saját kodekjeit meg minden mást, ami ehhez kell.

0 szavazat

( locsemege (veterán) | 2012. 03. 12., h - 17:05 )

Azért most eltűnődtem azon, hogy teszem azt, valahol jelszót vár a rendszer, a fókusz a terminálon van, figyelmetlenül becsépelem a jelszót, enter, s máris a bash history-ba íródott. Aztán history -c, de attól még a HDD-n ott van felülírásig.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

0 szavazat

A bash nem azonnal írja ki a history-t, hanem kilépéskor. Ha véletlenül begépelek parancsként egy jelszót, reflexszerűen adom ki utána a "kill -9 $$" parancsot: a bash-t saját magát öletem meg úgy hogy esélye se legyen elmenteni a history-t. (Igen, a többi begépelt parancs is elvész, ez az ára.)

0 szavazat

Lehet, hogy elég, nem tudom. Sosem használtam ezt az opciót. A manuál alapján tök nem egyértelmű számomra, hogy az egész .bash_history fájlt gyakja felül (semmiképp sem szeretném), vagy csak a futó shell által eddig memóriába rakott bejegyzéseket. Ki kéne próbálni, előtte backup, nincs hozzá kedvem. Részemről azért kill -9, mert ez létező, máshol is használt, általam már ismert formula, tudom hogy mit csinál, tudom hogy azt csinálja atombiztosan amit szeretnék, nem kell hozzá se tanulni, se utánajárni, se gondolkodni, és kétségeim sincsenek hogy mi van ha félreértem, mi van ha bugos lenne stb. A history -c -re ezek egyike sem igaz, utána kéne járni, meg kéne ismerni, most még nem is vagyok benne biztos hogy jó lenne nekem, valszeg igen, de akkor is nem éri meg a belefektetendő utánajárást. Szerintem.

0 szavazat

Kipróbáltam. Az aktuális shell történelmét törli. Felnyíl utána nem ad semmit, ugyanakkor az eddigi .bash_history megmarad. A shellből kilépve, újra elindítva a régi history elérhető.

Nekem a SIGKILL-el történő gyilkolászás eléggé ellenszenves. Elvarratlan szálak maradhatnak, nyitott file-ok, inkonzisztens állapot. Én csak szükség esetén nyúlok ehhez a barbár megoldáshoz.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

0 szavazat

Én is kipróbáltam, nekem legyakta az egész korábbi historyt. Pont erről beszéltem. Hogy nem tudhatom. A doksiból nem derül ki, bash verziónként vagy beállításonként változhat, kiismerhetetlen az összejátszása a többi éppen futó és később bezárandó bash process historymentésével stb.

A sigkilltől félsz, mert nem ismered. Nem maradnak elvarratlan szálak, sem nyitott fájlok, sem inkonzisztens állapot. Persze ha akkor nyírsz ki egy folyamatot amikor épp dolgozik valami fájlon, akkor az inkonzisztens maradhat az alkalmazás szemszögéből, de ha a bash-t saját magát saját magából lövöd ki, akkor nyilvánvalóan semmiféle függőben lévő fájlműveletet nem végezhet akkor.

0 szavazat

( wladek1 | 2012. 03. 12., h - 18:07 )

Ha jok a megerzeseim, akkor csak a sajat gepemen tudom ezt reprodukalni.
Nalam minden titkositott particion van; a gepet pedig zarolni szoktam.

0 szavazat

( Nyosigomboc (veterán) | 2012. 03. 12., h - 19:28 )

Asszem csinalok egy hasonlo videot, felteszek egy VM-be valamit, unlimited-re allitom a scrollback meretet, cat-olok valami jo nagy dolgot, es megmutatom, hogy a swaprol is kiolvashato (ugyanugy rendszergazdakent), esetleg a kcore-bol (na, onnan tuti).
Inkabb megsem, mert most nincs kedvem.

--
R2D2 a filmtörténet legmocskosabb szájú karaktere.
Minden szavát kisípolták.

1 szavazat

( gabim | 2012. 03. 12., h - 20:04 )

~$ ldd /usr/bin/xfce4-terminal | grep vte
libvte.so.9 => /usr/lib/libvte.so.9 (0x00007fb44f10b000)
~$ ldd /usr/bin/gnome-terminal | grep vte
libvte2_90.so.9 => /usr/lib/libvte2_90.so.9 (0x00007fbedfa57000)
~$ ldd /usr/bin/konsole | grep vte
~$

0 szavazat

Viszont ez nem a VTE-s probléma, hanem egy saját fejlesztés, ez már egy másik problem ticket. :)
Annyira viszont nem triviális ez a fajta issue, hogy a "Testing and reproducing the issue"-ban leírtakkal tetten lehetne érni csak úgy.
A többi emulátor fejlesztőinek viszont most főhet a feje, mert Esfahbod már nem szándékozik a jövőben fejleszteni a libVT-t, tehát valaki másnak kell a hibát orvosolni. A konsole ezzel szemben egy elég virulens közösség eléggé központi eleme, vélhetően hamar orvoslásra kerül a probléma benne.

Upd.: úgy tűnik, a konsole csak akkor érintett, ha unlimited-re van állítva a scrollback. 10000-es scrollback-nél nem jön létre ilyen temp file a /tmp-ben. http://linux.slashdot.org/comments.pl?sid=2714201&cid=39288993

0 szavazat