Securitybug in Gnome – fast 3 Jahre bis zum Fix

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.

Hier die beiden Videos im Youtubeplayer:

 

1 Milliarde US Doller geklaut

Der Zentralbank von Bangladesh wurde knapp 1 Milliarde US Dollar geklaut, weil einfach mal automatische Anweisungen und Abbuchen der US FED durchgeführt werden, ohne das dies jemand prüft. 870 Mio. Dollar konnten zurück gebucht werden, bevor die Täter es verflüssigen konnten. Am Ende sind die Täter mit 80 Mio. davon gekommen. Der Coup wurde fast 8 Monate lang eingefädelt.

Der Lacher ist aber, daß der Finanzminister von Bangladesh das aus der Zeitung erfahren hat 😀

Quelle: Heise.de

Jabbermeldungen von der Konsole schicken

Normalerweise geht man davon aus, daß Jabber/XMPP-Clienten von Menschen bedient werden. IM macht ja nur sinn, wenn jemand anderen was schicken will. Dieser Andere muß aber nicht notwendigerweise ein Mensch sein, ein Server tut es natürlich auch.

„SendXMPP“ heißt der Befehl. Das in Perl geschriebene Script ist nicht ganz fehlerfrei, aber dafür kommt es mit TLS Unterstützung, was es sympathisch macht, da so die Verbindung zum eigentlichen Jabberserver brav verschlüsselt wird.

echo "Das sieht aus, wie eine normale Nachricht auch aussieht." | sendxmpp -n -t  -u "Shell.Bot" -j xmpp.server.de -p 02332dfs09329324jfd  Ziel@xmpp.server.de

Da die Eingaben von STDIN angenommen werden oder von einer Datei stammen dürfen, kann man das Script praktisch an so alles ranstöpseln, was Statusinformationen loswerden will. Das geht soweit, daß man es über Webseiten z.b. zum Senden von Kundennachrichten an den Support benutzen kann.

Jetzt fehlt eigentlich nur noch eine Shelllösung zum Abchecken, ob das Ziel überhaupt online ist. Damit könnte man dann den Livechat auf der Webseite ausgrauen, wenn niemand erreichbar ist. Da Jabberclienten i.d.R. beliebig viele JabberAccounts verwalten können, hat man natürlich richtig viele gute Möglichkeiten hierarchisch strukturiert Kundensupport zu leisten und auch verschiedene Quellen bei Personen zusammen zu führen.

Anmerkung: Die Config von sendxmpp liest die „derzeit“ aktuelle Version leider nicht sauber ein, deswegen die Parameter. Im Prinzip kann man die aber an einen Linux-Useraccount binden und muß die dann nicht mehr eingeben.

Fehlermeldungen:

„Use of uninitialized value in string eq at /usr/bin/sendxmpp line 515
Error ‚AuthSend‘: [?]“

Wer die findet, sollte die Parameter für Usernamen/Server/Passwort in die Kommandozeile verlagern.