Alles, was Sie über den Umgang mit Sicherheitslücken in Linux-basierten Containern wissen wollten

Denken Sie an das wichtigste Container-Image, das gerade in Ihrer Produktionsumgebung läuft. Wie haben Sie dessen Basis-Image ausgewählt? Wissen Sie, wie viele Sicherheitslücken es enthält? Möchten Sie das nicht wissen?

Bei Snyk möchten wir die Auswahl des sichersten Basis-Images intelligenter, reibungsloser und vor allem datenbasierter gestalten.

Doch beginnen wir zunächst mit einem Überblick über die Sicherheit von Linux-Distributionen, denn in diesem Blogbeitrag geht es um Linux-basierte Images.

Linux-Distributionen kurz erklärt

Eine Linux-Distribution (Distribution) ist ein Betriebssystem (OS), das aus einer Sammlung von Software besteht. Dazu gehören ein Linux-Kernel (der Kern des Betriebssystems), ein Paketverwaltungssystem sowie GNU-Tools und -Bibliotheken, weitere Software und Dokumentation. All dies wird gebündelt und von den Verantwortlichen so angepasst, dass die Funktionen optimal auf die Anforderungen verschiedener Plattformen und Geräte abgestimmt sind.

Distributionen werden in der Regel auf zwei Arten bereitgestellt:

• als kompilierte Binärdateien (gepackte Images), die in Image-Repositories wie Docker Hub zum Download bereitstehen. Die Images werden in der Regel aus Bibliotheken erstellt, die als Quellcode gepflegt werden.

• als Quellcode, der Änderungen an der Originalsoftware ermöglicht. Das sorgt für große Flexibilität, zumal der Großteil der in der Distribution enthaltenen Software in der Regel Open Source ist.

Heute gibt es Hunderte Linux-Distributionen, von denen die meisten aktiv gepflegt werden. Dank ihrer großen Verfügbarkeit und flexiblen Funktionen kommen sie auf den unterschiedlichsten Plattformen und Geräten zum Einsatz – auch in Containern.

Wie jede andere Software sind auch Container anfällig für Angriffe, wenn ihr Code Sicherheitslücken enthält.

Wie unterscheidet sich die Sicherheit der verschiedenen Linux-Distributionen und ihrer Releases?

Die einzelnen Distributionen werden unterschiedlich erstellt und gepflegt. Unterschiede gibt es beispielsweise bei der Zusammenstellung der Komponenten und ihrer Verwaltung. Sie wirken sich unter anderem auf die Größe der Distribution, die Paketverwaltung und die Anfälligkeit für Sicherheitslücken aus.

Eine Sicherheitslücke in einer Komponente kann je nach Distribution unterschiedlich bewertet werden. Eine in mehreren Distributionen verbreitete Komponente kann in einer als sicher gelten, während sie in einer anderen einen hohen CVE-Score erhält – allein aufgrund der unterschiedlichen Art, wie die Distributionen zusammengestellt sind.

Einige Distributionen sind in der Regel auch sicherer als andere, weil ihre Verantwortlichen entsprechende Mechanismen in die Pflege integriert haben. Kommerzielle und etablierte Distributionen (Debian, Ubuntu, CentOS, Oracle) verfügen über eigene Sicherheitsteams. Diese prüfen CVE-Scores, priorisieren und implementieren Sicherheitskorrekturen und sorgen allgemein für die Sicherheit der Distribution.

Doch auch zwischen den verschiedenen Optionen gibt es Unterschiede. Die folgende Tabelle zeigt, wie sich die Verwaltung dieser großen Distributionen unterscheidet – ein Faktor, der sich ebenfalls auf ihre Sicherheit auswirkt:

*Alpine verfolgt bei der Pflege von Images einen anderen Ansatz: Die Pakete werden regelmäßig aktualisiert, wobei Sicherheitskorrekturen für eine kleine Auswahl wichtiger Pakete wie curl usw. hinzugefügt werden.

Wie unterscheidet sich eine Linux-Distribution von einem Sprachökosystem?

Sprachökosysteme speichern Pakete in Registries; Paketverwaltungen wie npm und pip sind dafür zuständig, diese Pakete aktuell zu halten. Auch Distributionen werden in Paket-Repositories gespeichert, damit sie in verschiedenen Projekten als Abhängigkeiten wiederverwendet werden können. Sie werden jedoch als Images gepackt und anschließend getrennt in speziell dafür vorgesehenen Image-Repositories abgelegt, von wo sie sofort in anderen Projekten verwendet werden können. Nach der Paketierung und Bereitstellung zum Download werden die Images in eigenen Paket-Registries gespeichert und dort von ihren Paketverwaltungen unabhängig von den ursprünglichen Bibliotheken aktualisiert.

In beiden Fällen ist die Paketverwaltung dafür zuständig, das Paket regelmäßig herunterzuladen, zu aktualisieren und anschließend wieder in den Speicher hochzuladen.

Hier enden jedoch die Gemeinsamkeiten.

Pakete in Programmiersprachen-Ökosystemen pflegen

Bei Paketen in Sprachökosystemen ist die Sache recht einfach: Es gibt eine Paket-Registry, mindestens eine Paketverwaltung und eine direkte, unkomplizierte Beziehung zwischen beiden. Die Paketverwaltung lädt Pakete aus der Registry herunter und wieder dorthin hoch.

Das lässt sich anhand des folgenden Diagramms veranschaulichen: links ein allgemeines Beispiel für ein beliebiges Paket-Repository, rechts ein Beispiel speziell für npm.

Pakete in Distributions-Repositories pflegen

Bei Distributionen in Image-Repositories ist die Sache dagegen etwas komplizierter. Eine Distribution kann mehrere Repositories, Paketverwaltungen und Upload-Tools verwenden. Welches Repository, welche Paketverwaltung und welches Upload-Tool zum Einsatz kommen, hängt unter anderem von der Release-Nummer und dem Umfang der Distribution ab (main, contributions, non-free, community).

Das lässt sich anhand des folgenden Beispiels veranschaulichen: links ein allgemeines Paket-Repository für eine beliebige Distribution in einer beliebigen Version, rechts mehrere Debian-Releases.

Jedes Debian-Release verwendet das Repository, das für das jeweilige Release vorgesehen ist.

Pakete und ihre Versionen sind nicht immer in allen Repositories verfügbar. Bei einigen Distributionen können Pakete zurückportiert werden (Paketversionen, die nur für einen Release-Typ verfügbar sind, lassen sich dann auch für einen anderen installieren). Manche Pakete können einer Distributionsversion direkt aus einem externen Repository hinzugefügt werden, zum Beispiel aus einem Personal Package Archive (PPA) für Ubuntu, statt über die native Paketverwaltung. Diese komplexe Beziehung zwischen Paketen und Distributionen unterscheidet sich von der einfachen Beziehung zwischen Paket-Registries und Paketverwaltungen, die deutlich weniger von den beschriebenen Versionsproblemen betroffen ist.

Die Herausforderungen beim Beheben von Container-Sicherheitsproblemen

Die meisten Sicherheitsteams von Distributionen pflegen Sicherheitskorrekturen nur für einen Teil ihrer Komponenten. Debian stellt beispielsweise offiziell nur für die Hauptkomponenten Sicherheitskorrekturen bereit, wie in der Dokumentation beschrieben. Grund dafür ist der komplexe Prozess, die verschiedenen Images im Zeitverlauf zu prüfen und zu priorisieren.

Wie bereits erwähnt, werden Images aus ihrem Quellcode erstellt, der üblicherweise separat in Open-Source-Bibliotheken vorliegt. Nach der Paketierung wird ein Image in einem eigenen Repository gespeichert und gepflegt. Dort entwickelt es sich unabhängig von der Quellcodebibliothek weiter, die ihrerseits ihren eigenen Versionsverlauf hat. Das bedeutet: Eine Sicherheitslücke in der Bibliothek muss nicht auch im Image vorhanden sein. Ist sie in einer späteren Version der Bibliothek aufgetreten, betrifft sie das bereits paketierte Image möglicherweise gar nicht. Umgekehrt kann dasselbe ebenfalls gelten.

Wird eine Sicherheitslücke in einer Bibliothek entdeckt, auf der ein Image basiert, müssen die Sicherheitsteams das Image entsprechend prüfen. Dabei verifizieren sie, ob die Sicherheitslücke überhaupt vorhanden ist und ob sie angesichts der Zusammensetzung des Images tatsächlich als Sicherheitslücke einzustufen ist.

Die Versionen der meisten älteren, etablierten Distributionen werden nicht grundlegend aktualisiert. In der Regel erhalten sie kleinere Updates und Sicherheitskorrekturen für neu entdeckte Sicherheitslücken.

Sehr alte Distributionen, deren Supportende erreicht ist (End of Life, EOL), sowie ganz neue Distributionen (Edge-Versionen, für die das Sicherheitsteam möglicherweise noch nicht zuständig ist) gelten bei den meisten Distributionen häufig als nicht gepflegt. Debian 7 ist beispielsweise EOL. Betrifft eine Sicherheitslücke Version X eines Pakets, das nur für EOL-Releases oder ganz neue Releases verfügbar ist, wird sie möglicherweise nicht in den Sicherheitshinweisen der Distribution aufgeführt. Daher spiegelt der Umfang des Sicherheitssupports für EOL- und hochmoderne Releases nicht unbedingt den tatsächlichen Sicherheitszustand der Distribution wider. In diesen Fällen reichen die verfügbaren Informationen für Snyk nicht aus, um alle Sicherheitslücken zu erkennen; selbst einige kritische Sicherheitslücken können unentdeckt bleiben.

Warum wird meine Linux-Distribution nicht unterstützt?

Jedes von uns unterstützte Image auf Distributionsbasis wird anhand unserer Datenbank für Sicherheitslücken entsprechend seiner Distribution und seines Releases gescannt. Nach dem Scan listen wir die Sicherheitslücken mit Details zu ihrer Ursache und dazu auf, ob sie behoben sind, welche Distributionen und Releases betroffen sind und ab welcher Version die Korrektur verfügbar ist.

Bei der Zusammenstellung unserer Sicherheitslückendaten halten wir uns nach Kräften über jedes neue Release auf dem Laufenden und planen entsprechend voraus. Außerdem beobachten wir die Aktivitäten und Anforderungen unserer Nutzerinnen und Nutzer genau, um unsere Datenbank gezielt zu erweitern. Sie können sich jederzeit über support@snyk.io oder unseren Twitter-Account an uns wenden. Darüber hinaus bemühen wir uns besonders, die LTS-Releases der Anbieter zu unterstützen, die wir in diesem Beitrag vorgestellt haben. Dennoch können wir nicht jede Distribution unterstützen. Wenn Ihr Image beispielsweise auf einer sehr alten oder ganz neuen Distribution basiert, wird sie von Snyk wahrscheinlich nicht unterstützt.

Wie findet Snyk sichere Basis-Image-Alternativen, die empfohlen werden können?

Wir erfassen außerdem regelmäßig Daten aus einer großen Auswahl an Repositories und rufen mehrmals täglich alle Tags pro Repository von Docker Hub ab, damit unsere Daten aktuell bleiben. Anhand dieser Informationen können wir Ihnen auch Empfehlungen zur Behebung mit Basis-Images (oder übergeordneten Images) geben – vorausgesetzt, Sie haben Ihre Snyk-Projekte mit der zugehörigen Dockerfile verknüpft.

Wenn Sie mit den Anwendungsscans von Snyk vertraut sind, kennen Sie es vielleicht, dass pro überwachtem oder getestetem Repository nur einige bis einige Dutzend Sicherheitslücken gefunden werden. Im Linux-Ökosystem sind die Zahlen jedoch ganz anders: Einige Hundert Sicherheitslücken sind keine Seltenheit.

Das kann überwältigend sein. Deshalb möchten wir Ihnen möglichst konkrete Empfehlungen und Erkenntnisse zu Ihrem Image und den Sicherheitslücken liefern. Dafür bitten wir Sie um die Dockerfile, die häufig Teil eines Container-Projekts ist.

Wenn Sie Ihre Images mit Snyk scannen, können Sie einen Link zu Ihrem Quellcode hinzufügen, in dem Sie das Dockerfile gespeichert haben. Sobald wir das Repository gescannt haben, können wir auf Grundlage der Ergebnisse Empfehlungen zur Behebung geben. In unserer Dokumentation erfahren Sie mehr darüber, wie Sie auf Ihr Dockerfile verlinken.

Sobald uns das Dockerfile vorliegt, erkennen wir das Basis-Image. So können wir feststellen, wie viele Schwachstellen auf das Basis-Image und wie viele auf andere, durch das Dockerfile hinzugefügte Layer zurückzuführen sind. Das hilft Ihnen sowohl bei der Entscheidung, ob Sie die anderen Layer im Dockerfile anpassen sollten, als auch dabei, ob Sie das Basis-Image durch ein sichereres Image ersetzen sollten.

Um passende Upgrades vorzuschlagen, rufen wir kontinuierlich Dutzende Repositories und Hunderte von Tags ab und scannen sie. Anschließend gleichen wir unsere Image-Datenbank mit unserer Datenbank zu Sicherheitslücken ab, um das sicherste verfügbare Image mit aktuellen Ergebnissen zu finden. Dann schlagen wir Tags des Repositorys für Ihr Basis-Image vor, darunter:

• ein Minor-Upgrade – wie der Name schon sagt, ein Tag für ein Minor-Upgrade gegenüber Ihrem aktuellen Tag. Oft lassen sich schon mit einem Minor-Upgrade Dutzende oder sogar Hunderte Schwachstellen beseitigen. Warum sollten Sie es also nicht zumindest ausprobieren?

• eine Option für ein Major-Upgrade – durch den Sprung zur nächsten Hauptversion aktualisieren

• eine alternative Lösung – wir empfehlen andere, nicht verwandte Images, die sich für Ihren Container eignen könnten

Wir betrachten ein alternatives Tag unter folgenden Bedingungen als Upgrade-Kandidaten:

• Es weist weniger Schwachstellen mit hohem Schweregrad auf oder dieselbe Anzahl solcher Schwachstellen, aber weniger Schwachstellen mit mittlerem Schweregrad, sowie gleich viele oder weniger Schwachstellen mit niedrigem Schweregrad.

• Die Betriebssystemdistribution des Tags für das Kandidaten-Image ist weder zu alt noch brandneu, keine Nicht-LTS-Version und nicht instabil.

• Da Sicherheitswarnungen für Alpine-Distributionen nur für eine kleine Auswahl gepatchter Pakete verfügbar sind, bieten Alpine-basierte Images nur begrenzte Einblicke in ihre Sicherheit. Deshalb empfehlen wir keine Alpine-basierten Tags.

Alternative Upgrades können Tags anderer Distributionen verwenden und sind daher in der Regel mit einem deutlich höheren Änderungsrisiko verbunden. Dennoch möchten wir Ihnen möglichst viele Informationen zu den verfügbaren Optionen geben, damit Sie Ihr Image absichern können.

Fazit

Container unterscheiden sich von Bibliotheken und machen Sicherheit und Triage zweifellos anspruchsvoller. Gleichzeitig sind Container aufgrund ihrer offensichtlichen und wichtigen Vorteile allgegenwärtig. Das bedeutet jedoch nicht, dass Sie unsichere Container bereitstellen müssen! Mit etwas Planung und geeigneten Sicherheitstools wie Snyk können Sie den Prozess der Container-Absicherung deutlich vereinfachen.

In jedem Fall ist es wichtig, Ihre Container regelmäßig zu triagieren, damit sie so sicher wie möglich bleiben. Wenn Sie eine Schwachstelle entdecken und sie durch den Austausch Ihres Basis-Images beheben müssen, sollten Sie Folgendes beachten, damit Ihr Container sicher bleibt und weiterhin funktioniert:

• Prüfen Sie, ob Sie von einem Betriebssystempaket abhängig sind. Falls ja, stellen Sie sicher, dass das Upgrade diese Abhängigkeit nicht beeinträchtigt.

• Berücksichtigen Sie die Größe des Images.

• Wenn Sie ein alternatives Upgrade in Betracht ziehen, sollten Sie auch alle distributionsspezifischen Befehle und Funktionen prüfen, die Sie verwenden, und sie entsprechend anpassen.

Scannen Sie Ihre Images noch heute mit Snyk.