Mehr Sicherheit für Linux und OSS gefragt

Linux ist überall. Alle Clouds, sogar Microsoft Azure, laufen damit.  Es sorgt dafür, dass alle 500 der Top-500-Supercomputer funktionieren. Sogar Desktop-Linux wächst, wenn man Pornhub glauben darf, dass die Zahl der Linux-Nutzer um 28 % gestiegen ist, während die Zahl der Windows-Nutzer um 3 % zurückging.

Auch Open-Source-Software wächst sprunghaft an. Laut dem Hype Cycle 2021 von Gartner für Open-Source-Software (OSS): „Bis 2025 werden mehr als 70 % der Unternehmen ihre IT-Ausgaben für OSS erhöhen, verglichen mit ihren derzeitigen IT-Ausgaben. Darüber hinaus wird Software as a Service (SaaS) bis 2025 das bevorzugte Nutzungsmodell für OSS werden, da es eine bessere betriebliche Einfachheit, Sicherheit und Skalierbarkeit bietet.“

In Bezug auf Datenbanken, dem Herzstück der Unternehmenssoftware, prognostiziert Gartner, dass über 70 % der neuen internen Anwendungen auf einer Open-Source-Datenbank entwickelt werden. Gleichzeitig werden 50 % der bestehenden proprietären relationalen Datenbankinstanzen auf Open-Source-DBMS umgestellt worden sein oder werden derzeit umgestellt.

Aber mit großer Macht kommt auch große Verantwortung. Das musste viele Entwickler kürzlich feststellen, als mehrere Sicherheitslücken in der Apache-Java-Logging-Open-Source-Bibliothek log4j2 entdeckt wurden.   Die log4j2-Probleme sind schlimm. Auf der Skala der National Vulnerability Database (NVD) wird es mit 10,0 CVSSv3 bewertet, was absolut furchtbar ist.

Das eigentliche Problem liegt nicht so sehr bei Open-Source selbst. Open-Source-Methodik und Sicherheit haben nichts Magisches an sich. Sicherheitsfehler können immer noch in den Code eindringen. Wenn nicht genug Entwickler auf Security achten, werden Sicherheitslücken immer noch unbemerkt bleiben.

Das wirkliche Problem mit log4j ist jedoch, dass Java die Bibliotheken, die sein Quellcode und seine Binärdateien verwenden, in zahlreichen JAR-Varianten versteckt. Das Ergebnis? Es kann sein, dass Sie eine verwundbare Version von log4j benutzen und es nicht wissen, bis es ausgenutzt wird.

Josh Bressers, Vice President of Security bei Anchore, erklärte kürzlich: „Eine der Herausforderungen, die die log4j-Schwachstelle mit sich bringt, besteht darin, sie tatsächlich zu finden. Java-Anwendungen und Abhängigkeiten sind in der Regel in einer Art Paketformat verpackt, das die Verteilung und Ausführung sehr einfach macht, aber es kann schwierig sein, herauszufinden, was in diesen Softwarepaketen enthalten ist.“ Glücklicherweise gibt es log4j-Scanner, die Ihnen helfen können, fehlerhafte log4j-Bibliotheken zu erkennen. Aber sie sind nicht perfekt.

Hinter dem log4j-Schlamassel verbirgt sich ein weiteres Problem, nämlich: „Woher wissen Sie, welche Open-Source-Komponenten Ihre Software verwendet?“ log4j2 zum Beispiel wird seit 2014 verwendet. Man kann nicht erwarten, dass sich jemand daran erinnert, ob er diese erste Version in einem Programm verwendet hat, das man heute noch benutzt.

Die Antwort ist eine, die die Open-Source-Gemeinschaft in den letzten Jahren ernst genommen hat: Die Erstellung von Software Bills of Material (SBOM). Eine SBOM gibt genau an, welche Softwarebibliotheken, Routinen und anderer Code in einem Programm verwendet wurden. Damit können Sie untersuchen, welche Komponentenversionen in Ihrem Programm verwendet werden.

Wie David A. Wheeler, Director of Open Source Supply Chain Security bei der Linux Foundation, erklärt hat, können Sie durch die Verwendung von SBOMs und verifizierten, reproduzierbaren Builds sicherstellen, dass Sie wissen, was in Ihren Programmen enthalten ist. Wenn eine Sicherheitslücke in einer Komponente gefunden wird, können Sie sie einfach flicken, anstatt wie ein Verrückter nach möglichem Problemcode zu suchen, bevor Sie ihn beheben können.

„Ein reproduzierbarer Build“, erklärt Wheeler, „ist ein Build, der bei gleichen Eingaben immer die gleichen Ergebnisse liefert, so dass die Build-Ergebnisse überprüft werden können. Ein verifizierter, reproduzierbarer Build ist ein Prozess, bei dem unabhängige Organisationen einen Build aus dem Quellcode erstellen und verifizieren, dass die Build-Ergebnisse aus dem angegebenen Quellcode stammen.“

Dazu müssen Sie und Ihre Entwickler Ihre Programme in einem SBOM unter Verwendung des Software Package Data Exchange (SPDX)-Formats der Linux Foundation verfolgen. Um sicherzustellen, dass Ihr Code auch wirklich das ist, was er vorgibt zu sein, müssen Sie Ihr SBOM mit Diensten wie dem Codenotary Community Attestation Service und Tidelift Catalogs beglaubigen und verifizieren.

All dies ist leicht gesagt. Es zu tun ist schwer. Im Jahr 2022 werden so gut wie alle Open-Source-Entwickler viel Zeit damit verbringen, ihren Code auf Probleme zu prüfen und dann SPDX-basierte SBOMs zu erstellen. Die Benutzer werden dies aus Sorge vor Solarwind-Katastrophen und log4j-Sicherheitsproblemen fordern.

Gleichzeitig arbeiten die Linux-Entwickler an der weiteren Absicherung des Betriebssystems, indem sie Rust zur zweiten Sprache von Linux machen. Und warum? Weil Rust im Gegensatz zu C, der Hauptsprache von Linux, viel sicherer ist. Insbesondere ist Rust bei der Behandlung von Speicherfehlern viel sicherer als C.

Wie Ryan Levick, ein leitender Cloud-Entwickler bei Microsoft, erklärte: „Rust ist absolut speichersicher“. Das ist eine große Sache, denn wie die Linux-Kernel-Entwickler Alex Gaynor und Geoffrey Thomas auf dem Linux Security Summit 2019 betonten, sind fast zwei Drittel der Sicherheitslücken im Linux-Kernel auf Speichersicherheitsprobleme zurückzuführen. Und woher kommen diese? Inhärente Probleme mit C und C++.

Jetzt wird Linux in Rust neu geschrieben. Zumindest nicht in diesem Jahrzehnt, sondern erst wieder in den 2030er Jahren, aber viele Linux-Treiber und anderer Code werden in Zukunft in Rust geschrieben werden.

Linus Torvalds sagte, dass er zwar „in keiner Weise auf Rust drängt“, aber „offen dafür ist, wenn man die versprochenen Vorteile bedenkt und einige Sicherheitsfallen vermeidet. Dennoch, so schloss er, „weiß ich auch, dass sich Versprechungen manchmal nicht bewahrheiten“.

Die Sicherung des Codes wird im Jahr 2022 das wichtigste Thema für Linux- und Open-Source-Entwickler sein.  Sie sind beide zu wichtig geworden, als dass es anders sein könnte.