Es ist mal wieder soweit, der halbe Desktop (Linux) Planet ist in Gefahr, naja, fast đ
Das Problem
Der Cinnamon-Screensaver 3.4.1-1 lockt den Bildschirm nicht mehr, wenn er soll. Das öffnet natĂŒrlich fatale SicherheitslĂŒcken in allen Bereichen, denn wenn der Bildschirmschoner angeht, lockt sich auch i.d.R. der Bildschirm, so daĂ ein Anderer den PC nicht ĂŒbernehmen kann. Steht man nun von seinem Platz auf, gibt man mit der 3.4.1-1 die Kontrolle ĂŒber seinen PC auf.
Und so beheben wir das Problem fĂŒr Fedora
ZunÀchst öffnen wir eine ROOT Konsole, als User geht es leider nicht zu beheben. Dann entfernen wir als Root das Paket von PC :
Nun editieren wir noch die /etc/dnf/dnf.conf und tragen bei „exclude“ „exclude=cinnamon-screensaver*“ ein, andernfalls wird der screensaver gleich wieder geupdated, wenn der nĂ€chste Cronjob dafĂŒr lĂ€uft.
Jetzt melden wir den aktuellen Benutzer vom Desktop ab und gleich wieder an. Das war es dann auch schon.
Bei Fedora ist ein entsprechender Bugreport am laufen, so daà mit einem Fix in den nÀchsten Tagen zu rechnen ist.
Update 26.6. 2017:
Leight Scott hat schnell reagiert und ein neues Paketupdate gepusht, welches das Problem behebt. Wer also cinnamon-screensaver in der dnf.conf gesperrt hat, kann die Sperre wieder aufheben.
ZunĂ€chst installieren wir einmal das Paket „blueproximity“ via „dnf install blueproximity“ .
Wenn das Programm gestartet wird, suchen wir uns zunÀchst einmal das BlueTooth GerÀt aus, das als Trigger dienen soll:
Danach sollte man den Kanal auswĂ€hlen auf dem das BT Protokoll arbeiten soll. Ein Status „benutzbar“ ist empfehlenswert đ
Danach setzen wir die Alarmparameter auf die uns genehmen Werte. Die Distanz Ihres verbundenen Handies wird Ihnen ganz unten angezeigt. Mit 127 ist aber nicht 127 Meter gemeint, sondern „ist komplett auĂer Reichweite / ist aus“ und „0“ ist direkt in der NĂ€he. Daher sollte man nur Entsperren, wenn das Handy im direkten Umfeld ist, also „0“ und „1“ fĂŒr die min. Sperrendistanz, sobald man sich bewegt. Die Zeit ist natĂŒrlich die Dauer dieses Zustandes, so kann man z.b. durch das BĂŒro gehen ohne das gleich der Bildschirm gesperrt wird.
Um sich mal eine Vorstellung von den Distanzwerten zu machen, der Wert „1“ wurde meinem Laptop angezeigt, als mein Handy bereits 3 m Luftlinie weg war, um die Ecke einer Wand mit vielen ElektrogerĂ€ten. Dieser Wert dĂŒrfte also ruhig etwas empfindlicher berechnet werden .
In der „Sperren“ Optionen können wir die Sperrkommandos fĂŒr den Screensaver angeben. Die Kommandos die dort bereits drinstehen sind fĂŒr Gnome 2, also nicht mehr brauchbar. Unten habe ich die neuen DBUS Kommandos gepostet, mit denen man Sperren und entsperren kann.
Das Entsperrkommando ist allerdings nicht perfekt. Es entsperrt zwar den Bildschirm, man muĂ das Passwort also nicht mehr angeben, aber der Bildschirm bleibt dunkel. Sobald man die Maus bewegt, kann man aber weiterarbeiten.
Sollte man sein Handy verloren haben ;), kann man sich natĂŒrlich auch ganz normal mit Passwort einloggen.
Im TOP-Icon-ContextmenĂŒ des Programms kann man es auch temporĂ€r abschalten. Das macht aus GrĂŒnden des Energiesparen natĂŒrlich viel Sinn, besonders beim Handyakku.
Mitarbeit
Wenn Ihr VorschlĂ€ge habt, wie man den Screensaver nicht nur freischaltet, sondern auch gleich Bildschirm wieder sichtbar macht, dann hinterlaĂt einen Kommentar. Den richtigen Tip werde natĂŒrlich in den Text aufnehmen.
Obwohl es heute Mode ist, jedem noch so kleinen Securitybug einen eigenen Namen zugeben, verzichte ich mal drauf. Ich hatte ja einigen Wochen geschrieben, daà es eine FD Veröffentlichung geben wird. Nun, heute ist es soweit : )
Der Fehler ist endlich gefixt, auch wenn die UmstĂ€nde komisch erscheinen werden. Der ganze Ablauf ist ohnehin merkwĂŒrdig, es gibt nicht mal eine CVE dazu. Fangen wir mal vorn an, am 18. November 2013 !
Mein Laptop hatte damals Fedora 18 mit einem Gnomedesktop drauf und wurde alle zwei Stunden aktualisiert, war also auf Stand. Das Laptop wurde nicht gebraucht und in den Suspend gebracht, als es dann wieder aufwachte, sah ich immer noch das Desktopfenster mit Inhalt, dann einige Sekunden spĂ€ter poppte der Screensaver auf und ich muĂte mich einloggen. Ok. Man sieht den Bildschirm, obwohl man das nicht sollte, war jedenfalls meine Meinung. Ich probiert es nochmal, aber diesmal lief alles normal ab, der Screensaver sprang diesmal deutlich eher an und man sah nichts. MerkwĂŒrdig.
SicherheitslĂŒcke: Informationdisclosure
Langer Rede kurzer Sinn, je nach Situation beim Abschalten des Laptops ins Disksuspend regiert es etwas anders beim Hochfahren. Ein Race zwischen den Prozessen findet statt und wenn der Screensaver das gewinnt, dann sieht man nichts, ansonsten dauert es lange und der Bildschirminhalt wird kurz sichtbar.
Am Mittwoch den 20. November habe ich dann ein Video gedreht auf dem man das sehen kann und einen Securitybugreport bei Fedora und Gnome erstellt. Nachdem die das Video gesehen hatten und nach der Hardware gefragt haben, lehnte man das Problem als irrelevant ab, weil die Hardware ja „nicht die schnellste“ wĂ€re. Argumentieren, daĂ das Prinzip mit dem Screensaver ja wohl klar falsch ablĂ€uft und das vor dem Suspend gemacht werden muĂ, half nichts. Taube Ohren.
3 Jahre spÀter
Letzten Dezember habe ich ein neues Laptop von der Firma bekommen. Mittlerweile gab es Fedora 23, man beachte 5 Versionen = 5*6 Monate spĂ€ter đ und der Bug sollte ja nicht mehr auftreten, weil I5 und SSD. Also … Deckel zu, warten, Deckel wieder hoch … und ????? BINGO.. der Desktopinhalt! Zwar nur fĂŒr ein paar Augenblicke, also deutlich schneller weg als bei dem alten Laptop, aber da.
Der Bug war bei Fedoraim Tracker immer noch als ungelöst offen. Nun gab es keine Entschuldigung mehr, denn die HW ist schnell, ganz besonders beim Umgang mit Disksuspend. Da mir 3 Jahre als deutlich zu lange fĂŒr so ein triviales Problem erschienen, habe ich einen FD Timer von 90 Tagen angesetzt, bis zu dem das Problem gefixt sein muĂte.
Endlich gut, alles gut ?
Fast. Es wurde behoben, allerdings als Silentupdate, sprich, man hat es keinem erzĂ€hlt. Nicht mal dem Bugreporter. Ich habe nur durch regelmĂ€Ăiges ausprobieren bemerkt, daĂ es endlich behoben wurde.
Bleibt zu vermerken, nicht alle SicherheitslĂŒcken werden sofort behoben, auch wenn durch so eine InformationslĂŒcke Inhalte vom Desktop in fremde HĂ€nde gelangen. Da könnten Bankdaten zusehen sein, Listen mit Namen von Menschen die nicht gefunden werden dĂŒrfen, der private Key vom Server .. tausend Dinge die man nicht sehen sollte, wenn keiner in der NĂ€he ist um es zu verhindern. Der Angreifer kann den Laptoprechner nach dem Test einfach wieder ins Suspend schicken und keiner merkt es.
Kleines Goodie am Ende ? Hier noch ein Gnome 3 Bug Desktop Hack den ich gemeldet hatte. Der wurde allerdings binnen einer Woche behoben, was bei dem Impact wohl auch kein Wunder ist.
