Software-Unsicherheit aufgrund Halbwissen

Gelegentlich sträuben sich mir die Haare (oder das, was davon übrig ist), wenn ich sehe, wie Sicherheitslücken in Software reinkommen. Dabei meine ich jetzt nicht die kleinen Fahrlässigkeiten, die dann zu Pufferüberläufen, SQL-Injections usw. führen, sondern wenn die Fehler aufgrund Halbwissen oder Oberflächlichkeit eingebaut werden und dann selbst mehrfach vorgetragene Hinweise aufgrund vermeintlichen Besserwissens übergangen werden.

Dabei geht es manchmal gar nicht um wirklich schwerwiegende Sicherheitslücken, sondern eher um die unterschätzten Kleinigkeiten, die dann nicht gleich zum CERT-Alert führen, die aber dann die Überlegungen aufdecken, die hinter den Entwürfen stecken. Interessant wird es dann, wenn es zum Streit kommt und man sieht, mit welchen abstrusen Argumentationen die Lücken verteidigt werden. Daran erkennt man dann aber, daß kein sauberes Entwurfsverfahren zugrundeliegt und wie dann die großen Fehler zustandekommen.

So ein Erlebnis hatte schon mal im Zusammenhang mit Schreibrechten im Linux-Kernel (siehe hier, hier und hier). Natürlich findet man solche Probleme im OpenSource-Bereich einfacher, einmal weil es man den Source sieht, dann aber auch weil man die Leute erreicht. Das heißt aber nicht, daß das nur im Open-Source-Bereich aufträte. Auch im kommerziellen Bereich habe ich solche Fälle schon mehrfach erlebt, z. B. hier.

Gerade bin ich wieder mal über ein Sicherheitsproblem gestolpert, diesmal in Subversion. Ich will jetzt nicht über die Entwickler herziehen, zumal Subversion ein hervorragendes Tool ist. Aber es sind Probleme, aus denen man lernen muß.

Wenn man in sicherheitsrelevantem Umfeld ein SVN-Repository betreibt, sollte man es tunlichst gegen unbefugtes Lesen und noch mehr gegen unbefugtes oder nicht nachvollziehbares Schreiben schützen.

Nun hat Subversion selbst eigentlich keine großen Sicherheitsmechanismen, es gibt prinzipiell vier Methoden der Zugriffssteuerung:

• Man kann direkt per Dateizugriff auf das Repository zugreifen. Dann hängt die Sicherheit von den Betriebssystem-Mechanismen zum Datei-Schutz ab (owner, group, permissions,…)
• Man kann per svn+ssh zugreifen, was aber letztlich nur die oben beschreibene Methode mit einer Umlenkung über SSH ist. Der Benutzer braucht einen lokalen Account (kann ein Sicherheitsproblem sein!) und die Rechte müssen wieder über das Betriebssystem mit allen Hakeleien (chmod g+s, umask,…) abgebildet.
• Es gibt einen SVN-Server mit ganz einfachem Passwort-Mechanismus.
• Es gibt die Möglichkeit, Subversion mittels Apache + WebDAV (oder anderen Servern) über HTTP und HTTPS zu betreiben. Das ist eigentlich die flexibelste Variante, die Rechte werden vom Webserver verwaltet, mit alle den Möglichkeiten und Zuckerle, die es da gibt. Da man dabei aber nicht über einen Web-Browser zugreift, sondern direkt mit dem svn-Client, ist man doch auf die Methoden beschränkt, die vom Client unterstützt werden. Das heißt, daß man auf Protokoll-Ebene zunächst ein Klartext-Passwort über HTTP-Authentication schickt, überprüfen kann man es dann, wie man will. Das dann am besten über HTTPS zum Schutz des Passwortes und der Daten.

Also ziemlich simpel, übersichtlich und eigentlich effektiv.

Man kann jetzt beispielweise einen LDAP-Server nutzen, um dann LAN-/Company-einheitliche Passworte zu verwenden um nicht für jeden Benutzer elfundzwanzig verschiedene Passworte zu halten. Pro Benutzer ein Passwort und fertig.

Der Vorteil einer solchen Konfiguration ist, daß man beim Ändern der Passworte oder Löschen eines Accounts keine vergißt. Und wenn sich der Benutzer nur ein Paßwort merken muß, dann wird er eher ein gutes Paßwort wählen, als wenn er sich ein Dutzend verschiedene merken muß (die er erfahrungsgemäß dann sowieso alle gleich setzt). Der Nachteil ist, daß man durch ein kompromittiertes Passwort gleich alle Anwendungen/Accounts des Benutzers kompromittiert hat. Wer das Passwort herausfindet, ist gleich “überall drin”. Man sollte sich aber nicht der Illusion hingeben, daß getrennte Datenbanken das Problem wirklich lösen würden, das Passwort kann ja dann trotzdem das gleiche sein.

Wie man es dreht und wendet, es ist einfach ein deftiges und gleichermaßen wohlbekanntes Problem, wenn Passworte kompromittiert werden. Das liegt so in der Natur der Sache.

Nun ist mir aufgefallen, daß der Subversion-Client dann, wenn man zum Zugriff auf ein Web-Repository (über HTTP oder HTTPS) ein Passwort verwendet, ungefragt und unbemerkt das Passwort im Klartext in ein verstecktes Verzeichnis im Homeverzeichnis ($HOME/.subversion/…) ablegt. Bei allen weiteren Zugriffen wird einem damit die Eingabe des Passwortes erspart. Man kann das zwar abschalten, indem man in der Benutzerkonfiguration (oder der für den Host unter /etc ) die Parameter store-passwords = no und store-auth-creds = no setzt. Aber das muß man zuerst einmal wissen. Und selbst wenn man es weiß, kann man es leicht vergessen, etwa wenn man auf einem neuen Rechner ist, oder mit einem System-Update die Konfigurationsdateien überbügelt wurden. Hat man dann ein firmenweites Passwort (LDAP, ADS,…), kann man sich ziemlich angreifbar machen. Keine gute Idee also. Man müßte es so machen, daß das Passwort nur auf ausdrücklichen Wunsch gespeichert wird. Manchmal gibt es irgendwelche Software im Internet, bei der der Zugang nur mit einem Passwort zugänglich ist, das alle auf der Mailingliste oder so kennen. Für solche Einfach-Security-Fälle ist es durchaus vertretbar, das Passwort abzuspeichern, weil es meist sowieso in irgendwelchen Notizen oder E-Mails im Klartext auf der Platte rumfliegt.

Jetzt bin ich keineswegs der erste, der darin ein Sicherheitsloch sieht. So, wie das schon diskutiert wurde und in den FAQ steht, waren vor mir schon mindestens 1000 andere Leute deshalb da. Schwer zu finden kann es also nicht sein. Die 1000 sind aber allesamt abgeblitzt. Man hält daran fest, das Passwort im Klartext auf die Platte zu schreiben, ohne daß der Benutzer es merkt. Man setze eben voraus, daß der Benutzer das Handbuch gelesen hat. Die alte RTFM-Überheblichkeit aus der OpenSource-Szene blüht wieder auf. Benutzerfreundlichkeit? Schutz gegen Fehlbedienung? Wer das verdammte Handbuch nicht auswendig gelernt hat, wird nicht ernst genommen.

Zwei Links wurden mir dazu noch geschickt, dieser und jener. Es ist also definitiv und erklärtermaßen so gewollt, daß der Benutzer sich selbst auskennen und aktiv dafür sorgen muß, daß sein Passwort nicht auf der Platte landet. Und das halte ich für unverantwortlich. Passworte dürfen nicht im Klartext undauffällig irgendwohin rieseln. Man lese nur mal diesen Satz:

Trust your OS to protect data on disk.

Autsch!.

Also habe ich als der 1001. das Thema aufgeriffen und darauf hingewiesen, daß man sowas nicht macht. Und dabei einige interessante Denkfehler über Sicherheit bemerkt. Die sind es, um die es mir hier geht:

• Das Argument wurde gebracht, daß es bei der HTTP-Authentifizierung nun einmal nötig sei, daß der Client dem Server das Passwort im Klartext übermittelt (ggf. über HTTPS). Wie sollte das möglich sein, wenn dem Client das Passwort nicht im Klartext zur Verfügung steht?

  Der erste Teil der Aussage ist richtig (es gibt zwar auch Challenge-Response-Verfahren, was aber nichts daran ändert, daß das Geheimnis auf Client-Seite im Klartext gebraucht wird).

  Der wesentliche Denkfehler liegt darin, die eigene Arbeitsweise der Entwickler, nämlich Passwörter lokal abzulegen, für alle Benutzer als gewollt vorausgesetzt wird. Daß ein Benutzer das Passwort jedesmal neu eingibt, wird als seltener Sonderfall abgetan.

  Erkennbar ist aber die Verwechslung/Vermischung zwischen Authentifikationsprotokoll und dem lokalen Aufbewahren des Geheimnisses.

• Es wird argumentiert, daß eine lokale Verschlüsselung oder auch nur Verschleierung nichts bringt, weil der Client es ja doch wieder lesen können muß. Prinzipiell nicht falsch, aber viele andere Programme lösen dasselbe Problem mit einem Master-Passwort. Außerdem ist die Erkenntnis darüber, daß eine Verschlüsselung nicht schützt, noch lange kein Grund, unverschlüsselt zu schreiben. Wenn’s nicht geht, läßt man es eben bleiben.
• Es kam das Argument, daß es eben nur 3 Varianten gäbe, nämlich daß beide (Client und Server) den Plaintext haben und dann etwas verschlüsselt rübergeht, oder daß der Server nur ein Hash hat, und das Passwort dann im Klartext rübergeht, oder eben was mit Public-Key. Naja, und in den ersten beiden Fällen braucht der Client eben das Geheimnis im Klartext.

  Fehler im Denkmuster.

  Zunächst mal braucht der Client in allen drei Fällen ein Geheimnis im Klartext. Ansonsten ist die Überlegung zwar nicht ganz falsch, geht aber weit an der Sache vorbei. Die Argumente beziehen sich nämlich auf das Authentifikationsprotokol, das Problem ist das lokale Abspeichern das Geheimnisses. Das sind unterschiedliche Problemstellungen und haben miteinander eigentlich sehr wenig zu tun.

• Wenn’s einem nicht gefällt, könnte man ja svn+ssh:// verwenden.

  Erstens kann der Client das nicht, wenn der Server das nicht abietet. Zweitens löst das das Problem nicht, daß der Benutzer aktiv wissen muß, daß was schiefgehen kann. Drittens bedeutet das, daß jeder Benutzer einen lokalen Unix-Account und Zugang zu einer Shell haben muß, was natürlich ganz gefährlich und eine ganz andere Größenordnung ist. Einen SSH-Zugang als Alternative zu einem Web-Zugriff zu geben ist, sagen wir mal “rustikal”.

  Naja, und dann eben die alte und stets bedenkliche Geisteshaltung “If there’s a workaround, it ain’t broken”.

Also letztlich verschiedene Ausprägungen desselben Denkfehlers (weil es doch sowieso im Klartext über die Leitung müßte, muß man es auch im Klartext abspeichern). Wie sollte der Client sich sonst authentifizieren ohne Zugriff auf das Geheimnis?

Das eigentliche Problem, daß der Benutzer nicht unmittelbar erkennen (und verhindern) kann, daß sein Passwort im Klartext rausgeschrieben wird, war nicht ohne weiteres zu vermitteln. Und daran diskutieren die schon Jahre herum, nicht erst seit ich frage. Und man legt Wert auf die Feststellung, daß das nicht zufällig entstanden sei, sondern daß man das bewußt so gewählt hat. Insecure by design.

Es wirft die Frage auf, wie man solches künftig vermeidet. Bessere Informatikausbildung?

In diesem speziellen Fall könnte ja vielleicht der 1001., der fragt, etwas bewirken. Ein einfacher Vorschlag wäre, das Passwort nur dann rauszuschreiben, wenn der Benutzer im Einzelfall (!) eine Option angibt, daß er das so haben will.