NEU
|
|
•NEUES THEMA10.04.2024, 12:07 Uhr
| Nutzer / in | |
| FPeregrin | |
|
|
• Zur PolÖk von Open Source
Die XZ-Vorfall wirft ein deutliches Licht auf die Produktionsbedingungen von Open Source, die ja nicht deshalb den kapitalistischen Gesetzmäßigkieten der allgemeinen Warenförmigkeit - inkl. der der Arbietskraft - nicht unterworfen wären, weil das Produkt für den Nutzer kostenlos ist. Hierzu und zum Vorfall selbst heise.de heute:
Aktenzeichen XZ ungelöst
In den vergangenen Tagen sind wir mit sehr viel Glück dem wohl größten Fiasko in der Geschichte des Internets gerade so entgangen. Wie konnte das passieren?
08:07 Uhr
Lesezeit: 18 Min.
Developer
Von Golo Roden
Man darf wohl ohne Übertreibung behaupten, dass etwas Derartiges nicht alle Tage passiert. Wahrscheinlich haben Sie zumindest am Rande mitbekommen, dass wir in den vergangenen zehn Tagen nur mit äußerst viel Glück einer der größten Katastrophen in der Geschichte des Internets knapp entkommen sind. Die Vorkommnisse lesen sich tatsächlich wie ein überaus spannender High-Tech-Kriminalroman. Doch was genau ist eigentlich geschehen? Wie konnte es dazu kommen? Welche Schritte sind nun erforderlich? Und vor allem: Wie lassen sich ähnliche Vorfälle in der Zukunft verhindern?
Ein Angriff auf XZ
Auf den ersten Blick schien es sich um einen Angriff auf das XZ-Projekt zu handeln, doch tatsächlich sind wir nur knapp einer digitalen Katastrophe unvorstellbaren Ausmaßes entkommen: Im Kern geht es bei dem Ganzen um nichts Geringeres als den Kampf um die digitale Weltherrschaft. Um zu verstehen, was genau passiert ist, werfen wir zunächst einen Blick auf einen kurzen historischen Abriss der Ereignisse.
Bevor wir damit jedoch beginnen, sollten wir kurz klären, was XZ eigentlich ist: Falls Ihnen das nichts sagt, XZ ist eine Sammlung von Werkzeugen zum Komprimieren von Dateien, ähnlich wie ZIP oder TAR, und bezeichnet ebenso das dazugehörige Kompressionsformat. Im Gegensatz zu ZIP und TAR handelt es sich bei XZ jedoch nicht um ein Archivformat, das heißt, es werden nicht mehrere Dateien zu einer einzelnen zusammengefasst, sondern jede Datei wird für sich komprimiert. Wichtig zu erwähnen ist dabei auch, dass es eine zugehörige Bibliothek namens liblzma gibt. Das steht für "Lempel Ziv Markov Algorithm", also den Namen des Algorithmus, den XZ intern verwendet.
Alles beginnt im Jahr 2021
Springen wir in das Jahr 2021, denn der Ursprung der ganzen Geschichte reicht tatsächlich bereits drei Jahre zurück. Damals ereignete sich zwar zunächst eigentlich nichts, was besonders ins Auge fiele oder für Aufregung gesorgt hätte, jedoch legte im Laufe des Jahres jemand namens Jia Tan ein GitHub-Konto mit dem Benutzernamen JiaT75 an. Außerdem reichte Jia Tan einen Pull Request bei der Bibliothek libarchive ein, der darauf abzielte, eine Fehlermeldung zu verbessern.
Zumindest scheint das auf den ersten Blick der Zweck des Pull Requests gewesen zu sein. Bei genauerer Betrachtung des zugehörigen Commits fällt jedoch auf, dass nicht nur eine Fehlermeldung verbessert werden, sondern auch die Funktion zur Ausgabe, safe_fprintf, durch eine unsichere Variante, nämlich einfach nur fprintf, ersetzt werden sollte. Dieser Pull Request wurde ohne Einwände akzeptiert und hatte vermutlich keine weitreichenden Folgen. Doch vor dem Hintergrund der aktuellen Geschehnisse gerät der Vorgang erneut in den Fokus. Kurz gesagt: Jia Tan betritt die Bühne.
Jia Tan wendet sich XZ zu
Im darauffolgenden Jahr 2022 legt Jia Tan erstmalig einen Patch für XZ vor. Im Gegensatz zum üblichen Vorgehen wird dieser Patch allerdings nicht als Pull Request eingereicht, sondern über eine Mailingliste verteilt. Der Patch selbst ist eher unscheinbar und weckt wenig Interesse. Doch es ereignet sich etwas anderes, weit spannenderes: Eine zweite Person, die sich Jigar Kumar nennt, beginnt, den Entwickler von XZ zu drängen, den Patch so schnell wie möglich zu integrieren.
Der Druck steigt weiter an, als eine dritte Person, unter dem Namen Dennis Ens, ebenfalls auf eine rasche Übernahme des Patches drängt. Sowohl Jigar Kumar als auch Dennis Ens verschwinden nach diesen Ereignissen spurlos und hinterlassen keinerlei digitale Spuren. Beide Konten scheinen außerdem speziell für diesen einmaligen Zweck angelegt worden zu sein. Bemerkenswert dabei ist, dass alle drei E-Mail-Adressen einem ähnlichen Muster folgen.
Der Hauptentwickler von XZ, Lasse Collin, gibt dem Druck nach und nimmt den Patch auf. Es ist ein Paradebeispiel dafür, wie die Dinge oft laufen: Lasse Collin betreibt die Arbeit an XZ nebenbei. Wie so häufig ist die Beteiligung an Open-Source-Projekten für ihn als Einzelperson kaum nachhaltig. Die Last, die XZ mit sich bringt, ist für ihn allein eigentlich zu groß. Er ist überfordert und überarbeitet, wie er damals selbst schreibt.
Open Source ist (mal wieder) nicht nachhaltig
Leider ist diese Situation typisch für viele Entwicklerinnen und Entwickler weitverbreiteter Open-Source-Bibliotheken, die wesentlich zur kritischen Infrastruktur beitragen, ohne dass sich jemand ernsthaft um ihre finanzielle oder psychische Gesundheit kümmert. Open Source leidet unter einem gravierenden Nachhaltigkeitsproblem. Und es ist nicht das erste Mal, dass so etwas geschieht. Erinnern wir uns nur an die jüngste Sicherheitslücke in Log4J.
Im Klartext: Die Open-Source-Ideologie hat es über die Jahre und Jahrzehnte geschafft, den Wert unserer Zeit als Entwicklerinnen und Entwickler zu untergraben. Denn seien wir ehrlich: Für die meisten geht es bei Open Source nicht primär um den Zugang zum Quellcode, sondern um die Kostenfreiheit. Dass dabei Menschen wie Lasse Collin auf der Strecke bleiben können, wird als bedauerlicher, aber akzeptabler Kollateralschaden angesehen. Hauptsache, Open-Source-Software bleibt sowohl für die breite Masse als auch Unternehmen kostenfrei verfügbar …
Jia Tan bietet Hilfe an
Vor diesem Hintergrund überrascht es wenig, dass Lasse Collin die Unterstützung, die Jia Tan ihm anbietet, dankend annimmt. Denn endlich scheint einmal jemand bereit zu sein, nicht nur Forderungen zu stellen, sondern sich auch aktiv einzubringen. Dass er dabei unwissentlich einem umfassenden Social-Engineering-Angriff zum Opfer fällt, kann Collin zu diesem Zeitpunkt natürlich nicht erahnen. Und Jia Tan engagiert sich tatsächlich: Sie oder er wird zu einem regelmäßigen Mitwirkenden bei XZ, steigt im Laufe der Zeit sogar zum zweithäufigsten Beitragenden auf und wird 2022 schließlich zum offiziellen Co-Maintainer ernannt, mit den entsprechenden Berechtigungen.
Von dieser neu gewonnenen Vertrauensstellung macht Jia Tan erstmals am 7. Januar 2023 Gebrauch und integriert eigenständig Code in das XZ-Projekt. Von diesem Zeitpunkt an genießt Jia Tan das vollständige Vertrauen von Lasse Collin. Zwei Monate später, im März, wird die Kontaktadresse für XZ beim Open-Source-Sicherheitsscanner OSS-Fuzz auf Jia Tans Adresse umgestellt. Das bedeutet, dass ab diesem Zeitpunkt sicherheitsrelevante Benachrichtigungen, die XZ betreffen, nicht mehr Lasse Collin, sondern nur noch Jia Tan erreichen.
Diese Änderung erweist sich wenige Monate später als bedeutsam, als eine neue Person, Hans Jansen, auf den Plan tritt. Hans Jansen schlägt eine Methode vor, um Prüfsummen schneller zu berechnen, indem der hierfür verwendete Algorithmus zur Laufzeit ausgetauscht werden kann – ein Konzept, das einem Plug-in-System ähnelt. Nach diesem Vorschlag verschwindet Hans Jansen zunächst wieder aus dem Geschehen, wird aber später erneut eine Rolle spielen.
Der Angriff wird vorbereitet
Jia Tan stimmt dem Änderungsvorschlag zunächst zu und erhält daraufhin prompt eine Sicherheitswarnung von OSS-Fuzz – Lasse Collin hingegen erhält diese Warnung nicht. Die Warnung ist gerechtfertigt, denn die vorgeschlagene Änderung würde es ermöglichen, Code nachträglich auszutauschen – eine Möglichkeit, die normalerweise vermieden werden sollte. Jia Tan wendet sich jedoch an OSS-Fuzz und behauptet, dass diese Änderung legitim sei und die Warnung somit unbegründet. Und OSS-Fuzz stimmt dieser Einschätzung schließlich zu. Damit ist in XZ nun theoretisch die Möglichkeit geschaffen, Code zur Laufzeit zu manipulieren.
Nach einer dreijährigen Vorbereitungsphase wird es dann im Jahr 2024 schließlich ernst: Jia Tan reicht bei XZ einen Pull Request ein, um scheinbar neue Testdateien hinzuzufügen. Konkret handelt es sich um zwei Binärdateien, deren Inhalt auf den ersten Blick nicht unmittelbar ersichtlich ist. Sie sollen angeblich dem Testen des Entpackungsvorgangs dienen, wobei eine der Dateien vermeintlich korrupt ist, die andere hingegen nicht.
Auf den ersten Blick mag dieses Vorgehen legitim erscheinen, da solche Testszenarien in der Praxis durchaus üblich sind. Andererseits lässt sich sicherlich darüber streiten, ob es eine gute Idee ist, direkt Binärdateien einzupflegen, oder ob diese nicht eher durch einen transparenten und nachvollziehbaren Prozess erzeugt werden sollten. Das eigentliche Problem besteht jedoch darin, dass diese "Test"-Dateien nicht einfach nur beliebige Binärdateien sind, sondern Skripte und ausführbaren Code enthalten. Beim Ausführen der Tests werden sie entpackt und in der Folge durch eine Reihe komplexer Befehle ausgeführt, was zu einer Manipulation des XZ-Builds führt. Ab diesem Zeitpunkt existieren somit kompromittierte Versionen von XZ.
>>>
Aktenzeichen XZ ungelöst
In den vergangenen Tagen sind wir mit sehr viel Glück dem wohl größten Fiasko in der Geschichte des Internets gerade so entgangen. Wie konnte das passieren?
08:07 Uhr
Lesezeit: 18 Min.
Developer
Von Golo Roden
Man darf wohl ohne Übertreibung behaupten, dass etwas Derartiges nicht alle Tage passiert. Wahrscheinlich haben Sie zumindest am Rande mitbekommen, dass wir in den vergangenen zehn Tagen nur mit äußerst viel Glück einer der größten Katastrophen in der Geschichte des Internets knapp entkommen sind. Die Vorkommnisse lesen sich tatsächlich wie ein überaus spannender High-Tech-Kriminalroman. Doch was genau ist eigentlich geschehen? Wie konnte es dazu kommen? Welche Schritte sind nun erforderlich? Und vor allem: Wie lassen sich ähnliche Vorfälle in der Zukunft verhindern?
Ein Angriff auf XZ
Auf den ersten Blick schien es sich um einen Angriff auf das XZ-Projekt zu handeln, doch tatsächlich sind wir nur knapp einer digitalen Katastrophe unvorstellbaren Ausmaßes entkommen: Im Kern geht es bei dem Ganzen um nichts Geringeres als den Kampf um die digitale Weltherrschaft. Um zu verstehen, was genau passiert ist, werfen wir zunächst einen Blick auf einen kurzen historischen Abriss der Ereignisse.
Bevor wir damit jedoch beginnen, sollten wir kurz klären, was XZ eigentlich ist: Falls Ihnen das nichts sagt, XZ ist eine Sammlung von Werkzeugen zum Komprimieren von Dateien, ähnlich wie ZIP oder TAR, und bezeichnet ebenso das dazugehörige Kompressionsformat. Im Gegensatz zu ZIP und TAR handelt es sich bei XZ jedoch nicht um ein Archivformat, das heißt, es werden nicht mehrere Dateien zu einer einzelnen zusammengefasst, sondern jede Datei wird für sich komprimiert. Wichtig zu erwähnen ist dabei auch, dass es eine zugehörige Bibliothek namens liblzma gibt. Das steht für "Lempel Ziv Markov Algorithm", also den Namen des Algorithmus, den XZ intern verwendet.
Alles beginnt im Jahr 2021
Springen wir in das Jahr 2021, denn der Ursprung der ganzen Geschichte reicht tatsächlich bereits drei Jahre zurück. Damals ereignete sich zwar zunächst eigentlich nichts, was besonders ins Auge fiele oder für Aufregung gesorgt hätte, jedoch legte im Laufe des Jahres jemand namens Jia Tan ein GitHub-Konto mit dem Benutzernamen JiaT75 an. Außerdem reichte Jia Tan einen Pull Request bei der Bibliothek libarchive ein, der darauf abzielte, eine Fehlermeldung zu verbessern.
Zumindest scheint das auf den ersten Blick der Zweck des Pull Requests gewesen zu sein. Bei genauerer Betrachtung des zugehörigen Commits fällt jedoch auf, dass nicht nur eine Fehlermeldung verbessert werden, sondern auch die Funktion zur Ausgabe, safe_fprintf, durch eine unsichere Variante, nämlich einfach nur fprintf, ersetzt werden sollte. Dieser Pull Request wurde ohne Einwände akzeptiert und hatte vermutlich keine weitreichenden Folgen. Doch vor dem Hintergrund der aktuellen Geschehnisse gerät der Vorgang erneut in den Fokus. Kurz gesagt: Jia Tan betritt die Bühne.
Jia Tan wendet sich XZ zu
Im darauffolgenden Jahr 2022 legt Jia Tan erstmalig einen Patch für XZ vor. Im Gegensatz zum üblichen Vorgehen wird dieser Patch allerdings nicht als Pull Request eingereicht, sondern über eine Mailingliste verteilt. Der Patch selbst ist eher unscheinbar und weckt wenig Interesse. Doch es ereignet sich etwas anderes, weit spannenderes: Eine zweite Person, die sich Jigar Kumar nennt, beginnt, den Entwickler von XZ zu drängen, den Patch so schnell wie möglich zu integrieren.
Der Druck steigt weiter an, als eine dritte Person, unter dem Namen Dennis Ens, ebenfalls auf eine rasche Übernahme des Patches drängt. Sowohl Jigar Kumar als auch Dennis Ens verschwinden nach diesen Ereignissen spurlos und hinterlassen keinerlei digitale Spuren. Beide Konten scheinen außerdem speziell für diesen einmaligen Zweck angelegt worden zu sein. Bemerkenswert dabei ist, dass alle drei E-Mail-Adressen einem ähnlichen Muster folgen.
Der Hauptentwickler von XZ, Lasse Collin, gibt dem Druck nach und nimmt den Patch auf. Es ist ein Paradebeispiel dafür, wie die Dinge oft laufen: Lasse Collin betreibt die Arbeit an XZ nebenbei. Wie so häufig ist die Beteiligung an Open-Source-Projekten für ihn als Einzelperson kaum nachhaltig. Die Last, die XZ mit sich bringt, ist für ihn allein eigentlich zu groß. Er ist überfordert und überarbeitet, wie er damals selbst schreibt.
Open Source ist (mal wieder) nicht nachhaltig
Leider ist diese Situation typisch für viele Entwicklerinnen und Entwickler weitverbreiteter Open-Source-Bibliotheken, die wesentlich zur kritischen Infrastruktur beitragen, ohne dass sich jemand ernsthaft um ihre finanzielle oder psychische Gesundheit kümmert. Open Source leidet unter einem gravierenden Nachhaltigkeitsproblem. Und es ist nicht das erste Mal, dass so etwas geschieht. Erinnern wir uns nur an die jüngste Sicherheitslücke in Log4J.
Im Klartext: Die Open-Source-Ideologie hat es über die Jahre und Jahrzehnte geschafft, den Wert unserer Zeit als Entwicklerinnen und Entwickler zu untergraben. Denn seien wir ehrlich: Für die meisten geht es bei Open Source nicht primär um den Zugang zum Quellcode, sondern um die Kostenfreiheit. Dass dabei Menschen wie Lasse Collin auf der Strecke bleiben können, wird als bedauerlicher, aber akzeptabler Kollateralschaden angesehen. Hauptsache, Open-Source-Software bleibt sowohl für die breite Masse als auch Unternehmen kostenfrei verfügbar …
Jia Tan bietet Hilfe an
Vor diesem Hintergrund überrascht es wenig, dass Lasse Collin die Unterstützung, die Jia Tan ihm anbietet, dankend annimmt. Denn endlich scheint einmal jemand bereit zu sein, nicht nur Forderungen zu stellen, sondern sich auch aktiv einzubringen. Dass er dabei unwissentlich einem umfassenden Social-Engineering-Angriff zum Opfer fällt, kann Collin zu diesem Zeitpunkt natürlich nicht erahnen. Und Jia Tan engagiert sich tatsächlich: Sie oder er wird zu einem regelmäßigen Mitwirkenden bei XZ, steigt im Laufe der Zeit sogar zum zweithäufigsten Beitragenden auf und wird 2022 schließlich zum offiziellen Co-Maintainer ernannt, mit den entsprechenden Berechtigungen.
Von dieser neu gewonnenen Vertrauensstellung macht Jia Tan erstmals am 7. Januar 2023 Gebrauch und integriert eigenständig Code in das XZ-Projekt. Von diesem Zeitpunkt an genießt Jia Tan das vollständige Vertrauen von Lasse Collin. Zwei Monate später, im März, wird die Kontaktadresse für XZ beim Open-Source-Sicherheitsscanner OSS-Fuzz auf Jia Tans Adresse umgestellt. Das bedeutet, dass ab diesem Zeitpunkt sicherheitsrelevante Benachrichtigungen, die XZ betreffen, nicht mehr Lasse Collin, sondern nur noch Jia Tan erreichen.
Diese Änderung erweist sich wenige Monate später als bedeutsam, als eine neue Person, Hans Jansen, auf den Plan tritt. Hans Jansen schlägt eine Methode vor, um Prüfsummen schneller zu berechnen, indem der hierfür verwendete Algorithmus zur Laufzeit ausgetauscht werden kann – ein Konzept, das einem Plug-in-System ähnelt. Nach diesem Vorschlag verschwindet Hans Jansen zunächst wieder aus dem Geschehen, wird aber später erneut eine Rolle spielen.
Der Angriff wird vorbereitet
Jia Tan stimmt dem Änderungsvorschlag zunächst zu und erhält daraufhin prompt eine Sicherheitswarnung von OSS-Fuzz – Lasse Collin hingegen erhält diese Warnung nicht. Die Warnung ist gerechtfertigt, denn die vorgeschlagene Änderung würde es ermöglichen, Code nachträglich auszutauschen – eine Möglichkeit, die normalerweise vermieden werden sollte. Jia Tan wendet sich jedoch an OSS-Fuzz und behauptet, dass diese Änderung legitim sei und die Warnung somit unbegründet. Und OSS-Fuzz stimmt dieser Einschätzung schließlich zu. Damit ist in XZ nun theoretisch die Möglichkeit geschaffen, Code zur Laufzeit zu manipulieren.
Nach einer dreijährigen Vorbereitungsphase wird es dann im Jahr 2024 schließlich ernst: Jia Tan reicht bei XZ einen Pull Request ein, um scheinbar neue Testdateien hinzuzufügen. Konkret handelt es sich um zwei Binärdateien, deren Inhalt auf den ersten Blick nicht unmittelbar ersichtlich ist. Sie sollen angeblich dem Testen des Entpackungsvorgangs dienen, wobei eine der Dateien vermeintlich korrupt ist, die andere hingegen nicht.
Auf den ersten Blick mag dieses Vorgehen legitim erscheinen, da solche Testszenarien in der Praxis durchaus üblich sind. Andererseits lässt sich sicherlich darüber streiten, ob es eine gute Idee ist, direkt Binärdateien einzupflegen, oder ob diese nicht eher durch einen transparenten und nachvollziehbaren Prozess erzeugt werden sollten. Das eigentliche Problem besteht jedoch darin, dass diese "Test"-Dateien nicht einfach nur beliebige Binärdateien sind, sondern Skripte und ausführbaren Code enthalten. Beim Ausführen der Tests werden sie entpackt und in der Folge durch eine Reihe komplexer Befehle ausgeführt, was zu einer Manipulation des XZ-Builds führt. Ab diesem Zeitpunkt existieren somit kompromittierte Versionen von XZ.
>>>
•NEUER BEITRAG10.04.2024, 12:13 Uhr
| Nutzer / in | |
| FPeregrin | |
|
|
>>>
Hans Jansen taucht wieder auf
Am 25. März 2024 taucht Hans Jansen schließlich erneut auf und setzt sich unter anderem beim Debian-Projekt dafür ein, auf die neue – und somit kompromittierte – Version von XZ umzusteigen. Das Debian-Projekt führt auch tatsächlich ein Upgrade durch, zunächst zwar nur in einer Vorabversion, aber Hans Jansen erzielt damit einen Erfolg. Auch andere Linux-Distributionen wie Kali-Linux, Arch-Linux und Fedora nehmen das Upgrade vor. Einige Distributionen, darunter Ubuntu, entscheiden sich gegen das Upgrade oder schieben eine Entscheidung auf. So gelangt die kompromittierte Version von XZ aber in eine Reihe von Linux-Distributionen.
Besagte Vorabversion von Debian fand nun ihren Weg zu Andres Freund, einem Mitarbeiter von Microsoft, der an der Entwicklung von PostgreSQL beteiligt ist. Er wollte einige seiner Änderungen an PostgreSQL testen und entschied sich daher für die neueste Debian-Version. Dadurch kam er bereits sehr früh mit dem Schadcode in Berührung – deutlich früher als die meisten Nutzer. Bei seinen Tests bemerkte er, dass der Login über SSH ungewöhnlich lange dauerte, nämlich eine dreiviertel Sekunde anstelle der üblichen Viertelsekunde.
Während die meisten Entwicklerinnen und Entwickler dies wahrscheinlich übersehen oder ignoriert hätten, wurde Freund skeptisch und begann, der Sache auf den Grund zu gehen. Seine Nachforschungen führten ihn immer tiefer in den Kaninchenbau, was mich persönlich an Clifford Stoll erinnert, der in den 1980er-Jahren aufgrund eines minimalen Abrechnungsfehlers den KGB-Hack aufdeckte. Schließlich geht Andres Freund am 29. März, also vier Tage später, mit seinen Erkenntnissen an die Öffentlichkeit.
Von XZ zu SSH
Nun stellt sich die Frage: Was genau ist das Problem und wo liegt die Gefahr? Es steht fest, dass XZ kompromittiert wurde, aber welche Auswirkungen hat das? Die Bedrohung ist tatsächlich nur indirekt mit XZ verbunden. Es ist wichtig zu verstehen, dass XZ unter Linux eine essenzielle Rolle spielt: So wird unter anderem der Kernel üblicherweise mit XZ komprimiert, ebenso das Initramfs und auch RPM- sowie DEB-Pakete. XZ ist somit schon früh im Systemstartprozess von Bedeutung.
Viele Linux-Distributionen verwenden heutzutage Systemd als Init-Prozess, der oft auch dazu dient, den SSH-Dienst zu starten. Die meisten Distributionen bieten dafür allerdings nicht die offizielle OpenSSH-Version an, sondern eigene, modifizierte Varianten mit zusätzlichen Funktionen. Die Integration von SSH mit Systemd ist eine solche typische Erweiterung. Hier setzt der Angriff an: Wenn Systemd startet, lädt es XZ, und XZ modifiziert – noch bevor SSH gestartet wird – die Funktion zur Authentifizierung von SSH-Schlüsseln. Sobald SSH aktiviert wird, ist bereits die manipulierte Version im Einsatz.
Und die hat es in sich: Die manipulierte Version der Authentifizierungsfunktion verhält sich zwar in 99,9 Prozent aller Fälle absolut so, wie man es erwarten würde. Doch für einen einzigen, spezifisch definierten SSH-Schlüssel tritt ein Sonderfall in Kraft: Dieser wird nämlich nicht korrekt überprüft, sondern ein Teil des Schlüssels wird dazu verwendet, Remote-Befehle auszuführen. Es ist tatsächlich ziemlich beeindruckend, dass so etwas überhaupt möglich ist. Der Clou dabei ist, dass sich SSH damit für praktisch alle Nutzerinnen und Nutzer vollkommen normal verhalten würde, nur nicht für Angreiferinnen oder Angreifer, die im Besitz des entsprechenden privaten Schlüssels wären. Das hätte die Sicherheitslücke extrem gut verbergen können.
Auf den letzten fünf Metern gescheitert
Das Besondere an diesem Angriff ist seine Komplexität. Er basiert darauf, die Lieferkette von SSH über mehrere Ebenen hinweg zu attackieren: Von XZ über liblzma und Systemd bis hin zu SSH. Ein solches Unterfangen erfordert umfassendes Spezialwissen aus verschiedenen internen Bereichen des Betriebssystems, der betroffenen Werkzeuge und insbesondere ihrer Wechselwirkungen. Die Vorbereitungen für diesen Angriff hatten eine lange Vorlaufzeit, beginnend im Jahr 2021, und es handelt sich um einen sogenannten NOBUS-Angriff ("Nobody but us"), bei dem ausschließlich die Angreiferin oder der Angreifer die Sicherheitslücke hätte ausnutzen können. Die Möglichkeit, in XZ dynamisch Code nachzuladen, legt sogar die Grundlage für weitere Exploits. Dies zeugt von einer komplexen und sorgfältig durchdachten Vorgehensweise.
Angesichts der hochtechnischen Natur dieses Angriffs stellt sich daher die Frage, warum er so schnell entdeckt wurde. Warum lief der SSH-Login merklich langsamer als üblich, was letztlich den ersten Verdacht bei Andres Freund weckte? Warum wurde dies, trotz des beträchtlichen Aufwands, der in die Planung des Angriffs floss, nicht umfassender getestet?
Mehr Glück als Verstand
Möglicherweise hatten wir alle einfach nur enormes Glück: Denn am 29. Februar, also vor gerade einmal fünf Wochen, wurde bei Systemd der Vorschlag eingebracht, das Laden von XZ zu einem deutlich späteren Zeitpunkt im Systemstartprozess zu initiieren, um diesen zu beschleunigen. Wäre dieser Vorschlag umgesetzt worden, hätte XZ nicht mehr die Möglichkeit gehabt, unbemerkt Veränderungen an SSH vorzunehmen.
Mit anderen Worten: Diese Änderung in Systemd hätte den sorgfältig über Jahre geplanten Angriff zunichtegemacht. Daher könnte es sein, dass die Angreifenden unter Druck gerieten, ihre Pläne vorzeitig in die Tat umzusetzen – selbst auf das Risiko hin, dass der Angriff bislang nicht ausgereift war. Dieser glückliche Zufall hat uns möglicherweise davor bewahrt, dass 80 bis 90 Prozent aller Server im Internet kompromittiert worden wären. Bedenkt man, dass Linux auf einem Großteil aller Server im Web und in der Cloud läuft, sind die potenziellen Konsequenzen kaum zu überschauen. Das hätte dann wirklich einer Übernahme der digitalen Weltherrschaft gleichkommen können, wie eine Szene aus "Fight Club", nur eben im echten Leben.
Was man aktuell weiß
Zum aktuellen Stand: Der spezifische Exploit wird noch von zahlreichen Expertinnen und Experten untersucht. Das GitHub-Repository von XZ ist momentan gesperrt, während der ursprüngliche Hauptentwickler, Lasse Collin, mit den Aufräumarbeiten beschäftigt ist. An dieser Stelle möchte ich noch einmal betonen, wie sehr mir Lasse Collin leidtut. Er hat viel Zeit und Engagement in die Entwicklung von etwas gesteckt, das der Allgemeinheit zugutekommt, nur um dann Opfer eines hinterlistigen Angriffs zu werden. Dass er einem so gut geplanten Social-Engineering-Angriff zum Opfer gefallen ist, kann und darf ihm nicht angelastet werden. Es ist zutiefst bedauerlich, dass jemand, der Gutes bewirken wollte, von anderen ausgenutzt wird, mit der erkennbaren Absicht, enormen Schaden anrichten zu wollen.
Ob die wahren Drahtzieher dieses komplexen Angriffs jemals ermittelt werden können, bleibt ungewiss. Es gibt Stimmen, die aufgrund der Komplexität und der langen Vorbereitungszeit auf die Beteiligung von Geheimdiensten verweisen. Allerdings könnte es genauso gut ein Einzelner mit ausgeprägter technischer Expertise und Durchhaltevermögen gewesen sein. Die bisher einzige Spur, ein IRC-Chat, den Jia Tan genutzt hat, führt zu einer IP-Adresse in Singapur, die jedoch zu einem VPN-Anbieter gehört – wahrscheinlich also eine Sackgasse. Eventuell könnte eines Tages eine Kombination aus Quellcodeanalyse, Auswertung der Tageszeiten und weiteren Indizien zu Erkenntnissen führen – allerdings halte ich das persönlich für eher unwahrscheinlich.
>>>
Hans Jansen taucht wieder auf
Am 25. März 2024 taucht Hans Jansen schließlich erneut auf und setzt sich unter anderem beim Debian-Projekt dafür ein, auf die neue – und somit kompromittierte – Version von XZ umzusteigen. Das Debian-Projekt führt auch tatsächlich ein Upgrade durch, zunächst zwar nur in einer Vorabversion, aber Hans Jansen erzielt damit einen Erfolg. Auch andere Linux-Distributionen wie Kali-Linux, Arch-Linux und Fedora nehmen das Upgrade vor. Einige Distributionen, darunter Ubuntu, entscheiden sich gegen das Upgrade oder schieben eine Entscheidung auf. So gelangt die kompromittierte Version von XZ aber in eine Reihe von Linux-Distributionen.
Besagte Vorabversion von Debian fand nun ihren Weg zu Andres Freund, einem Mitarbeiter von Microsoft, der an der Entwicklung von PostgreSQL beteiligt ist. Er wollte einige seiner Änderungen an PostgreSQL testen und entschied sich daher für die neueste Debian-Version. Dadurch kam er bereits sehr früh mit dem Schadcode in Berührung – deutlich früher als die meisten Nutzer. Bei seinen Tests bemerkte er, dass der Login über SSH ungewöhnlich lange dauerte, nämlich eine dreiviertel Sekunde anstelle der üblichen Viertelsekunde.
Während die meisten Entwicklerinnen und Entwickler dies wahrscheinlich übersehen oder ignoriert hätten, wurde Freund skeptisch und begann, der Sache auf den Grund zu gehen. Seine Nachforschungen führten ihn immer tiefer in den Kaninchenbau, was mich persönlich an Clifford Stoll erinnert, der in den 1980er-Jahren aufgrund eines minimalen Abrechnungsfehlers den KGB-Hack aufdeckte. Schließlich geht Andres Freund am 29. März, also vier Tage später, mit seinen Erkenntnissen an die Öffentlichkeit.
Von XZ zu SSH
Nun stellt sich die Frage: Was genau ist das Problem und wo liegt die Gefahr? Es steht fest, dass XZ kompromittiert wurde, aber welche Auswirkungen hat das? Die Bedrohung ist tatsächlich nur indirekt mit XZ verbunden. Es ist wichtig zu verstehen, dass XZ unter Linux eine essenzielle Rolle spielt: So wird unter anderem der Kernel üblicherweise mit XZ komprimiert, ebenso das Initramfs und auch RPM- sowie DEB-Pakete. XZ ist somit schon früh im Systemstartprozess von Bedeutung.
Viele Linux-Distributionen verwenden heutzutage Systemd als Init-Prozess, der oft auch dazu dient, den SSH-Dienst zu starten. Die meisten Distributionen bieten dafür allerdings nicht die offizielle OpenSSH-Version an, sondern eigene, modifizierte Varianten mit zusätzlichen Funktionen. Die Integration von SSH mit Systemd ist eine solche typische Erweiterung. Hier setzt der Angriff an: Wenn Systemd startet, lädt es XZ, und XZ modifiziert – noch bevor SSH gestartet wird – die Funktion zur Authentifizierung von SSH-Schlüsseln. Sobald SSH aktiviert wird, ist bereits die manipulierte Version im Einsatz.
Und die hat es in sich: Die manipulierte Version der Authentifizierungsfunktion verhält sich zwar in 99,9 Prozent aller Fälle absolut so, wie man es erwarten würde. Doch für einen einzigen, spezifisch definierten SSH-Schlüssel tritt ein Sonderfall in Kraft: Dieser wird nämlich nicht korrekt überprüft, sondern ein Teil des Schlüssels wird dazu verwendet, Remote-Befehle auszuführen. Es ist tatsächlich ziemlich beeindruckend, dass so etwas überhaupt möglich ist. Der Clou dabei ist, dass sich SSH damit für praktisch alle Nutzerinnen und Nutzer vollkommen normal verhalten würde, nur nicht für Angreiferinnen oder Angreifer, die im Besitz des entsprechenden privaten Schlüssels wären. Das hätte die Sicherheitslücke extrem gut verbergen können.
Auf den letzten fünf Metern gescheitert
Das Besondere an diesem Angriff ist seine Komplexität. Er basiert darauf, die Lieferkette von SSH über mehrere Ebenen hinweg zu attackieren: Von XZ über liblzma und Systemd bis hin zu SSH. Ein solches Unterfangen erfordert umfassendes Spezialwissen aus verschiedenen internen Bereichen des Betriebssystems, der betroffenen Werkzeuge und insbesondere ihrer Wechselwirkungen. Die Vorbereitungen für diesen Angriff hatten eine lange Vorlaufzeit, beginnend im Jahr 2021, und es handelt sich um einen sogenannten NOBUS-Angriff ("Nobody but us"), bei dem ausschließlich die Angreiferin oder der Angreifer die Sicherheitslücke hätte ausnutzen können. Die Möglichkeit, in XZ dynamisch Code nachzuladen, legt sogar die Grundlage für weitere Exploits. Dies zeugt von einer komplexen und sorgfältig durchdachten Vorgehensweise.
Angesichts der hochtechnischen Natur dieses Angriffs stellt sich daher die Frage, warum er so schnell entdeckt wurde. Warum lief der SSH-Login merklich langsamer als üblich, was letztlich den ersten Verdacht bei Andres Freund weckte? Warum wurde dies, trotz des beträchtlichen Aufwands, der in die Planung des Angriffs floss, nicht umfassender getestet?
Mehr Glück als Verstand
Möglicherweise hatten wir alle einfach nur enormes Glück: Denn am 29. Februar, also vor gerade einmal fünf Wochen, wurde bei Systemd der Vorschlag eingebracht, das Laden von XZ zu einem deutlich späteren Zeitpunkt im Systemstartprozess zu initiieren, um diesen zu beschleunigen. Wäre dieser Vorschlag umgesetzt worden, hätte XZ nicht mehr die Möglichkeit gehabt, unbemerkt Veränderungen an SSH vorzunehmen.
Mit anderen Worten: Diese Änderung in Systemd hätte den sorgfältig über Jahre geplanten Angriff zunichtegemacht. Daher könnte es sein, dass die Angreifenden unter Druck gerieten, ihre Pläne vorzeitig in die Tat umzusetzen – selbst auf das Risiko hin, dass der Angriff bislang nicht ausgereift war. Dieser glückliche Zufall hat uns möglicherweise davor bewahrt, dass 80 bis 90 Prozent aller Server im Internet kompromittiert worden wären. Bedenkt man, dass Linux auf einem Großteil aller Server im Web und in der Cloud läuft, sind die potenziellen Konsequenzen kaum zu überschauen. Das hätte dann wirklich einer Übernahme der digitalen Weltherrschaft gleichkommen können, wie eine Szene aus "Fight Club", nur eben im echten Leben.
Was man aktuell weiß
Zum aktuellen Stand: Der spezifische Exploit wird noch von zahlreichen Expertinnen und Experten untersucht. Das GitHub-Repository von XZ ist momentan gesperrt, während der ursprüngliche Hauptentwickler, Lasse Collin, mit den Aufräumarbeiten beschäftigt ist. An dieser Stelle möchte ich noch einmal betonen, wie sehr mir Lasse Collin leidtut. Er hat viel Zeit und Engagement in die Entwicklung von etwas gesteckt, das der Allgemeinheit zugutekommt, nur um dann Opfer eines hinterlistigen Angriffs zu werden. Dass er einem so gut geplanten Social-Engineering-Angriff zum Opfer gefallen ist, kann und darf ihm nicht angelastet werden. Es ist zutiefst bedauerlich, dass jemand, der Gutes bewirken wollte, von anderen ausgenutzt wird, mit der erkennbaren Absicht, enormen Schaden anrichten zu wollen.
Ob die wahren Drahtzieher dieses komplexen Angriffs jemals ermittelt werden können, bleibt ungewiss. Es gibt Stimmen, die aufgrund der Komplexität und der langen Vorbereitungszeit auf die Beteiligung von Geheimdiensten verweisen. Allerdings könnte es genauso gut ein Einzelner mit ausgeprägter technischer Expertise und Durchhaltevermögen gewesen sein. Die bisher einzige Spur, ein IRC-Chat, den Jia Tan genutzt hat, führt zu einer IP-Adresse in Singapur, die jedoch zu einem VPN-Anbieter gehört – wahrscheinlich also eine Sackgasse. Eventuell könnte eines Tages eine Kombination aus Quellcodeanalyse, Auswertung der Tageszeiten und weiteren Indizien zu Erkenntnissen führen – allerdings halte ich das persönlich für eher unwahrscheinlich.
>>>
•NEUER BEITRAG10.04.2024, 12:16 Uhr
| Nutzer / in | |
| FPeregrin | |
|
|
>>>
Welche Konsequenzen können wir ziehen?
Was lässt sich nun konkret unternehmen? Kurzfristig ist es sicherlich ratsam, alle verfügbaren Updates einzuspielen und gegebenenfalls zu überprüfen, ob die eigene Infrastruktur von der Schwachstelle betroffen ist. Weitere Informationen dazu finden sich im CVE-2024-3094.
Langfristig betrachtet handelt es sich hierbei jedoch weniger um ein technisches als vielmehr um ein gesellschaftliches und kulturelles Problem, das verschiedene Ebenen betrifft: Dazu zählt das blinde Vertrauen in Open-Source-Projekte, die anhaltende Nachhaltigkeitsproblematik in der Open-Source-Welt und die sorglose Integration externer Abhängigkeiten in eigene Projekte. Das gesamte System des Internets basiert im Wesentlichen auf gegenseitigem Vertrauen, oft jedoch, ohne wirklich zu wissen, wem dieses Vertrauen eigentlich geschenkt wird. Es ist daher erstaunlich, dass nicht noch mehr Zwischenfälle geschehen.
Die eigentlich spannende Frage ist jedoch, was vielleicht tatsächlich bereits unbemerkt passiert, ohne dass wir davon Kenntnis erlangen. Ich sehe den aktuellen Open-Source-Ansatz daher kritisch, denn die Verlockung, etwas kostenlos zu erhalten, macht viele Entwicklerinnen und Entwickler und auch Unternehmen offenbar blind für alles andere. In einer idealen Welt wäre das unproblematisch, aber angesichts der Existenz von Akteuren mit bösartigen Absichten – inklusive feindlicher Organisationen und Staaten – muss man sich fragen, ob das blinde Vertrauen in Open Source tatsächlich langfristig tragbar ist.
Open Source als Problem?
Und nur, damit das nicht falsch verstanden wird: Ich möchte damit nicht sagen, dass Closed Source die Lösung sei. Ein ähnlicher Angriff wäre dort genauso möglich. Doch wird die Anfälligkeit von Open Source durch das bestehende Problem verstärkt, dass Open-Source-Entwicklung in der Regel nicht nachhaltig ist: Solange Software für kritische Infrastrukturen wie das Internet von einzelnen Personen in ihrer Freizeit nebenher und unbezahlt erfolgt, solange wird es auf einfachstem Wege möglich sein, sich deren Vertrauen zu erschleichen. Würde die Entwicklung von Open-Source-Software hingegen angemessen bezahlt, wäre die Notwendigkeit, aus einer akuten Notlage heraus auf von Fremden angebotene Hilfe zurückzugreifen, deutlich niedriger.
Selbstverständlich weist Open Source sehr viele positive Aspekte auf, das möchte ich nicht abstreiten. Aber wo Licht ist, ist bekanntermaßen leider auch Schatten – und von diesen Schattenseiten der Open Source haben wir vermutlich gerade erst den Anfang gesehen. (map)
Link ...jetzt anmelden!
Welche Konsequenzen können wir ziehen?
Was lässt sich nun konkret unternehmen? Kurzfristig ist es sicherlich ratsam, alle verfügbaren Updates einzuspielen und gegebenenfalls zu überprüfen, ob die eigene Infrastruktur von der Schwachstelle betroffen ist. Weitere Informationen dazu finden sich im CVE-2024-3094.
Langfristig betrachtet handelt es sich hierbei jedoch weniger um ein technisches als vielmehr um ein gesellschaftliches und kulturelles Problem, das verschiedene Ebenen betrifft: Dazu zählt das blinde Vertrauen in Open-Source-Projekte, die anhaltende Nachhaltigkeitsproblematik in der Open-Source-Welt und die sorglose Integration externer Abhängigkeiten in eigene Projekte. Das gesamte System des Internets basiert im Wesentlichen auf gegenseitigem Vertrauen, oft jedoch, ohne wirklich zu wissen, wem dieses Vertrauen eigentlich geschenkt wird. Es ist daher erstaunlich, dass nicht noch mehr Zwischenfälle geschehen.
Die eigentlich spannende Frage ist jedoch, was vielleicht tatsächlich bereits unbemerkt passiert, ohne dass wir davon Kenntnis erlangen. Ich sehe den aktuellen Open-Source-Ansatz daher kritisch, denn die Verlockung, etwas kostenlos zu erhalten, macht viele Entwicklerinnen und Entwickler und auch Unternehmen offenbar blind für alles andere. In einer idealen Welt wäre das unproblematisch, aber angesichts der Existenz von Akteuren mit bösartigen Absichten – inklusive feindlicher Organisationen und Staaten – muss man sich fragen, ob das blinde Vertrauen in Open Source tatsächlich langfristig tragbar ist.
Open Source als Problem?
Und nur, damit das nicht falsch verstanden wird: Ich möchte damit nicht sagen, dass Closed Source die Lösung sei. Ein ähnlicher Angriff wäre dort genauso möglich. Doch wird die Anfälligkeit von Open Source durch das bestehende Problem verstärkt, dass Open-Source-Entwicklung in der Regel nicht nachhaltig ist: Solange Software für kritische Infrastrukturen wie das Internet von einzelnen Personen in ihrer Freizeit nebenher und unbezahlt erfolgt, solange wird es auf einfachstem Wege möglich sein, sich deren Vertrauen zu erschleichen. Würde die Entwicklung von Open-Source-Software hingegen angemessen bezahlt, wäre die Notwendigkeit, aus einer akuten Notlage heraus auf von Fremden angebotene Hilfe zurückzugreifen, deutlich niedriger.
Selbstverständlich weist Open Source sehr viele positive Aspekte auf, das möchte ich nicht abstreiten. Aber wo Licht ist, ist bekanntermaßen leider auch Schatten – und von diesen Schattenseiten der Open Source haben wir vermutlich gerade erst den Anfang gesehen. (map)
Link ...jetzt anmelden!
•NEUER BEITRAG21.09.2024, 20:15 Uhr
| Nutzer / in | |
| FPeregrin | |
|
|
Zur PolÖk von Open Source
heise heute:Viele Open-Source-Maintainer schmeißen hin – steigender Druck auf Projekte
In Open-Source-Projekten steigt der Unmut. Mangelnde Vergütung bei wachsenden Anforderungen an Features, Dokumentation und Sicherheit belastet Maintainer.
08:50 Uhr
Lesezeit: 3 Min.
Developer
Von Robert Lippert
Der neue Tidelift State of the Open Source Maintainer Report wirft einen Blick auf die Belastungen, denen Maintainer heute ausgesetzt sind. Insbesondere die mangelnde Vergütung wirkt weiter Druck auf Projektbetreuer aus – gut 60 Prozent von ihnen sehen kein Geld für ihr Engagement.
Security im Fokus, nur kosten darf es nichts
Und auch im professionellen Bereich bleibt die Lage angespannt. Zwar kann eine Minderheit von rund 12 Prozent der Befragten von ihrer Arbeit an quelloffenen Projekten leben; der Wert hat sich gegenüber 2023 jedoch nicht verbessert, sondern sogar leicht verschlechtert (13 Prozent). Und das trotz Vorfällen wie dem Osterdrama um die xz Utils und der gestiegenen Aufmerksamkeit für Sicherheitsaspekte.
Tatsächlich müssten Maintainer gegenüber 2021 inzwischen bis zu dreimal so viel Zeit in die Sicherheit ihrer Projekte investieren. Dazu zählen neben Wartungsarbeiten und der Entwicklung neuer Sicherheitsfunktionen insbesondere auch das Beheben von Sicherheitslücken, die Suche nach neuen Schwachstellen oder der Umgang mit Abhängigkeiten im Code. Zeit, die dann für andere Aufgaben fehlt.
Maintainer orientieren sich zunehmend an Security-Standards
Der State of the Open Source Maintainer Report lobt an dieser Stelle das wachsende Bewusstsein für Standards wie dem NIST Secure Software Development Framework, der OpenSSF Scorecard oder dem SLSA (Supply Chain Levels for Software Artifacts Framework). Die OpenSSF Scorecard setzte sich insbesondere für Quellcode im Unternehmenskontext als Benchmark durch, und 30 Prozent der Maintainer arbeiten bereits mit dem Modell. Weitere 6 Prozent planen dessen Einsatz in den kommenden drei Monaten und 12 Prozent möchten sich innerhalb eines Jahres damit auseinandersetzen.
Dabei erlaubt der Report auch einen näheren Blick auf die von Tidelift unterstützten Projektbetreuer. Hier legen die Zahlen nahe, dass sich finanziell geförderte Betreuer eher an solche Standards halten – eine Förderung wirke sich also messbar auf eine Verbesserung der Sicherheit von Open-Source-Projekten aus.
Über ein Drittel der Maintainer würde am liebsten aufgeben
Die Arbeit an Open-Source-Projekten bringt nicht nur finanzielle Entbehrungen mit sich. Rund 48 Prozent der Maintainer fühlen sich nicht richtig wertgeschätzt, das entspricht rund 8 Prozentpunkten mehr als noch im Jahr 2021. Und wenn sie in eigenen Worten beschreiben dürften, was ihnen an der Arbeit wirklich nicht gefällt, dann kritisieren sie insbesondere das Anspruchsdenken ihrer Community. Wie es ein Befragter ausdrückt: "Die meisten Nutzer, selbst diejenigen, die Korrekturen benötigen, sind nicht bereit, selbst mit anzupacken. Sie erwarten einfach, dass jemand anderes das Problem kostenlos löst."
Und so ziehen es auch 38 Prozent der Befragten in Erwägung, ihr Engagement aufzugeben. 22 Prozent hätten diese Überlegung bereits in die Tat umgesetzt, so die Umfrage.
Der Tidelift State of the Open Source Maintainer Report steht gegen Registrierung kostenlos zum Download zur Verfügung. Er fasst die Antworten von 437 Maintainern zusammen, von denen mit 45 Prozent fast die Hälfte mehr als zehn Jahre Erfahrung in der Betreuung von Open-Source-Projekten mitbringt.
(who)
Link ...jetzt anmelden!
PNG-Datei •
Bild öffnen
...ohne Wasserzeichen: anmelden!
240918_woran-maintainer-lieber-arbeiten-11ffbc29...
...ohne Wasserzeichen: anmelden!
240918_woran-maintainer-lieber-arbeiten-11ffbc29...
• Hier gibt's was extra: mehr Debatten aus den www.secarts.org-Foren
Die 11. Moskauer Sicherheitskonferenz
BRD-Politzirkus: Wirtschaftskrise-Zeitenwende-Fas..
Archäologie: 5 Pionierinnen des 19./20. Jahrhund..
arktika
• 15.04.2024
arktika
• 15.04.2024
arktika
• 15.04.2024
Nordkorea-Südkorea: Änderung der Politik
Die 11. Moskauer Sicherheitskonferenz
Über die BRD-Siko sind die Medien voll;über die Siko der Russischen Föderation erfährt man deutlich weniger, aber sie fin...mehr
arktika
• 26.08.2023
BRD-Politzirkus: Wirtschaftskrise-Zeitenwende-Fas..
Also ein Rundumthread, der das Tun und Treiben unserer Bourgeoisie u. ihrer LakaiInnen beleuchtet; wenn das "führen müssen"...mehr
arktika
• 22.10.2023
Archäologie: 5 Pionierinnen des 19./20. Jahrhund.. 4
>>>>>
Direktorin und Trümmerfrau: Gertrud Dorka
* 1893 in Orlau (heute Orlowo in Polen), †1976 in Berlin
Gertrud...mehr
arktika
• 15.04.2024
arktika
• 15.04.2024
arktika
• 15.04.2024
Nordkorea-Südkorea: Änderung der Politik
Eine (vermutlich notwendige) Richtungsänderung der Politik Nordkoreas gegenüber Südkorea:
Koreanische Halbinsel
Pjö...mehr
arktika
• 21.01.2024