Linux über große Hintertür gehackt? Alles was du zum XZ Backdoor wissen solltest

[DMW007]

Es gibt einige Probleme mit Geheimdiensten: Fängt schon damit an, dass ein Ausländischer Geheimdienst in aller Regel keine Deutschen Interessen schützen will, sondern die des eigenen Landes. Und auch das nur im besten Falle. Hintertüren sind ein Paradebeispiel für höchst umstrittene Maßnahmen. Erst mal weil man dafür dem eigenen Geheimdienst vertrauen muss - was selbst in Demokratien schwierig ist, weil diese meist nur wenig und damit unzureichend kontrolliert werden. Das führt zu fragwürdigen Aktionen. Da muss nicht mal zwingend Böswilligkeit dahinter stecken. Punkt zwei bei solchen Aktionen ist, dass sie sehr schnell sehr stark außer Kontrolle geraten können, weil eine Hintertür per Definition eine Sicherheitslücke darstellt. Selbst in der Hand eines streng kontrollierten Geheimdienstes wäre der Missbrauch durch Dritte ein sehr hohes (mMn unverantwortliches) Risiko.

Und das ist nur die Theorie. In der Praxis sind viele weitaus gefährlicher unterwegs, weil es eben keine ausreichende Kontrolle & Reglementierung gibt. Da horten Geheimdienste gefährliche Sicherheitslücken/Hintertüren, passen damit nicht auf, bis weitere Zugang bekommen. Wir als Bevölkerung sind daher gefragt, das mindestens bei der Wahl zu berücksichtigen. Sowie im besten Falle vorher schon darauf aufmerksam zu machen, etwa die Themen diskutieren. Genug Anlässe dazu gibt es. Aktuell erinnern sich einige beispielsweise daran, dass da doch was mit Julian Assange war. Die Chatkontrolle ist ebenfalls mal wieder präsent, nachdem man sich auf "Quick Freeze" weitgehendst geeinigt hat. So was muss immer wieder diskutiert, verhandelt und ggf. Abgelehnt/dagegen protestiert werden, weil einige Kreise an Interesse an der Schwächung von effektiver Sicherheit haben - unter anderem etwa durch Hintertüren in verbreiteter Software.

[U-Labs YouTube]

Kommentar von @q9a:
Ich konnte systemd noch nie leiden
Man wollte erreichen das multicoreprozessorsysteme schneller starten ok für laptop & co
Aber Server ? Ist dort völlig egal

[DMW007]

Unter anderem das, es ging dabei um mehr. Beispielsweise Abhängigkeiten besser abbilden zu können oder generell Vereinheitlichung. Das haben sie teilweise durchaus erreicht. Du hast jetzt ein Systemd-Unit und keine Shell-Skripte, wo sich manches wiederholte. Die große Frage lautet: Wann ist es genug? Bei Systemd hat man gesagt, die ganzen Dienste schreiben Logs, da müssen wir auch was einheitliches für anbieten. Grundsätzlich nachvollziehbar, dabei kam das Journal heraus. Weil das Journal effizient sein möchte, legt es keine Textdateien ab, sondern komprimiert die Logs. Auch nachvollziehbar, ist ja nur Text drin und Text lässt sich gut komprimieren.

Als Ergebnis sind nun allerdings solche Exploits relativ einfach möglich, weil alles mit allem zusammen hängt. Vorher war das nicht so: Da hat init.d sich im Wesentlichen nur um Starten, Stoppen und Neustarten gekümmert. Die darüber gestarteten Programme haben ihre Logs in /var/log abgelegt. In der Regel hat man logrotate installiert oder die Distribution brachte das mit, damit ältere Protokolle gelöscht werden. Wahlweise noch mit der Möglichkeit, die älteren erst zu komprimieren. Hypothetisch könnte eine Bibliothek zum Komprimieren drin sein, die einen Exploit aufweist. Immerhin könnte die sich dann nicht so einfach über Systemd überall einklinken. Das würde den Angriff erschweren, allerdings natürlich nicht unmöglich machen - sobald ein Angreifer Schadcode auf dem System einschleusen kann, lässt sich damit Unsinn anstellen und das System ist potenziell kompromittiert.

Man kann und sollte auf der einen Seite darüber diskutieren, wann eine Software fertig ist. Dies ist ein grundsätzliches Thema: Eine Software wird für Zweck X entwickelt. Sowohl Nutzer als auch Entwickler kommen gerne auf 99 andere Ideen, was man alles noch einbauen könnte. Für sich gesehen machen diese Funktionen durchaus Sinn. Auf Dauer bekommt man jedoch ein Monster, das für Fehler und Sicherheitsmängel immer anfälliger wird, im schlimmsten Falle ist es irgendwann unwartbar. Der X.org Server ist ein Paradebeispiel dafür: Neben zig Erweiterungen wurden diverse Workarounds/Hacks eingebaut, die an anderer Stelle gelöst werden müssten - beispielsweise im Treiber der Grafikkarte, da hat es der Hersteller aber nicht gefixt. Eine Pauschale Antwort darauf ist schwierig. Ich denke, wir brauchen mehr Bewusstsein dafür und sollten uns ein Stück weit an die Unix-Philosophie erinnern: Ein Werkzeug soll einen Zweck erfüllen und den dafür gut. Für komplexere Zwecke kann man mehrere miteinander verbinden, z.B. durch Pipes.

Allerdings kann man es sich mMn nicht einfach machen und sagen: Systemd ist doof, wären die nicht so blöd, hätten wir kein Problem. Weil wie vorhin schon gesagt, sobald Schadcode aufs System kommt, haben wir ein Problem. Mit init.d wäre es nicht so einfach möglich geworden, den OpenSSH-Server versteckt zu infiltrieren. Dann wäre es ein anderer Exploit geworden. Wir brauchen daher einen kritischeren Blick auf Abhängigkeiten: Sie müssen grundsätzlich hinterfragt werden, nur da eingesetzt wo es nötig ist und die eingesetzten benötigen Unterstützung, damit man sie nicht so einfach kapern kann. Sonst fällt das an anderen Stellen auf die Füße, wo es das auch schon seit längerem tut. Beispiel Atlassian: Die haben zig Drittanbieter-Bibliotheken eingebunden und pflegen sie nicht mal, was ein Hauptgrund ist, warum es in deren Software ständig schwere Sicherheitsmängel gibt. Und hier reden wir nur von einem kommerziellen Unternehmen, dass proprietäre Anwendersoftware verkauft. Bei zentraler Software die zum Kernsystem vieler GNU/Linux-Distributionen gehört, muss der Maßstab deutlich höher liegen, als bei einem Murks-Konzern, der mit seinen Schlampereien kein Ökosystem bedroht.