Hardlinks und chown
Wir möchten hier kurz über ein für uns überraschendes Sicherheitsproblem berichten, das wir auf unseren Systemen gefunden haben.
Wir hatten vor langer Zeit häufiger das Problem, dass in Nutzerverzeichnissen Dateien lagen, die einem anderen Nutzer gehören. Der Hauptgrund hierfür war, dass wir damals PHP-Code mit den Rechten des Apache-Nutzers ausgeführt haben. Das machen wir schon lange nicht mehr so, in unserem aktuellen Setup führen wir PHP-Code mittels FPM mit Nutzerrechten aus.
Doch aus dieser Zeit stammt ein Skript, mit dem wir Nutzern erlaubt haben, sich zum Besitzer von Dateien in ihrem Homeverzeichnis zu machen. Das Skript wurde mit Sudo ausgeführt und prüfte, dass die Dateien sich im Home des jeweiligen Nutzers befanden. Im Homeverzeichnis eines Nutzers sollten sich im Normalfall keine Dateien befinden, die dem jeweiligen Nutzer nicht gehören - also alles kein Problem?
Das dachten wir zumindest - und lagen falsch. Der Grund dafür sind sogenannte Hardlinks. Es gibt unter Linux zwei Arten von Links auf Dateisystemebene, die bekannteren Symlinks und eben Hardlinks. Bei Hardlinks hat man faktisch zwei Dateisystemeinträge für die identische Datei. Sprich: Alle Eigenschaften einer Datei ändern sich an beiden Stellen.
Ein Nutzer hätte nun in seinem Home einen Hardlink auf eine Datei anderswo auf dem Dateisystem anlegen können und mittels des oben genannten Skripts sich zum Besitzer dieser Datei machen.
Es gibt dabei ein paar Einschränkungen: Ein Hardlink kann nur auf Dateien und nicht auf Verzeichnisse gesetzt werden. Zudem muss der Nutzer zumindest Lesezugriff auf das Zielverzeichnis haben. Damit waren direkte Angriffe auf andere Nutzer ausgeschlossen, da bei uns die Homeverzeichnisse nicht für andere Nutzer lesbar sind. Zudem funktioniert der Angriff nicht über Partitionsgrenzen hinweg. Damit waren die Angriffsziele vergleichsweise beschränkt, allerdings gab es einige Skripte unseres Mailinglistensystems im Homedir, auf die man einen Angriff hätte durchführen können.
Wir haben keine Hinweise darauf, dass dieses Problem in irgendeiner Weise ausgenutzt wurde. Wir wollten hier darüber berichten, da es eine für uns überraschender Angriffsvektor war, den wir nicht bedacht hatten. Wir haben das Skript inzwischen entfernt.
Eine naheliegende Frage ist, ob der selbe Angriff auch mit Symlinks funktionieren würde. Dann wären die oben genannten Einschränkungen weg. In unserem Fall hätte dies nicht funktioniert, da unser in Python geschriebenes Skript Symlinks nicht folgte. Es ist aber in ähnlichen Setups vorstellbar, dass der Angriff auch mit Symlinks. Ein Aufruf des Kommandozeilentools chown auf einen Symlink wirkt sich beispielsweise auch auf das Link-Ziel aus.
