Plötzlich in der Session des Anderen – und das, ohne sein Kennwort zu kennen. Was der Traum des Hacker ist, ist der Albtraum des Sicherheitsbeauftragten. Was ist also zu tun, wenn man unverhofft in eine solche Situation gerät?
Zunächst einmal ist eine solche Situation derart selten, dass es sich für mich lohnte, mir die Augen zu reiben um festzustellen, dass ich nicht träume.
Der erste ernsthafte Schritt ist das Reproduzieren, also das Nachvollziehen aller Schritte die nötig sind, um den Effekt zu erzielen. Im vorliegenden Fall sind es sieben Schritte:
- Erzeuge zwei neue Benutzer (
user1
unduser2
) - Bearbeite die Datei
/etc/gdm/custom.conf
und schalte das timed login für den Benutzeruser2
ein, in dem in der Sektion[daemon]
die folgenden Eintragungen gespeichert werden:
Mit diesem Eintrag wird der Gnome Display Manager (GDM) so konfiguriert, dass der Login-Dialog automatisch nach 10 Sekunden den Benutzer[daemon]
TimedLoginEnable=true
TimedLogin=user2
TimedLoginDelay=10user2
anmeldet, wenn bis dahin niemand einen eigenen Login-Prozess eingeleitet hat – d. h. entweder angefangen hat einen Benutzernamen einzugeben oder einen Benutzer aus der Liste gewählt hat. - Starte den Rechner neu.
- Melde Dich als Benutzer
user1
an. - Sperre den Bildschirm.
- Wähle "als anderer Benutzer anmelden", um erneut in den Login-Dialog zu gelangen.
- Warte, bis der TimedLogin ausgelöst wird oder wähle den Benutzer
user2
- Es wird die Sitzung für den Benutzer
user1
entsperrt und nicht eine neue Sitzung für den Benutzeruser2
gestartet.
Nun muss noch die Software-Version des GDM festgestellt werden, damit eine vernünftige Fehlermeldung formuliert werden kann. Die aktuell eingesetzte Version des GDM ist in der Datei /usr/share/gnome/gnome-version.xml
gespeichert. Im vorliegenden Fall war es die Version 3.28.2 der Ubuntu 18.04 Distribution.
Eine weitere Frage ist, wohin wird dieser Fehler gemeldet, der die Sicherheit des Systems betreffen kann. Auf der Gnome Webseite ist als Adresse Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein! angegeben. Schon wenige Stunden nach der ersten E-Mail kam kam Antwort mit Nachfragen über bestimmte Systemkonfigurationen und der Bitte das Debugging einzuschalten und das Log einer Fehlerreproduktion zu senden. Weil es zunächst so schien, dass der Fehler nicht reproduziert werden konnte, weil dort ein Fedora 29 benutzt wurde, setzte ich noch schnell eine virtuelle Maschine mit dieser Distribution auf. Hier war die GDM Version 3.31.3. Aber auch hier konnte der Fehler nachvollzogen werden – auch unter Ubuntu 18.10. nachdem der Fehler auch bei den Entwicklern reproduziert werden konnte, dauerte es noch einen weiteren Tag, bis ein entsprechender Issue mit der Nummer 460 in der Gnome-Fehlerdatenbank angezeigt- und direkt an einer Lösung gearbeitet wurde. Zwischenzeitlich tauchte auch ein Eintrag in der CVE (Common Vulnerability and Exposure) in der National Vulnerability Database (NVD) des National Institute of Standards and Technology (NIST) auf.
Ich wurde über den Fortgang der Fehlerbeseitigung auf Nachfrage informiert. Bereits drei Tage später wurde die Fehlerbeseitigung in das Gnome GDM-Repository gespeichert, und nach den obligatorischen Tests wurden entsprechende Patches für die einzelnen Distributionen von denen bereitgestellt. Die gesamte Fehlerbeseitigung hat nicht länger, als zwei Wochen gedauert. Eine Leistung, mit der sich andere Softwarehersteller sehr schwer tun.