Chyba umožňuje odemknout xscreensaver

Chyba CVE-2015-8025 umožňuje shodit xscreensaver odpojením kabelu od jednoho z monitorů, pokud jich máte více. Poté se objeví odemčená obrazovka s plným přístupem. Podobné chyby jsou například CVE-2014-1949 a deset let stará CVE-2006-0062. Bohužel stále nejsou opraveny…

30.10.2015 22:00 | Jendа | Bezpečnostní upozornění

Komentáře

[Jendа]

Tady je dobře vidět rozdíl v návrhu Linuxu a bezpečných systémů, například železničních zabezpečovacích zařízení. Takové zabzař má defaultně tu nejméně permisivní návěst a aktivně se mu tam musí posílat permisivnější a pokud se tento signál ztratí, přejde zase do bezpečného stavu (například „stůj“). Oproti tomu Linux, pokud se mu ztratí screensaver, nepřejde do stavu „obrazovka je zamčena a nelze odemknout, protože chcípnul odemykací proces“. On přejde do stavu „odemčeno“. I ta debilní Windows 2000 to měla líp.

Další zajímavost je, že o této chybě se ví již deset let (CVE-2006-0062), ale stále ji nikdo neopravil. Skoro to vypadá jako nějaké spiknutí tajných agentur.

Proč se vůbec řeší neexistence bezpečného hardware, když stejně neexistuje software, který by na něm šel provozovat?

[Spike]

A ještě se někteří vztekají, že jim chtěj rozbít hračku a pod Waylandem jim nebude moct číst každá pochybná aplikace vstup z klávesnice a snímat obrazovku... :)

[sonicpp]

Toto mě vždycky zajímalo. Jak tedy bude fungovat aplikace na snímání obrazovky, která snímá stiskem nějaké klávesové zkratky. Dejme tomu, že hraju ve fullscreenu nějakou hru a chci ji blejsknout, jak se rozliší pochybný software, který nemá focus a čte všechny klávesy a snímač obrazovky, který snímá klávesu, aby mohl vyfotit obrazovku? Z tvého příspěvku navíc chápu, že i to snímání obrazovky bude nějak omezeno...

[Spike]

Tak zrovna (současné) hry mají typicky ukládání snímků obrazovky implementováno v sobě, takže není potřeba ani globální klávesová zkratka, ani extra aplikace, která by snímala celou obrazovku (protože tou aplikací je sama hra).

Globální klávesové zkratky a snímky desktopu je potřeba řešit na úrovni compositoru, který má tohle na starosti.

Global shortcut handling in a Plasma Wayland session | Martin's Blog

[Spike]

Ještě přidám Wayland compositors - Why and how to Handle privileged clients! (Updated on the 2014/02/21) - mupuf.org

[sonicpp]

Díky

[Jendа]

Třeba bude možné dát jí předem oprávnění. Stejně, jako v QubesOS - můžeš přidělit aplikaci síť, mikrofon, kameru, přístup k souborům, přístup k obrazovce, přístup ke schránce a další věci.

[Heron]

QubesOS - můžeš přidělit aplikaci síť, mikrofon, kameru, přístup k souborům, přístup k obrazovce, přístup ke schránce a další věci

Geniální. Takto se to řeší na jednouživatelských systémech, tablech a mobilech. Proč to tahat na PC s GNU/Linuxem?

[Jendа]

Protože nikdo nebyl schopen implementovat ten existující způsob bezpečně?

(teda po dnešní díře umožňující vylámat se z Xenu už ani ten QubesOS nevypadá neprolomitelně…)

[Heron]

Jakto že ne? Původně jsem chtěl dopsat oddělení uživatelů, jmené prostory procesů apod, ale myslel jsem, že to není třeba. Jako já nemám pocit, že by procesy odděleného uživatele mohly zasahovat do mých souborů nebo paměti mých procesů. To by byl jiný řev, než že se po (fyzickém přístupu a odpojení kabelu) zhroucení xscrsaveru někdo dostane na (mou) plochu.

Takže to někdo byl schopen implementovat bezpečně a to už hodně dlouho do minulosti. Jen se to dneska (bůh ví proč) nepoužívá

[Radek Miček]

Jako já nemám pocit, že by procesy odděleného uživatele mohly zasahovat do mých souborů nebo paměti mých procesů.

Bohužel, jádro je plné chyb, tudíž to lze.

[Heron]

ano

Tobě fakt musel Linux provést něco opravdu hrozného, když s ním spojuješ xscreensaver

[Jendа]

Ne, fakt se mi nic nestalo. A ze systémů co jsem potkal mi přijde nejlepší.

když s ním spojuješ xscreensaver

Beru to jako sadu aplikací pro desktop. Mám tomu říkat GNU/Linux nebo GNU/X.org/GTK/QT/Linux? Samozřejmě pokud se budeme bavit jenom o jádru, tak tam to vypadá docela v pořádku. Ale jenom jádro asi provozuje málokdo. Pokud by existovala nějaká alternativa k aplikacím, o kterých se mluví, tak bych neřekl ani popel. Ale místo X.org si můžeš vybrat experimentální Wayland a místo xscreensaveru si můžeš nainstalovat gnome-screensaver nebo xtrlock, které fungují úplně stejně. (níže někdo píše, že KDE5 to nějak hlídá, to je dobře)

[Heron]

Aby někdo mohl odpojit monitor od pc, tak u něj musí být fyzicky přítomen. Tedy i kdyby byl xscreensaver nebo xorg v pořádku, tak stále má útočník možnost fyzického útoku na pc (zapojit usb, fireware, odpojit a zmrazit ram modul, nebo vytáhnout disk). Vyřešením bezpečnosti xscreensaveru proti útoku vytažení hdmi kabelu se tedy (skoro) nic nezlepší. Naopak, bezpečnost se výrazně zlepší, pokud uživatel má svá data na disku šifrovaná a před opuštěním stanice všechny své procesy ukončí (a vymaže io cache).

[Jendа]

USB by nemělo umožnit kompromitaci, FW ani PCIe s IOMMU taky ne, ale PCIe mám dost hluboko vevnitř a FW nemám. Disk je šifrovaný. Zbývá ti coldboot, což jde řešit a) TRESORem, b) třeba SoCy mají paměti připájené na desce, Apple taky, c) u poloviny testovaných modulů se to prostě z neznámého důvodu nepovedlo.

[Heron]

Mno

Moje deska měla IOMMU default vypnuté (stejně jako jsou by default stále vypnuté funkce virtualizace na intelech a fůra dalších věcí). IEEE 1394 má standardně DMA. TRESOR imho není ve vanile.

Takže to vlastně nevadí, protože si ze stejných důvodů jistě odpojuješ hdmi ještě před lock screen .

[Josef Kufner]

Podstatný faktor při takových útocích je čas. Pokud si někdo odběhne od zamknutého počítače na oběd, těžko dělat coldboot útok tak, aby si toho po návratu nevšimnul. Pokud ale stačí odpojit kabel k tomu, abych mu tam přiinstaloval něco pěkného, je útok docela snadno proveditelný: Odpojím kabel, odemkne se desktop, vložím flashku do USB, spustím binárku (nespustí se to samo), odpojím USB, zamknu desktop. Je potřeba jen pár minut času v nestřežený okamžik.

[Heron]

No dobře, tohle je pravda, ale otázkou je, zda v takovém (fyzickém) prostředí potom vůbec ten komp provozovat.

Nevím jak kdo, ale já nechávám komp klidně odemčený i s přihlášeními na roota. Proto, že všichni přítomní ve stejné místnosti pracujeme pro stejnou věc a pokud bych zjistil, že někdo mé stanice zneužil k něčemu nekalému, tak bych v takovém prostředí stejně nadále nepracoval (nehledě na to, že všichni dotyční mají více (a skrytějších) příležitostí, jak se na toho admina dostat).

[Josef Kufner]

Pokud by takový útok byl úspěšný, tak by jsi to nezjistil. Otázkou také je, zda do takové místnosti nemá přístup i někdo s nekalými úmysly, který vůbec nemusí být součástí tvého týmu.

[Hans1024]

+1

Kdyz ma nekdo fyzicky pristup k PC, tak se proti nemu proste branit neda. Bud clovek lidem, u kterych neco necha, veri a pak nema cenu neco zamykat, a nebo jim neveri, tak proc je sakra nechavat v jedne mistnosti s mymi vecmi? Me to zamykani obrazovky pripada stejne divne, jako mit zamek na flasce s pitim, aby mi tam nahodou nekdo neco neprimychal...

[Jendа]

Kdyz ma nekdo fyzicky pristup k PC, tak se proti nemu proste branit neda.

Pokud máš na PCIe IOMMU a nějak pořešené RAMky proti vyčtení (případně máš klíče přímo na čipu), tak mě moc útoků nenapadá.

a nebo jim neveri, tak proc je sakra nechavat v jedne mistnosti s mymi vecmi

Dunno. Lidi u nás ve škole nebo v hackerspace si počítače na záchod neberou, takže je prostě nechají zamčené. Kromě instalace rootkitu od náhodných kolemjdoucích se asi bojím ještě policejní razie.

[Hans1024]

Kdyz maji ti lidi pristup do mistnosti, tak je taky milion zpusobu, jak muzou odchytnout heslo, kterym si ten screen unlocknes.

Ja teda nevim, co to je za nahodne kolemjdouci, co instaluji rootkity. Pokud ma na tom zajem nejaka spolecnost/organizace, tak ty podle dostupnych informaci vetsinou nepristoupi k najimani fyzickych osob, co sahaji na HW, pokud jdou pouzit mene rizikove metody (remote exploit) a musis pro ne byt zatracene dulezity, aby to vyssi riziko podstoupily. Pokud jsi pro nekoho zatracene dulezity, tak jsi v pr..., pokud ne, tak se bud pohybujes kolem totalnich posuku, nebo jsi paranoidni.

U policejni razie to zamykani alespon trochu smysl dava, za predpokladu ze s sebou maji nekoho kompetentniho. Zase ale pokud bych si myslel, ze mi realne hrozi nejaka razie, tak bych se radeji sbalil a vypadl, nez abych zil ve stresu.

[Josef Kufner]

Další use-case je, že notebook je jen uspaný do paměti, má šifrovaný disk a je ukraden/ztracen. Pokud útočník rebootne, ztratí klíče z paměti a je to v pohodě. Do té doby stojí mezi ním a daty jen zamknutý desktop. Pokud je zámek spolehlivý, zbývá cold boot a podobné věci, na které má útočník jeden pokus a slušnou šanci na selhání. Druhá možnost je zahodit před uspáním šifrovací klíče (luks suspend/resume), ale stejnak bude v paměti dost citlivých dat, to už je lepší uspání na disk.

[Bystroushaak]

Kdyz ma nekdo fyzicky pristup k PC, tak se proti nemu proste branit neda.

To je samozřejmě blbost. Máš spoustu počítačů*, kde je tohle přímo jedním z požadavků a bránit se samozřejmě dá. Je to jen o tom, že v současnosti se tímhle směrem moc lidí neubírá.

*Například v knihovně jsou to čtecí terminály, odkud nesmí být možné odnést elektronické knihy. Při studiu proprietárních zdrojáků windows jsou na univerzitách podobné počítače, kde máš zakázané USB a zamknutou skříň, aby nebylo možné si zdrojáky odnést a tak dále.

[Heron]

Kdyz ma nekdo fyzicky pristup k PC

vs.

zamknutou skříň

Tak nevím

[Bystroushaak]

Co nevíš? Skříně se dají zamykat na zámek, aby nešly otevřít. Ve firmách je to docela standard, když už kvůli ničemu jinému, tak aby z toho nikdo nemohl ukrást třeba polovinu RAM. K počítači stále máš fyzický přístup, můžeš do něj strkat flashdisky a firewire a psát na klávesnici, jen se prostě nedostaneš jednoduše do bedny.

[Heron]

Tak znovu:

Kdyz ma nekdo fyzicky pristup k PC, tak se proti nemu proste branit neda.

To je samozřejmě blbost.

vs.

zamknutou skříň

Je mi přišlo podivné, že nejprve označíš jako blbost "fyzický přístup a nedá bránit útoku (na hw)" a hned o odstavec níž navrhuješ fyzické omezení přístupu k PC pro zamezení útoku (na hw). Čímž vlastně potvruješ něco, co sám vyvracíš.

[Bystroushaak]

Možná to bude tím, že není fyzické omezení přístupu, jako fyzické omezení přistupu, že. Pokud mezi tím nevidíš rozdíl, asi nemá smysl dál pokračovat v diskuzi.

[pc2005]

Například v knihovně jsou to čtecí terminály, odkud nesmí být možné odnést elektronické knihy.

Fotce monitoru to ale nebrání že?

aby nebylo možné si zdrojáky odnést a tak dále

A pak přijde někdo takovej.

[Bystroushaak]

Fotce monitoru to ale nebrání že?

Fotka monitoru se nepovažuje za (plnohodnotnou) kopii. To by měl už o dost jednodušší si tu knížku prostě koupit a oscannovat. Pointa je, že tady jsou těch knížek tisíce a prostě se nemají nechat odnést.

[pc2005]

U knížek možná (jde si na tom terminálu přečíst knížku bez účtu v knihovně?). V případě security by obscurity zdrojáků (nebo psaného hesla kde jsou vidět hvězdičky) to nebude dobrej nápad.

[pc2005]

Tak mě napadlo, jak moc EM vyzařujou PCIe (nebo SATA) sběrnice.

[Bystroushaak]

Tak mě napadlo, jak moc EM vyzařujou PCIe (nebo SATA) sběrnice.

Pořád víc EM vyzařuje samotný monitor. Viz třeba Tempest for Eliza. Jenže to bys musel mít možnost tam v nečem programovat. Hm. Možná v JS by se dalo.

[Bystroushaak]

U knížek možná (jde si na tom terminálu přečíst knížku bez účtu v knihovně?).

Já popravdě ani nevím, nikdy jsem to neviděl, jen jsem slyšel co to má umět a nemá a tak.

[nupac]

tvoje starosti-najdi si ženskou

[tom]

Aby někdo mohl odpojit monitor od pc, tak u něj musí být fyzicky přítomen. Tedy i kdyby byl xscreensaver nebo xorg v pořádku, tak stále má útočník možnost fyzického útoku na pc (zapojit usb, fireware, odpojit a zmrazit ram modul, nebo vytáhnout disk). Vyřešením bezpečnosti xscreensaveru proti útoku vytažení hdmi kabelu se tedy (skoro) nic nezlepší.

Slysel jste uz o X terminalu? Pristup k X serveru nutne neznamena pristup k pocitaci, kde dany SW bezi.

[Jendа]

Proč když řeknu, že tady dělají řízky připálené, a že vedle je dělají takovým způsobem tak a tak lépe, tak mi hned provedli něco hrozného?

[Heron]

To nevím, ale do restaurace, kde podle mě dělají řízky spálené, bych pravděpodobně už nikdy nepřišel (ve skutečnosti již nechodím do restaurací, kde jsem se setkal s mnohem menšími prohřešky).

[Jendа]

Jenže tady jiná restaurace není, navíc všichni okolo dodávají příbory fungující především v této restauraci.

[Rad]

proto jsem se naucil varit a pribory si dlabu ze dreva, neasi :)

[Jendа]

Ano, taky jsem přemýšlel o tom, že se na IT vykašlu (napsat vlastní OS a dostat ho do produkce je pro mě nemožné, navíc mi návrhy architektury fakt strašlivě nejdou, takže bych to ani neuměl).

[Josef Kufner]

Zrovna jsem si zkusil v KDE5 sestřelit proces, který zamyká obrazovku. Proces jsem mnohokrát úspěšně zabil, ale na desktop se nedostal. Nějaký ksmserver ten zámek pořád držel a ochotně zamykající proces restartoval. To nejlepší, co jsem z toho dostal byla černá obrazovka asi na sekundu. Když jsem zabil ksmserver, session skončila. Asi to s tou bezpečností nebude tak marné.

[R]

KDE to ma vyriesene uz davno - aj "blbe stare" KDE 3.5 (dnes Trinity) - ked spadne proces zamykajuci obrazovku, session sa ukonci.

[tom]

A jak to souvisi s Linuxem, todle mi prijde jako problem, kterej je ciste v X. Navic se da resit celkem trivialne tak, ze se vymeni SIGCHLD poslany zamykatkem obrazovky za SIGKILL (toto kernel podporuje) a kdyz pak zamykatko nahodou zhebne, tak to odstreli cela Xka.

[Jendа]

A jak to souvisi s Linuxem, todle mi prijde jako problem, kterej je ciste v X.

Pokud máš FSF definici, že Linux je kernel, tak nijak. Zajímalo by mě, jak kolekci běžně používaného software tvořícího desktop či server používající systémové služby linuxového jádra říkáš ty.

Navic se da resit celkem trivialne tak, ze se vymeni SIGCHLD poslany zamykatkem obrazovky za SIGKILL (toto kernel podporuje)

Super, jak? Rychlé googlení to nenašlo.

[tom]

A jak to souvisi s Linuxem, todle mi prijde jako problem, kterej je ciste v X.

Pokud máš FSF definici, že Linux je kernel, tak nijak. Zajímalo by mě, jak kolekci běžně používaného software tvořícího desktop či server používající systémové služby linuxového jádra říkáš ty.

Debian

Navic se da resit celkem trivialne tak, ze se vymeni SIGCHLD poslany zamykatkem obrazovky za SIGKILL (toto kernel podporuje)

Super, jak? Rychlé googlení to nenašlo.

man clone: The low byte of flags contains the number of the termination signal sent to the parent when the child dies.

[Jendа]

Debian

To by se na mě zase sesypali, že ta chyba je přece i jinde.

man clone: The low byte of flags contains the number of the termination signal sent to the parent when the child dies.

Tak když už si budu patchovat desktop (u mě xfce4-session), aby to vyrobilo ten proces takhle, tak si už můžu přidat i ten handler na sigchld… Pak je ještě problém v těch některých dalších CVE, kde locker nezhebnul, ale podařilo se ho hodit do pozadí.

[tom]

Debian

To by se na mě zase sesypali, že ta chyba je přece i jinde.

Kdyz pouzivam Debian, tak me zajima zejmena to, jestli ta chyba je v nem.

man clone: The low byte of flags contains the number of the termination signal sent to the parent when the child dies.

Tak když už si budu patchovat desktop (u mě xfce4-session), aby to vyrobilo ten proces takhle, tak si už můžu přidat i ten handler na sigchld…

Jste si vedom toho, ze SIGCHLD neni v linuxu "queued signal" a tudiz pri ukonceni vice potomku pred zavolanim handleru bude handler informovan pouze o jednom z nich? Ja jen abyste si tam neudelal race condition...

[pet I.]

Hmmmm, za já si už rok lámu hlavu proč mi pythoní program při současném pádu dvou dětí restartne jen jedno, a ono je to o patro výš, v kernelu. Hmmm, no to teda fakt nevím co s tím budu dělat....

[petr_p]

Všechny zombíky lze posbírat pomocí while (r = wait(-1, &status, WNOHANG), r != 0 && r != -1);

[tom]

Pri vytvareni procesu si muzete vyzadat zaslani queued signalu. A priste misto hledani chyby ve svem kodu venovat nejaky cas i RTFM

[pc2005]

Taky by mě to zajímalo. Zatím mě napadlo jen použití LD_PRELOAD (pokud to tedy jde).

[Lol Phirae]

kolekci běžně používaného software tvořícího desktop či server

On dneska někdo běžně používá xscreensaver? OMG k čemu? Ta xscreensaver hovadina je asi 15 let mrtvá, nechápu, proč to ještě není z distribucí odstraněno.

[Martin Mareš]

Budete se divit, ale používají a docela dost

[Jendа]

OMG k čemu?

K zamykání obrazovky? Ale to je jedno, všechna ostatní zamykátka, co jsem viděl (xlock, xlockmore, gnome-screensaver, nějaká věc v Compizu…), měla úplně ten stejný bug. Podle toho, co se píše v této diskuzi, to má správně implementováno jen KDE.

To „běžně používaný software“ se ale nevztahovalo na xscreensaver, ale na X.

[xorly]

Jaký význam má řešit zabití *locku? To už útočník stejně musí mít přístup do terminálu a pak mu Xko může být někde...

[tom]

Prijde mi, ze jste vubec nepochopil diskutovany problem. Jde o to, aby se sezeni ukoncilo, pokud zamykaci obrazovka havaruje. Pokud je jako zamykatko pouzit xscreensaver (ktery po odpojeni vystupu havaruje), muze utocnik jeho pad pouzit ke vstupu do sezeni. V pripade, ze by se ukoncilo i sezeni, neziska utocnik pristup k systemu.

[Jendа]

Přesně tak.

(případně sezení může zůstat běžet zamčené - pokud by Xka implementovala nějaký LOCK flag - a opravit se to může z jiné konzole, kde se pustí DISPLAY=:0 můj-unlock)

[xorly]

Problém jsem pochopil. Reagoval na špatný příspěvek. Šlo o některý výše, kde dotyčný zmiňoval, jak je lock proces v KDE odolný vůči SIGKILL, že se nastartuje nová instance a nic se neděje. Není mi jasné jaký význam takový test měl. Jnak třeba i3lock se při odemknutí ukončí, zde by asi zmíněné řešení nešlo použít, ale to jen na okraj.

[tom]

Zrejme tak testoval, co se stane po padu zamykatka v KDE5. Mohl tak napriklad simulovat OOM zabijaka, ktery take pouziva SIGKILL. I kdyz se samozrejme vybizi otazka, zda by se v pripade nedostatku pameti podarilo process znovu spustit. Proto ja povazuji za vhodnejsi v tom pripade ukoncit cele sezeni.

[Josef Kufner]

Při zabití zamykátka se desktop neodemknul. Prostě chvilku jen černá obrazovka a desktop nikde. Tedy GUI, které se stará o odemykání není součástí samotného zámku. Při zabití rodiče tohoto zamykátka, tedy procesu, který nejspíš ten zámek držel, se session opravdu ukončila. Nevím jak přesně to je implementované, ale vypadá to bytelně.

[Jendа]

Lock může spadnout z důvodu špatného HW, může ho sestřelit OOM killer (to měl teď Android, do lock screeny šlo pořád dokola copypastovat a tím exponenciálně zvětšovat držený text), nebo je v něm chyba, kvůli které nepřežije změnu rozlišení plochy za chodu (o tom je zprávička)

[Lol Phirae]

a bezpečných systémů, například železničních zabezpečovacích zařízení

No, to sis aktuálně vybral výbornej příklad... :-P

[Lexnar]

Taky jsem si rikal - opira se o to prave diky ty nehode, ve stylu "vyjimka potvrzuje pravidlo", nebo o tom fakt nevi.

[Ondrej Santiago Zajicek]

Oproti tomu Linux, pokud se mu ztratí screensaver, nepřejde do stavu „obrazovka je zamčena a nelze odemknout, protože chcípnul odemykací proces“

To ma jednoduche a vcelku prirozene reseni - zamykat obrazovku rovnou procesem window manageru.

[Jendа]

Spíš session/Xek. V Xfce po pádu WM okna jenom ztratí dekoraci a nejde s nimi hýbat.

Ano, má to jednoduché řešení. Akorát ho nikdo neimplementoval. (resp. z komentáře výše jsem se dozvěděl, že už to umí KDE)

[Ondrej Santiago Zajicek]

Bezny postup je v ramci X session pouzit exec na spusteni WM, takze pad WM je pad X session. A i kdyz se exec nepouzije, tak blokujici spusteni WM je posledni krok v ramci X session, takze jeho skoncenim X session dobehne a ukonci se. Tedy alespon v pripade, kdy X session je bezny shellovy skript. Netusim, jak je to v pripade ruznych X session manageru, tam by na tom musely spolupracovat oba.

[kyknos]

Ze je screensaver bezpecnostni dira rikam snad uz deset let a zatim na me vetsinou koukali divne. Jsem rad, ze to nekdo vidi stejne.

[pc2005]

Podle mě uvažovat, že je screensaver zabezpečení je trochu mimo. Co když útočník přijde o 10 sekund dřív a zahýbe myší (a screensaver se tak neaktivuje)? Zodpovědný uživatel, pokud opustí stanici, tak by se měl odhlásit a ne to nechávat na timeoutu (vím je to nereálný požadavek).

Mají moderní laserové myši citlivost na ultra(/infra)zvukové vlnění stolu?

[kyknos]

vsak pokud na tom zalezi, muzes ho aktivovat sam nebo pockat, az se aktivuje

odhlasovat se je neprakticky nepohodlne, zvlast kdyz od pocitace odchazis casto

[pc2005]

No v některých situacích se to asi může hodit, ale to nic nemění na tom, že kompletní ukončení session je víc bezpečnější než jen blokování některých vstupů a výstupů počítače.

[kyknos]

no a jeste bezpecnejsi je ten pocitac zamknout do trezoru - ale nejde o dokonale zabezpeceni, ale o bezny uzivatelsky scenar - navic viz nize, doma se mi obvykle nepohybuji hackeri, ale pratelsti lide, kocka... presto clovek nechce, aby se screensaver jen tak odemknul nebo prestal fungovat, kocka a vim dokazi neuveritelne veci...

[pc2005]

Já bych řekl, že Jendovi o dokonalé zabezpečení jde . Aneb: já s tebou souhlasím:

Ze je screensaver bezpecnostni dira

Z mého pohledu by se navíc screensaver vůbec neměl považovat za bezpečností aplikaci (= o stupeň vyšší nároky).

BTW proti kočce by mohlo stačit pouhé přepnutí na jiný fyzický terminál, než jsou xka. BTW^2 Existuje nějakej session lock pro fyzickou textovou konzoli?

[Jendа]

BTW^2 Existuje nějakej session lock pro fyzickou textovou konzoli?

Třeba screen to umí.

[Mrkva]

vlock. s parametrem -a to znemozni i prepinani konzoli, take s trochou stesti to bude fungovat i na zamceni Xek.

[pc2005]

Thx zajímavý.

[tom]

vlock. s parametrem -a to znemozni i prepinani konzoli, take s trochou stesti to bude fungovat i na zamceni Xek.

Stestim myslite treba zakazanou magic sysrq? vlock-nosysrq je jistejsi (nebo -s).

[Mrkva]

No nevim, ja mam povoleny jen reboot, RO mount a sync.

[kyknos]

navic bezpecnost se netyka jen situaci s _utocniky_ v pravem slova smyslu - staci i scenar typu porno na obrazovce vs male dite, nebo nakup vanocniho darku vs obdarovany pobliz apod. a problem je nejen pad screensaveru, ale prinejmensim v nekterych konfiguracich jeho pomala aktivace - tzn. sahnes na mys, obrazovka se rozsviti s nechranenym obsahem (i kdyz je zamcena), a az za par sekund se obraz prekryje screensaverem

[Bystroushaak]

Podle mě uvažovat, že je screensaver zabezpečení je trochu mimo. Co když útočník přijde o 10 sekund dřív a zahýbe myší (a screensaver se tak neaktivuje)?

Já si poslední dobou říkám, že by bylo dobré mít RFID prsten, který je snímán senzorem na vzdálenost třeba dvou metrů. Automaticky by ti pak zamykal obrazovku, když ten prsten nenajde.

Samozřejmě, i tohle by šlo obejít (např. RFID wormhole), ale už by to nebylo tak jednoduché a většinu problémů by to mohlo řešit.

[kyknos]

tu kocku by to zrovna vubec neresilo

[Josef Kufner]

Tohle jde udělat pomocí Bluetooth s telefonem, nebo libovolným jiným zařízením. Nástrojů je na to povícero. Prostě se čas od času koukne, zda dané zařízení je v dosahu a pokud ne, tak se desktop zamkne.

[Bystroushaak]

Hm. To asi stojí za pokus. Dávám do todo.

[pc2005]

BT je na to dost špatný protokol (zvlášť pokud se bude jen sledovat existence). Udělat fake zařízení je triviální.

[Bystroushaak]

Tak samozřejmě, že by to muselo jít o krok dál, než jen kontrolovat, jestli není v okolí daná MAC adresa. Stačí jednoduchý challenge-response protokol s hashováním sdíleného tajemství a náhodných dat.

[Jendа]

Co když útočník přijde o 10 sekund dřív

Já když odcházím, tak screensaver aktivuju ručně. Mám na to klávesovou zkratku.

Zodpovědný uživatel, pokud opustí stanici, tak by se měl odhlásit

To je dost nepraktické, protože mám většinou spoustu otevřených věcí.

[pc2005]

Já když odcházím, tak screensaver aktivuju ručně. Mám na to klávesovou zkratku.

To by šlo, ale to už spíš není automatický screensaver, jako zamknutí session. Ten screensaver je už jen vedlejší efekt.

To je dost nepraktické, protože mám většinou spoustu otevřených věcí.

V opravdu bezpečném systému by to bylo triviální. Odhlášení by mohlo být prostě uložení stavu virtuálního stroje.

[Jendа]

Ten screensaver je už jen vedlejší efekt.

Jasně. Taky jsem měl dlouho jako screensaver černou obrazovku (teď jsem si napsal RobCo PIP-Boy 2000).

[Spike]

V opravdu bezpečném systému by to bylo triviální. Odhlášení by mohlo být prostě uložení stavu virtuálního stroje.

Co když potřebuješ, aby i zamčený stroj na pozadí něco dělal?

[pc2005]

Tak by bylo víc úrovní: zamknout, uložit část a zbytek nechat jako démon, uložit všechno, hibernace. Problém je, že pokud chceš, aby "za" screensaverem (nebo i zámkem), ještě něco běželo, tak se ti pak může stát tohle.

Taky by bylo vtipný nechat zapnutou webkameru v prohlížeči, takže druhá strana vidí jak se přihlasuješ.

[Spike]

Každej správnej místní paranoik má beztak kameru přelepenou černou izolačkou, ne?

A nepřišlo mi, že by (vestavěné) kamery zabíraly klávesnici.

[pc2005]

Já mám svoji (externí) webkameru odpojenou .

To asi většinou ne i když asi bude záviset na úhlu otevření notebooku. Minimálně můžeš odhadnout délku hesla a přibližnou lokaci kláves. Každopádně pokud bude zaplej mikrofon, tak můžeš klávesy slyšet a to už je normální odposlouchávací metoda.

[Jendа]

Taky by bylo vtipný nechat zapnutou webkameru v prohlížeči, takže druhá strana vidí jak se přihlasuješ.

Jednu dobu jsem měl obrazovku vypadající nezamčeně a když se ji někdo pokusil použít, začlo to hrát Flying Toasters a poslalo to fotku na IRC.

Chytil jsem se já a kamarád.

[pc2005]

[petr_p]

Podobné chyby jsou například CVE-2014-1949 a deset let stará CVE-2006-0062.

Odkazované chyby nejsou chyby xscreensaveru.

[Jendа]

Všechny tři chyby jsou v Xkách. Vysvětluje to článek odkazovaný v poslední větě.

[petr_p]

Článek? Já tam vidím jen citaci z hlášení o chybě, pak tři odkazy a tři odstavce, ve kterých se pisatel rozčiluje, jak je to hrozné.

Navíc žádná z těch chyb není v X. Jedna je v xlockmore, druhá v GTK a ta poslední v xscreensaveru.

Přijde mi, že někdo nepochopil XGrabKeyboard(). Pokud to tak děsně vadí, není problém přidat třetí hodnotu argumentu keyboard_mode, takže pokud se klient odpojí před zavoláním XUngrabKeyboard(), server se ukončí.

[Jendа]

Navíc žádná z těch chyb není v X. Jedna je v xlockmore, druhá v GTK a ta poslední v xscreensaveru.

Ne, chyba je v X, že nemá "locked" flag nebo něco podobného, a tak musí lidí, co píšou zamykátko, dělat nestabilní hacky přes kradení klávesnice a výrobu superoken.

Pokud to tak děsně vadí, není problém přidat třetí hodnotu argumentu keyboard_mode, takže pokud se klient odpojí před zavoláním XUngrabKeyboard(), server se ukončí.

Proč to vůbec nikdo neimplementuje?

[Ondrej Santiago Zajicek]

IMHO je chyba uz v predstave, ze bezny program muze bezpecne locknout konzoli. Idealne by veskere 'full-screen style' operace byly 'virtualizovane' a pod kontrolou WM, takze WM by mohl nabizet klavesove zkratky, ktere by je overridovaly. Tedy zamknuti konzole je operace, za kterou musi byt zodpovedny primo WM jako 'spravce konzole'.

[petr_p]

Protože desktopáci mají na práci důležitější věci jako třeba vypínat Ctrl-Alt-Backspace nebo ignorovat DPI výstupního zařízení.

[Matlák]

Teď jsem to vyzkoušel na své slack mašině, zapnul Xscreensaver 5.15, zobrazil dialog pro zadání hesla, odpojil HDMI a nic. Plocha se ani nezmenšila, obě strany (obě X screeny) zůstaly dále dostupné, i když ta druhá strana jen poslepu (pochopitelně). Řekl bych že je to chyba konfigurace (za každou cenu dynamické). Já všude používám statické konfigurace. A ty druhé dvě zmíněné CVE mě nechávají úplně chladnými, jelikož se týkají mainstreamových DE které naštěstí nepoužívám.

[Jendа]

xlock je součástí nějakého mainstreamového WM?

Smysl odkazování na ta CVE ale nebyl v tom, abychom si plivli na FVWM/xlock/GNOME, ale v tom, abychom se zamysleli: „Může se podobná chyba objevit i v jiném WM?“ A na to je odpověď ano.

[Matlák]

Chyba s xlock je zmiňovaná v souvislosti s fvwm (i když to uznávám není tak úplně mainstream), zranitelnost prostředí cinnamon využívá chyby v celkem hojně používaném DE a ano, z mé strany šlo o mimo jiné nemístný plivanec na adresu mainstreamových WM/DE.

Každopádně jsem chtěl především upozornit, že to CVE-2015-8025 rozhodně neznamená, že všechny GNU/Linux mašiny na světě co používají dva a více monitorů v kombinaci s xscreensaver jsou (byly celou dobu) zranitelné takto triviálním způsobem. Žádný z mých strojů (a to všechny xscreensaver a více monitorů používají) není tímto způsobem zranitelný a ani nikdy nebyl.

[Matlák]

Jinak to zamyšlení na téma "bezpečnost v desktopovém GNU/Linuxu v mainstreamových distribucích" je nasnadě mnohem spíš, ale to se týká komplexně celého userspace a návrhu systému a to je v téhle situaci IMHO akademická diskuse. Zavírat aplikace do VM s vlastním rootem a různě mezi nimi posílat zprávy je spíš vrchol zoufalých pokusů o řešení fundamentálně špatných bezpečnostních vlastností počátečního návrhu userspace na GNU/Linuxové platformě.

[Dirka]

https://www.jwz.org/xscreensaver/changelog.html

Fixed a crash when hot-swapping monitors while locked.

Ten RH bug je vuci 5.33 to jen tak, aby se nereklo, ze kluci na tom nemakaj aspon trosku ... nemuze to aspon zpravicka zminit? Nebo se pletu a je to jeste jinej bug?