Im März 2024 machte die Entdeckung einer Backdoor in den zur Komprimierung genutzten „xz“-Tools und Bibliotheken Schlagzeilen. Aber wie groß ist die Bedrohung der IT-Sicherheit durch in Open Source-Software eingeschleuste Malware wirklich? Mir sind bereits vor einigen Tagen einige Aussagen der Eclips-Foundation zu diesem Thema untergekommen. Ich stelle die Aussagen mal hier im Blog ein.
Rückblick Backdoor in Upstream xz/liblzma
Im März 2024 hat der deutsche Microsoft-Ingenieur Andres Freund einen Hackerangriff auf die Linux Software vereitelt. Nur weil Freund sehr aufmerksam war und ihm einige merkwürdige Symptome rund um liblzma (ein Teil des xz-Pakets) unter Debian-Sid-Installationen aufgefallen waren, ist er dieser Sache nachgegangen.
Er fand dann die Ursache: Das (auch von sssh benutzte) Upstream-xz-Repository und die xz-Tarballs wurden mit einem Backdoor versehen. Erst vermutete er, dass das Debian-Paket kompromittiert worden sei, stellte aber fest, dass die Backdoor im Upstream-Paket enthalten ist. Ich hatte im Beitrag Linux: Backdoor in Upstream xz/liblzma; Kompromittierung der SSH-Server darüber berichtet.
In den Medien (und hier im Blog) wurde anschließend die Sicherheit von Open Source Software (OSS) in Kommentaren in Frage gestellt. Hier wäre es wichtig, eine fundierte Einordnung zur Frage Wie groß ist die Bedrohung der IT-Sicherheit durch Open Source Malware wirklich? vorzunehmen.
Wie groß ist die Bedrohung wirklich?
Zunächst einmal stellt Malware gleichermaßen eine Bedrohung für kommerzielle als auch für Open-Source-Software dar. Cybersicherheitsexperten bestätigen, dass Cyberkriminelle häufig auf Schwachstellen abzielen, die eine möglichst große Angriffsfläche bieten. Berücksichtigt man, dass bis zu 90 Prozent aller Software-Infrastrukturen auf Open Source Software (OSS) basieren, wird klar, dass OSS immer mehr zum Hauptziel von Angriffen wird.
Angesichts dieser Tatsachen ist es offensichtlich, dass die Bedrohungen für die Softwaresicherheit nicht nur real sind, sondern auch anhalten. Die beruhigende Nachricht ist jedoch, dass sich die derzeitigen Sicherheitspraktiken als wirksam erweisen. Jüngste Vorfälle wie die Linux SSH Schwachstelle und der xz utils Angriff konnten beide erfolgreich abgewehrt werden, weil die Community schnell reagiert und ihre Schutzmaßnahmen umgesetzt hat. Die Zusammenarbeit der Community ist die beste Verteidigung gegen solche Angriffe.
Eclipse Foundation nutzt das SLSA-Framework
Um die Abwehrmaßnahmen zu verstärken, wurde für die betreuten Projekte der Eclipse Foundation das SLSA-Framework übernommen. SLSA steht für „Supply-chain Levels for Software Artifacts“, ein Security Framework. Es besteht aus einer Checkliste mit Standards und Kontrollen, um Manipulationen von Open Source Software (OSS) zu verhindern, die Integrität zu verbessern und Pakete und Infrastruktur zu sichern. Es ist, laut Eigenbeschreibung, der Weg von „sicher genug“ zu größtmöglicher Widerstandsfähigkeit, und zwar für jedes Glied der Kette.
Neben den Ausführungen auf der oben verlinkten SLSA-Seite hat Google im Juli 2021 den Beitrag Securing the software development lifecycle with Cloud Build and SLSA mit einer Einführung in das Thema publiziert.
Eclipse nutzt ihre eigenen Sicherheitsrichtlinien
Mikaël Barber, Head of Security bei der Eclipse Foundation merkt dazu an, dass die Eclipse Foundation über den SLSA-Ansatz hinaus eigene Sicherheitsrichtlinien entwickelt habe, um sicherzustellen, dass bei der Entwicklung dieser Projekte die besten Software-Sicherheitspraktiken im Mittelpunkt stehen.
Ebenso wichtig sei das Engagement der Eclipse Foundation, ihre Mitglieder bei der Anpassung ihrer Projekte an neue Regulierungen wie den Cybersecurity Resilience Act zu unterstützen. Als Teil des proaktiven Ansatzes hat die Eclipse Foundation wir kürzlich die Open Regulatory Compliance Initiative ins Leben gerufen. In der Initiative sind weitere führende Stiftungen wie die Apache Software Foundation, OpenSSF Foundation, Blender Foundation, OpenSSL Software Foundation, PHP Foundation, Python Software Foundation und Rust Foundation beteiligt.
Gemeinsam wollen die Mitglieder auf Best Practices basierende Prozessspezifikationen entwickeln, um die Einhaltung dieser sich entwickelnden Regulierungen zu erleichtern. Damit werden Organisationen, die Open Source einsetzen, in die Lage versetzt, diese Regularien effizienter umzusetzen.
Es tut sich also was in Punkt Software-Lieferkette – und bei Open Source Software sind die Vorgänge transparent, was bei Closes Source-Software in der Regel so nicht nachgeprüft werden kann. Man ist bei Closes Source-Software auf die Zusicherungen der Hersteller angewiesen.
Nur ein Wort: Kerkhoffs‘ Prinzip:
https://de.wikipedia.org/wiki/Kerckhoffs%E2%80%99_Prinzip
Die Diskussion Open-Source oder Closed Source ist komplett sinnfrei. Wer ernsthaft Closed-Source, Security und Privacy versucht zusammen zu führen ist in meinen Augen böshaft unlauter (oder schlichtergreifend frei von Ahnung von dem, was er redet).
Man muss davon ausgehen, das Kriminelle durchaus Zugriff auf Close Source haben.
Und Kerkhoff haben ja die Banken vor ein paar Jahren demonstriert, als sie die PIN Erzeugung bei EC Karten streng geheim halten wollten, kriminelle aber schon länger den Algorithmus geknackt hatten.
Als der Algorithmus geprüft wurde,stellte sich heraus,das u.U. nur 33 PINs erzeugt werden konnten, keine 10000.
Es geht hier um den Angriffs Vektor „unerwartet eine Backdoor zu haben“. Und der ist wenn die Firmen alles selbst entwickeln kleiner. Und wenn er Auftritt ist auch nachvollziehbar woher das Problem kommt.
Open Source hat andere stärken, aber hat genau hier an dem Punkt einen Schwachstelle. Je spezialisierter der Code desto weniger Entwickler sehen ihn sich an.
Wie schwierig das ist zeigte ja die Modifikation des Linux Zufalls generators.
IIRC war es nur eine scheinbare optische Änderung am Sourcecode, ein Semicolon.
Das bewirkte, das ein Feld von der Runtime immer wieder gelöscht wurde. Das bewirkte, das der Zufallswert nicht mehr so zufällig war wie erwartet.
Wer, das real war, der diese Minimale Änderungen vorgenommen hatte ließ sich nachher nicht mehr feststellen, trotz aller Kontrollen.
Aber auch black box Software ist nicht vor korrupten Mitarbeitern gefeit.
Das muss aber noch vor der git-Einführung gewesen sein.
So arbeitet eigentlich kein Open Source Projekt mehr, dass sowas nicht bemerkbar und rück-verfolgbar ist.
es wurde zurück verfolgt, aber der Täter war RL nicht mehr ermittelbar, weil er sich tarnen konnte, und sehr aufwändig Reputation aufgebaut hat,nach dem Eingriff nicht mehr zu finden war.
Das SLSA-Framework Prinzip ist wirklich gut. Aber wer stellt sicher, dass wirklich alle OSS Projekte damit verknüpft sind? Was ist, wenn eine wichtige Linux-Funktionalität nicht darüber läuft, keinen ähnlichen Mechanismus nutzt, wird sie dann aus den Distributionen ausgeschlossen – egal wie zentral wichtig es ist? Und neben dem ganzen Linux-Kram gibts diese ganzen Java-Bibliotheken in Richtung NPM, oder diese Polyfil Geschichte neulich. Das ist doch alles unüberschaubar und unbeherrschbar, da alles in einen Topf geschüttet und anschließend ordentlich durchgerührt wird und keiner mehr weiß, was wo reinspielt.
Bei OSS gibt es noch eine Chance, dass man das eruieren kann. Aber wie sieht es bei Closed Source aus? Da werden Open Source-Bibliotheken eingebunden und alles läuft für Außenstehende im Blindflug.
Na ja… etwas schön „geredet“.
Ist zwar irgendwie Quatsch, aber das musstest du als MS Troll jetzt sagen, TBR, oder?
Wer allerdings – mit MIT ginge das – die Sourcen ins eigene Projekt einpflegt ist natürlich für die entsprechende Pflege verantwortlich. Deswegen fordern andere Modelle – die LGPL zum Beispiel – dann die Offenlegung der gesamten Sourcen.
MIT ist halt wegen des nahezu vollständigen Fehlens von Restriktionen ausgesprochen attraktiv: namentlich und beispielsweise MySQL-Connectoren, Mimekit/Mailkit oder JSON.net.
Eigentlich ist Best Practice Open-Source-Bibliotheken praktisch 1:1 zu linken, am besten generische Binaries zu verwenden und darauf zu hoffen, dass der Maintainer sich um Probleme kümmert. Nicht ganz üblich, obwohl eigentlich obligatorisch, ist es, dann dem Projekt entweder Arbeitsleistung oder Gold zukommen zu lassen.
Ein Problem ist halt, dass viele Anbieter glauben (!), dass es ihr Produkt(marketing) beschädigt, wenn sie Third-Party-Produkte kennzeichnen müssen. Da ist die Versuchung groß, die Sourcen zu integrieren… Noch schlimmer: Wenn sie wissen, dass ihre Änderungen/Anpassungen Lizenz- oder Urheberrechtsverstöße sind und sie dann die Fremdleistung im eigenen Kompilat unsichtbar machen.
An sich ist die Kombination Closed- und Open-Source ein absoluter Winner, weil man das beste aus beiden Welten zusammenführen kann. Aber: Ohne Transparenz kann das genauso gefährlich wie Closed-Source sein.
Was im Übrigen gerne untergeht: Closed-Source muss an sich natürlich nicht gefährlich sein – es ist die intransparente Verknüpfung mit betriebswirtschaftlichen Interessen. Die Transparenz könnte man mit niedrigschwelligen Auditierungspflichten durchaus herstellen – aber sowas will ja keiner…
Dann lieber jede Woche zwei Security-Albträume…
„Deswegen fordern andere Modelle – die LGPL zum Beispiel – dann die Offenlegung der gesamten Sourcen.“
Schwachstelle: Wer prüft das dann alles?
„Eigentlich ist Best Practice Open-Source-Bibliotheken praktisch 1:1 zu linken, am besten generische Binaries zu verwenden und darauf zu hoffen, dass der Maintainer sich um Probleme kümmert. “
Weitere offensichtliche Schwachstelle. Das wurde z.B. xz zum Verhängnis.
„Was im Übrigen gerne untergeht: Closed-Source muss an sich natürlich nicht gefährlich sein – es ist die intransparente Verknüpfung mit betriebswirtschaftlichen Interessen.“
Hier gillt: Entweder traut man dem Hersteller, oder nicht. Hieraus ergibt sich nicht automatisch eine Schwachstelle des Konzepts.
Nicht zu vergessen, diesen ganzen Windows-Kram, bei dem dann noch das Linux-Subsystem Dinge mit reinspült von dem M$ auch noch teilweise alte Versionen mitliefert die keiner Prüft. Da war doch letztens irgendwas ….!? Muss mal den Blog bei Günter checken.
„Aber wer stellt sicher, dass wirklich alle OSS Projekte damit verknüpft sind?“
Wer will eigentlich jemandem vorschreiben, das er sein OSS Projekt daran ausrichten muss?
Wenn es etwas überschaubares und beherrschbares sein soll, empfehle ich mal Block und Bleistift – aber aufpassen – Nachbar spickt!
Beides anfällig und das wars schon. Ob „open source“ immer schnell gefixt wird als „closed source“ möchte ich nicht behaupten wollen.
Sehe ich auch so!
„open Source“ heisst ich kann das lesen / prüfen / ändern.
„closed Source“ bedeutet – man muss es nehmen wie es ist – basta!
„Sicher“ sind beide nur innerhalb gewisser Grenzen!
„open Source“ heisst ich kann das lesen / prüfen / ändern.“
korrekt, wenn ich das selnst kann.
Oder ich verlasse mich darauf das andere das prüfen und etwas finden, aber wenn das zu viele tun (auf andere verlassen) wird das natürlich auch nichts.
Es gab ja leider schon mehrere Beispiele bei denen auch OSS jahrelang Sicherheitslücken hatten und es keiner festgestellt hat.
Insofern das OSS das Potential das Lücken schnell gefunden werden können, was aber leider nicht automatisch dazu führt dass diese auch schnell gefunden werden.
also da gab es auch schon Lücken die 10+Jahre im System waren bevor sie nen Security Forscher fand… nur wer sagt dir den das er der erste war der die Lücke fand?
Er war sicher der erste der sie meldete.
/Edit/
Open Source bedeutet lediglich man hätte sie finden können!
„Beides anfällig und das wars schon. Ob „open source“ immer schnell gefixt wird als „closed source“ möchte ich nicht behaupten wollen.“
Netter Allgemeinplatz.
Wir haben auf Arbeit, im Zuge eines kleinen Disputs mit einem Softwarehersteller, mal die auf einer Handvoll Servern ausgerollte Software oberflächich untersucht. Das Produkt ist kommerziell und eigentlich closed source.
Gefunden haben wir, eingebettet in die Programmverzeichnisse, über 80 Open-Source-Module in den verschiedensten Versionsständen. Nicht ein einziges war auf dem aktuellen Versionsstand, etliche waren das selbe (z.B. 5x Apache Tomcat), aber auch in komplett unterschiedlichen Versionsständen. Teils mehrere Dinge custom zusammenkompiliert, gerne mal äkter al 2 Jahre und natürlich so nur durch Herstellerupdates aktualisierbar.
Was wir hinterher tun konnten war nur: Auf das Problem hinweisen und den Hersteller abmahnen.
Der übrigens versucht hat, das zuerst irgendwie wegzureden und nur Salami-Taktik beim Einräumen von Sicherheitsproblemen spielte.
Beim Zählen der offenen, kritischen, genauer gesagt remote exploitable Sicherheitslücken bin ich persönlich übrigens bei 20 ausgestiegen.
Was wir bei Open Sourcen hätten tun können: Patches einspielen und wieder ein sicheres System haben.
Der Weg steht allerdings nicht offen, weil der Kunde genau diese Software will. Lustigerweise genau diese Software, ein Branchenstandard und natürlich explizit als „sicher“ vermarktet.
Das Problem mit closed source ist aber tatsächlich ein grundsätzliches Problem.
Nicht zuletzt, weil immer mehr open source da hineingemischt wird. Und ich habe noch nicht eine einzige Firma gesehen, die ein vernünftiges Updatesystem für diese Programmteile am Start hatte.
Das beste war bisher von einer Firma, wo ich so eine Untersuchung schon mal gemacht hatte (zu log4j-Zeiten), die dann lapidar meinte, man könne die Open-Source-Teile, die dort nicht angepasst kompiliert waren, einfach selbst aktualisieren und bekäme dann bei Problemen trotzdem Support.
Finden musste man die mit Sicherheitslücken behaftete Software aber immer noch selbst. Oder halt ein paar Monate (2-3!) warten, bis dann auch der Hersteller diese mitgeteilt hat. Natürlich erst, nachdem er die Drop-In-Aktualisierung in seinen speziellen Installer verpackt und und diesen zum Download zur Verfügung gestellt hatte.
Trotzdem ist das – bis heute – der erlebte Premium-Standard…
Brauchst dir nur mal diverse Systemsoftware von Dell, HP, Lenovo und Co anzusehen, zur Drucker/Storage/iDrac/Ilo/…/-Verwaltung, da sieht es genauso aus. Bei der iDRAC-Software haben wir jetzt überall manuell einen neuen wget in den Programmordner geschmissen,
Sollte ein Augenmerk nicht mehr auf die Leute gelegt werden, die Software oder Produkte „untersuchen“? Von den Leuten hört man wenig, keine Ahnung wie viele es von denen überhaupt gibt…. Am Ende sind Leute die „hingucken“ und aktiv Sicherheitslücken finden, evtl. auch nur durch Zufall und den Herstellern auf den Sack gehen.
Es ist wirklich erschreckend, wie viel „Fehler“ man in Produkten findet wenn man da mal genau hinschaut. Das Harmloseste sind noch falsche Handbücher oder Beschreibungen… Man bekommt wirklich den Eindruck, dass Niemand genau hinschaut. Auch auf Kundenseite.
Es ist zwar schön, dass die Sachen dann öffentlich und transparent sind. Nur es muss dann auch Jemand hinschauen :-\ Man kann jetzt von Closes Source halten was man will, der Aufwand um da ranzukommen oder damit zu „arbeiten“ ist in vielen Fällen schon immens.
Wir hier in D haben das große Pech, daß Sicherheitslücken aufgrund des „Hacker-Paragraphen“ überhaupt nicht mehr gemeldet werden!
Ja, während einige Firmen Bounty Programme auflegen, damit die Sicherheitslücken gegen Bares gemeldet werden, bevor sie ausgenutzt werden können sind andere Firmen undankbar und zeigen lieber den Finder an, siehe Modern Solutions.
https://www.borncity.com/blog/2024/01/18/amtsgericht-jlich-verurteilt-entdecker-der-modern-solutions-schwachstelle-zu-geldstrafe-jan-2024/
So ist es „andere Firmen zeigen lieber den Finder von Sicherheitslücken an“ und das ist häufiger als man denkt nur um die eigene Unfähigkeit damit zu verbergen … unglaublich!
…. Sprich Firmen, in Form von z.B. Finanzdienstleistern die einen Müll auf deine Online- oder sonstige Sicherheit geben, hauptsache der eigene Profit stimmt. Ein Grund mehr solche Verweigerer an der Gesellschaft zumindest für einem selbst “ ganz schnell aus der Verantwortung zu nehmen“ und danach nie mehr in Erwägung zu ziehen. Im Fundament meiner Laube liegt manches wesentlich sicherer!
Wie Ralf M. schon sagte, einige Firmen haben Bounty-Programme, keine Ahnung wie ernst die sowas nehmen. Andere Firmen juckt es nicht.
Als Mitarbeiter kann man nur auf das Problem aufmerksam machen. Entweder reagiert die Firma drauf oder man muss solange nerven bis was gemacht wird oder man seinen Job los ist…..
Sofern man eine Lücke als Außenstehender findet oder den Verdacht hat sollte man die Firma informieren, die muss dann eigentlich „schauen“ und man selber ist eigentlich raus. Die meisten Leute fangen dann vermutlich an selber irgendwas zu exploiten oder meinen es reicht, wenn man nur einmal mit der Firma Kontakt aufnimmt. Wenn die Leute dann auf den Sack bekommen, kann ich total nachvollziehen. Ich gehe davon aus, dass genau hier das größte Problem in solchen Fällen liegt. Das ist dann auch schade, weil je öfter man der Firma mitteilt: „Hey, ihr habt ein Problem“ umso mehr reiten die sich theoretisch in die Scheiße wenn dann nicht reagiert wird.
Es ist aber in vielen Fällen unmöglich irgendwelche Bugs oder Ausfälligkeiten zu melden. Man findet irgendeinen Bug (der auch eine Sicherheitslücke sein könnte) auf mehreren Geräten eines Herstellers. Es gibt kein Bounty-Programm, der Support ist total unfähig, man investiert Stunden/Wochen Monate um selber rauszufinden was das Fehlerbild ist, weil der Support unfähig ist das Problem mal zu reproduzieren oder zu erkennen, dass es ein großes Problem ist.
Es gibt halt KEINE offizielle Infrastruktur/Plattform um irgendwelche Bugs zu melden. Du kannst halt auch nicht einfach in irgendwelcher Software „rumhacken“. Wobei es in einigen Situationen aber nötig wäre, weil man erst so prüfen kann, ob es eine Sicherheitslücke ist bzw. das Problem behoben wurde. Das sollte man aber nicht einfach mal so machen, sondern erst wenn man irgendwo eine Meldung abgegeben hat nach dem Motto: „Hallo, hier könnte ein Problem sein. Ich schaue mal nach und dokumentiere was ich mache“.
Ich würde das ganze mal etwas umformulieren. Ich sehe das Problem in ungepflegter OpenSource, die weit verbreitet ist und sich keiner mehr dafür zuständig fühlt und bei Software, egal ob OpenSource oder closed Source die in Abhängigkeit zu OpenSource stehen, da sie Funktionen aus anderen Quellen nutzen.
Aktuelles Beispiel wget, https://www.borncity.com/blog/2024/06/18/kritische-schwachstelle-cve-2024-38428-in-wget-dringend-handeln/
Seit der Meldung im Blog hat sich nichts getan, es ist immer noch die anfällige Version im Downloadbereich verfügbar, kein Hinweis auf der Homepage von wget und von der pecompiled Windows Variante die noch älter ist und gegen weitere ältere librarys gelinkt ist https://eternallybored.org/misc/wget/ brauchen wir gar nicht erst zu reden.
Oft genug sind die Betreuer der Seiten auf Git gar nicht mehr aktiv oder erreichbar und da ist es leider so, das diese Seiten auch nicht offline geschaltet werden, wenn bekannt ist das hier ein Sicherheitsrisiko besteht oder das Git mit Malware infiziert wurde.
Ich habe das unter meinem privaten Ubuntu 22.04 aus Interesse nachverfolgt, da dort „nur“ die Version 1.21.2 ausgegeben wird:
# wget -V
GNU Wget 1.21.2 built on linux-gnu.
Laut https*//ubuntu.com/security/CVE-2024-38428 ist das aber auch bereits darin gefixt, published 16.6.2024.
Dank an die, die’s richten!
Nachtrag, richtig geil wird das ganze dann, wenn Apps im Store von MS hochgeladen werden und MS diese modifizert https://www.borncity.com/blog/2024/04/23/microsofts-neuer-store-app-installer-mit-telemetrie-wrapper-als-sicherheitsfalle/