© liudmilachernetska / 123RF.com

Es ist mühsam und zeitaufwendig, Sicherheitslücken im Auge zu behalten und Systeme abzusichern. Der Vulnerability-Scanner von Buildroot hilft beim Schwachstellenmanagement eines Eigenbau-Linux.

Die Bedrohung der Sicherheit durch Angriffe auf IT-Systeme macht auch vor Linux-Systemen nicht halt. Das gilt insbesondere für eingebettete Systeme, bei denen Linux Marktführer ist. Ein solches Embedded-System umfasst technisch ein Füllhorn unterschiedlicher Komponenten. Als zentraler Dreh- und Angelpunkt fungiert der Linux-Kernel mit seinen diversen Gerätetreibern (siehe Kasten “Linux-Kernel-Security”). Darauf aufbauend findet sich das Userland mit einem umfangreichen Softwaremix aus beispielsweise einer Shell, Bibliotheken, einem Webserver oder einem DHCP-Client.

Tritt in einer der Komponenten eine Schwachstelle zutage, gilt es, deren Relevanz zu analysieren und abhängig vom Ergebnis ein mit Patch aktualisiertes System zu generieren. Der Aufwand, es anschließend – idealerweise Over the Air (OTA) – zu verteilen, ist immens und setzt die detaillierte Kenntnis der verbauten Software voraus, insbesondere deren Version und Patchlevel.

Getreu dem Motto “Augen zu und durch” ignorieren viele Hersteller die Problematik. Sie bauen und verkaufen frisch und fröhlich Systeme, ohne substanzielle Pflege zu betreiben. Beim Kunden verrichten die Geräte still vor sich hin werkelnd brav ihre Arbeit, manchmal über Jahrzehnte, wenn man etwa an eine Heizungssteuerung denkt. Dabei geraten sie zunehmend in Vergessenheit. Gerade bei vernetzten Systemen etablieren sich dadurch immer mehr Zeitbomben in den Kellern, Häusern, Gebäuden, Produktionsanlagen und Unternehmen. Immerhin: Der Gesetzgeber fängt an, Druck auf die Hersteller aufzubauen [1].

Nummer sicher

Eingebettete Systeme auf Linux-Basis werden gern über System-Builder wie Buildroot, Yocto oder OpenEmbedded zusammengeschraubt. Während die beiden letzten einen ausschweifenden Ressourcenhunger an den Tag legten, handelt es sich bei Buildroot um einen sehr schlanken System-Builder, den beispielsweise Tesla und SpaceX zur Erstellung der Software für ihre Fahrzeuge beziehungsweise Raketen einsetzen.

Mit der Version 2021.02 hat Buildroot ein Vulnerability Management integriert (siehe Kasten “Vulnerability Management”). Es untersucht automatisiert die jeweilige Systemkonfiguration und erstellt eine umfangreiche Tabelle (Abbildung 1) über die verwendeten Pakete, deren Lizenzen und den Softwarestand. Hinzu kommen Informationen über bekannte Sicherheitslücken, die der NVD entstammen, der National Vulnerability Database.

Abbildung 1: Die Ausgabe des Schwachstellenscanners von Buildroot.

Diese Datenbank betreibt das NIST, das National Institute of Standards und Technology der USA. Die NVD enthält eine nach Schwere klassifizierte Sammlung von Schwachstellen und Fehlkonfigurationen, die sich automatisiert und vor allem standardisiert abfragen lässt (Abbildung 2). Die Inhalte werden im JSON-Format geliefert.

Abbildung 2: Bei der NVD handelt es sich um eine Art Google für die Schwachstellensuche.

Schwachstellen sammeln

Sicherheitslücken referenziert man über eine CVE-Nummer (Common Vulnerabilities and Exposures). Die CVE-Nummer besteht neben dem Vorsatz CVE aus einer Jahresangabe plus laufender vier- oder mehrstelliger Zahl (Abbildung 3). Diese Nummern darf nur eine CVE Numbering Authority (CNA) vergeben. Zu den CNAs gehört beispielsweise die Non-Profit-Organisation MITRE Corporation, die unter anderem durch Mittel der US-Sicherheitsbehörde CISA (Cybersecurity and Infrastructure Security Agency) finanziert wird. Hersteller können ebenfalls das Recht bekommen, CVEs zu vergeben, allerdings nur für eigene Produkte.

Abbildung 3: Für das Nummerieren von Schwachstellen gibt es den CVE-Standard.

Neben einer (arg kurzen) Zusammenfassung der Sicherheitslücke enthält ein CVE-Eintrag im Wesentlichen eine Liste der betroffenen Softwareprodukte und deren Versionen. Zusätzlich gibt es noch den Veröffentlichungszeitpunkt und Links zu weiteren Infos. Bis hierhin bleibt also alles relativ dünn. Die NVD ergänzt daher den CVE-Eintrag um einen CVSS Score (Common Vulnerability Scoring System), Links zu weiterführenden Informationen, eine Kategorisierung der Schwachstelle (CWE, Common Weakness Enumeration), ein Veröffentlichungsdatum, Infos über die entdeckende Institution oder Person und potenziell existierende Absicherungsmöglichkeiten (Abbildung 4).

Abbildung 4: Die NVD reichert CVE-Einträge zu Schwachstellen mit vielen wertvollen Zusatzinfos an.

Gefahr berechnen

Beim CVSS Score handelt es sich um einen numerischen Wert, der das Sicherheitsrisiko auf einer Skala von 0 bis 10 bewertet – je höher die Zahl, desto schwerer die Lücke. Wie Abbildung 5 zeigt, ist die Berechnung des Scores standardisiert und umfasst verschiedene Faktoren wie die Angriffsquelle (Internet, lokales Netz, physisch vor Ort), die Angriffskomplexität (niedrig, hoch) sowie die zur Aktivierung notwendigen Rechte (keine, niedrig, hoch). Außerdem erfasst der Score, ob die Anwenderin oder der Anwender an der Aktivierung beteiligt sein muss (ja, nein), und wie sich ein Angriff auf Vertraulichkeit, Integrität und Verfügbarkeit auswirkt. Zudem berücksichtigt die Berechnung, ob ein Exploit bereits bekannt oder sogar im Umlauf ist.

Abbildung 5: Der CVSS Score erfasst akribisch den Schweregrad einer Lücke.

Die CVEs enthalten die Information über betroffene Softwareprodukte und deren Version in Form sogenannter Common Platform Enumerations. Diese ebenfalls standardisierten CPEs enthalten unter anderem den Namen des Herstellers sowie den Namen und die Version des Produkts (Abbildung 6). Bereitgestellt werden die CPEs wiederum durch das NIST. Die NVD sammelt sämtliche CPEs und stellt die Querverbindungen zu den CVEs her.

Abbildung 6: Die CPEs enthalten standardisierte Versionsinformationen.

Buildroot erstellt über den Aufruf »make pkg-stats« eine Übersicht für das Schwachstellenmanagement in Form einer HTML-Datei und eines JSON-Files. Die HTML-Datei kann man leicht in einem Webbrowser ansehen. Unten auf der Seite findet sich zunächst eine generelle Statistik. Sie führt beispielsweise auf, wie viele Pakete up to date oder eben in einer älteren Version zum Einsatz kommen, wie viele Pakete von CVEs betroffen sind und wie vielen Paketen Lizenzinformationen fehlen (Abbildung 7).

Abbildung 7: Statistische Informationen vermitteln einen ersten Überblick.

Ansonsten listet die Übersicht für jedes einzelne Paket, ob eine Lizenzinformation existiert und ob die Lizenz selbst beiliegt, welche Version konfiguriert ist und ob es eine aktuellere Version gibt. Ein Link verweist auf die zur Software gehörenden Download-Quelle im Internet. Zudem finden sich noch alle für das Produkt relevanten CVEs, wobei solche, die für die ausgewählte Version/Konfiguration keine Rolle spielen, explizit aufgeführt werden. Als Letztes erscheint schließlich – falls vorhanden – die zugehörige CPE ID.

Rot bedeutet Gefahr

Kritische Felder markiert Buildroot in der HTML-Ausgabe rot. Abbildung 1 zeigt, dass die Anzahl der roten Felder beträchtlich ist, wobei die Entwicklerin oder der Entwickler jedes einzelne durchsehen muss. Die roten Felder weisen auf unbekannte Lizenzen, veraltete Version oder dem Produkt nicht eindeutig zuzuordnende CPEs hin.

Tatsächlich sind zum einen die in Buildroot verwendeten Versionen nicht hundertprozentig konform zu den CPE-Kennungen, zum anderen erweist sich das CPE-Verzeichnis der NVD als unvollständig oder teilweise fehlerhaft. Buildroot muss nämlich die CPE-Versionen selbständig generieren und leitet diese aus dem Namen des Pakets oder Projekts ab. Allerdings kann man durch Setzen entsprechender Variablen dem Generierungsalgorithmus unter die Arme greifen, sodass die CPEs tatsächlich matchen.

Die bis hierhin genannten Aspekte genügen noch nicht zur substanziellen Bewertung der potenziellen Schwachstellen. Glücklicherweise tauchen in der HTML-Ausgabe die CVEs als anklickbare Links auf, die zum zugehörigen Datensatz führen. Da aber die CVEs selbst keinen CVSS Score enthalten, muss man sich– ebenfalls per Klick auf einen Link – zur NVD weiterleiten lassen. Dort finden sich endlich die relevanten Informationen, die es allerdings ab dieser Stufe mehr oder minder händisch auszuwerten gilt: Unter Umständen hat Buildroot die Schwachstelle bereits gepatcht, und das Vulnerability Management konnte dazu keine Info finden.

Jetzt gilt es, geeignete Maßnahmen zu ergreifen (sichere Konfiguration, Patch einspielen, Software durch eine Alternative ersetzen oder abwählen), das System neu zu generieren, es fürs Update freizugeben und es schließlich zu verteilen.

Eigenbau

Listing 1 fasst die notwendigen Arbeiten zusammen, um sich mit überschaubarem Aufwand selbst ein Bild von der Arbeitsweise des Vulnerability Managements und der Ausgabe zu machen.

Zunächst konfigurieren Sie auf einem Ubuntu ein Buildroot-System etwa für eine ARM-64-Bit-Plattform (AArch64). Dazu installieren Sie im Rahmen der Vorbereitung die Pakete flex, bison, build-essentials, libncurses-dev, qemu, uml-utilities, libssl-dev und python3-pip. Über den Python-Installer Pip ziehen Sie dann Module aiohttp und ijson nach.

Per Git holen Sie sich zu guter Letzt Buildroot auf die eigene Maschine, konfigurieren es für die ARM-64-Architektur und rufen einmal die Konfigurationsoberfläche per »make menuconfig« auf. Hier können Sie noch Pakete an- oder abwählen. Zum Verlassen drücken Sie einfach [Esc] und quittieren die Nachfrage Do you wish to save your new configuration mit Yes respektive durch einen Druck auf die Eingabetaste. Das nachfolgende »make« generiert ein Selbstbau-Linux.

Auf einem aktuellen Notebook müssen Sie für diesen Vorgang eine gute Stunde einplanen. Buildroot lädt in dieser Zeit die notwendigen Softwarepakete auf die Maschine, zieht eventuell notwendige Patches, generiert essenzielle Werkzeuge und erstellt schließlich die Systemkomponenten selbst. Diese schraubt es dann zum Gesamtsystem zusammen, das im Verzeichnis »output/images/« landet. Sie testen das System, indem Sie dort das Skript »start-qemu.sh« aufrufen (Abbildung 8).

Abbildung 8: Buildroot unterzieht ein selbst gebautes Linux einem Test.

### Benötigte Entwicklerpakete
$ sudo apt install build-essentials python perl flex bison git libncurses-dev qemu uml-utilities libssl-dev python3-pip
### Schwachstellenmanagement
$ pip install aiohttp
$ pip install ijson
### Buildroot installieren
$ git clone git://git.buildroot.org/buildroot
$ cd buildroot
### Selbstbau-Linux konfigurieren
$ make qemu_aarch64_virt_defconfig
$ make menuconfig
### System generieren
$ make
### Selbstbau-Linux starten
$ output/images/start-qemu.sh

Alter Verwalter

Da Sie sich für potenzielle Sicherheitslücken interessieren, nehmen Sie durch Aufruf von »make pkg-stats« noch eine Vulnerability-Analyse vor. Das gestartete Python-Skript wertet die konfigurierten Pakete aus, erstellt die CPEs, erledigt den Abgleich über die NVD, evaluiert nützliche Zusatzinfos wie die Lizenzen und schreibt das Ergebnis in Form je einer HTML- und JSON-Datei ins Verzeichnis »output/«. Das ganze dauert typischerweise keine fünf Minuten. Die Datei »pkt-stats.html« sehen Sie sich im Webbrowser an, das Gegenstück »pkt-stats.json« ermöglicht eine automatisierte Weiterverarbeitung.

Für ein Vulnerability Management genügt es logischerweise nicht, diese Statistik nur während der Systementwicklung erstellen zu lassen und auszuwerten. Vielmehr erfordert das Security Vulnerability Tracking eine periodische Auswertung, die Sie beispielsweise per Cron einrichten. Ein mitgestartetes Skript könnte die JSON-Ausgabe nach relevanten Änderungen scannen und bei Auftreten eine E-Mail versenden. Der nachfolgende Schritt, ein fehlerbereinigtes System zu bauen [2] und es als authentifiziertes Update [3] an die betroffenen Kunden auszuliefern, ist alles andere als trivial, wie wir bereits in früheren Folgen dieser Kolumne thematisiert haben. Und dass nach einem Fehler vor einem Fehler ist, braucht man eigentlich nicht gesondert zu erwähnen. (jlu)