Update für altes Embedded-Linux-Board
Verfügbarkeits- Retrofit mit Security-Perspektive
Im ersten Moment hört sich die Aufgabenstellung einfach an: Ein Embedded-Modul mit Open-Source-Betriebssystem und einer C/C++-Anwendung soll aufgrund von Bauteilbeschaffungsproblemen durch einen Nachfolger mit Verfügbarkeitsgarantie ersetzt werden. Ganz so einfach war die Lösung dann aber nicht.
Insgesamt geht es um eine Baugruppe zur Lösung sehr spezieller Messaufgaben, die in Deutschland entwickelt und hergestellt, aber weltweit eingesetzt wird (Bild 1). Auf der Baugruppe kommt ein FPGA zum Einsatz, in dem wichtige Funktionen zur Erfassung von Echtzeit-Messdaten realisiert sind. Zur Integration der gesamten Messvorrichtung in die Anwenderumgebung existiert eine 10/100-Mbit/s-Ethernet-LAN-Verbindung.
Jobangebote+ passend zum Thema
Zwischen dem FPGA und dem Ethernet-LAN ist ein Embedded-Linux-Rechnermodul zu finden, auf dem eine in C/C++ erstellte Anwendersoftware läuft. Bis auf wenige digitale I/Os nutzt diese Software sowohl für FPGA-I/O-Buszugriffe als auch die LAN-Kommunikation ausschließlich das Treiberkonzept des Embedded-Linux-Betriebssystems.
Da die Embedded-Modulhardware unter dem Namen »ADNP/1520« schon seit fast zwanzig Jahren gefertigt wird, haben sich inzwischen Beschaffungsprobleme mit dem 32-bit-x86-Microcontroller AMD Elan SC520, aber auch hinsichtlich der DRAM- und Flash-Speicher eingestellt. Insofern sollte mit dem ADNP/2586 ein Nachfolger entwickelt werden, der zu »100% ADNP/1520-kompatibel« ist und ohne Schaltungs- und Anwendungssoftwareänderungen in der Messtechnikbaugruppe genutzt werden kann.
Zur Kompatibilität gehören nicht nur die mechanischen Abmessungen sowie das Pinout, sondern auch eine nahezu identische Stromaufnahme und Wärmeentwicklung. Besonders wichtig sind des weiteren Signale und Zeitverhalten des I/O-Bussystems zum FPGA, das bedingt durch den SC520 einer Embedded-PC-Funktionalität entspricht. Insofern entschied sich das Entwicklerteam für einen Vortex86DX-SoC von DMP, um den SC520-Mikrocontroller zu ersetzen (siehe Tabelle).
Backport oder neues Linux?
Auch wenn das Primärziel des ADNP/2586-Vorhabens die Sicherstellung der Produzierbarkeit für die nächsten fünf bis zehn Jahre war, kam während der Projektplanung neben den Hardwareaspekten doch sehr früh eine entscheidende Frage auf: Kann man in 2023 einen Embedded-Linux-Rechner als Retrofit neu entwickeln und mit einem über 20 Jahre alten Linux-Kernel und einem ebenso alten Root-Dateisystem ausstatten, um eine möglichst vollständig kompatible Laufzeitumgebung für den Anwendungscode zu schaffen – also idealerweise binärkompatibel? Hardware-technisch wäre das möglich (Bild 2).
Aus Sicht der Cybersecurity ist eine solche Aktion allerdings inzwischen unverantwortlich. Insofern wurde im Entwicklerteam über einen möglichen Security-Backport für einen Linux-Kernel der Version 2.4 diskutiert. Die Komplexität dieses Vorhabens wird allerdings schon beim Versuch deutlich, eine Grobübersicht der bekannten Sicherheitslücken für ein altes Betriebssystem inklusive der Laufzeitumgebung (z. B. Bibliotheken und Skripte innerhalb des Root-Dateisystems) zu erstellen. Man müsste verschiedene Quellen mit sehr umfangreichen Inhalten sichten und ggf. sogar mit geeigneten Werkzeugen selbst nach Sicherheitslücken und Schwachstellen suchen.
Ein möglicher Startpunkt wäre die bis ins Jahr 2001 zurückreichende CERT-Advisories-Liste der Carnegie Mellon University [1]. Deutlich effektiver ist allerdings die Nutzung der MITRE-Common-Vulnerabilities-and-Exposures(CVE)-Liste [2] im Internet – siehe hierzu auch den Abschnitt »Was sind CVEs?«. Über eine Webseite wie www.cvedetails.com lässt sich die gesamte Liste der bisher veröffentlichten CVEs sehr komfortabel durchsuchen. Mit Suchbegriffen wie »Linux 2.4«, »BusyBox 0.60«, »GNU gcc« und »GNU glibc« erhält man eine Übersicht bekannter Sicherheitslücken. Der Umfang überraschte allerdings, alleine zum Linux-Kernel 2.0 sind schon ca. 1.900 Sicherheitslücken zu finden. Zu jedem CVE wird ein Common-Vulnerability-Scoring-System(CVSS)-Wert mit einer Ampelfarbe zum Schweregrad der jeweiligen Sicherheitslücke angezeigt. Im Rahmen der Vorbereitung eines Backporting sind daher mehrere Tausend CVEs zu sichten und zu bewerten.
Spätestens nach dieser Erkenntnis war dem Entwicklerteam allerdings klar, dass eine solche Vorgehensweise nicht infrage kommt. Als einzige mögliche Handlungsalternative wurde der Einsatz eines aktuellen Linux-Kernels plus eines ebensolchen Root-Dateisystems beschlossen. Die Wahl fiel daher auf die Linux-Kernel-Version 6.1, für den ein 10-Jahres-Langzeit-Support bis August 2033 durch das Civil-Infrastructure-Platform(CIP)-Projekt existiert. Das Root-Dateisystem basiert auf Debian Bookworm (Debian 12) und Squashfs, um ein komprimiertes Read-only-Dateisystem zu realisieren.
| Was sind CVEs? |
|---|
|
Die Abkürzung steht für »Common Vulnerabilities and Exposures«. Mit »Vulnerabilities« sind ganz allgemein bekannte Sicherheitslücken und Schwachstellen in Computersystemen gemeint. »Exposures« bedeutet in diesem Kontext in etwa »Enthüllung« bzw. »Aufdeckung«. Hinter der CVE-Idee steht ein umfangreiches Programm, das Ende 1999 von US-Sicherheitsorganisationen geschaffen wurde, um IT-Sicherheitslücken zu erfassen und in einem Standarddatenformat zu veröffentlichen. Dadurch wurde ein Referenzsystem zur kontinuierlichen Verbesserung der Cybersicherheit erschaffen. Inzwischen beteiligen sich im Rahmen einer hierarchischen Organisationsstruktur zahlreiche internationale Partner am CVE-Programm. Als Root-Organisation dient die MITRE Corporation, ein Dienstleister der US-Regierung. Die Erfassung von Sicherheitslücken und Schwach-stellen erfolgt weltweit durch sogenannte CNAs (CVE Numbering Authorities). Dafür existiert ein CVE-Partnerprogramm. Es beinhaltet u. a. einen speziellen Boarding-Prozess, um neue Mitglieder einzubinden. Ein Beispiel für eine CVE wäre das NFC-basierte Kreditkartenterminal eines elektronischen Kassensystems A des Herstellers B, das einem Angreifer das Auslesen der Kundenkreditkarten- und Pin-Eingabedaten eines Bezahlvorgangs ermöglicht. Nachdem diese Sicherheitslücke entdeckt, innerhalb der CVE-Organisationsstrukturen gemeldet und geprüft wurde, bekommt sie eine Registriernummer im Format »CVE-yyyy-nnnn«. In dieser CVE-ID ist »yyyy« die Jahreszahl der Veröffentlichung und »nnnn« die fortlaufende Nummerierung aller Veröffentlichungen in dem betreffenden Jahr. Zwischen dem Entdecken einer Sicherheitslücke und der CVE-Veröffentlichung liegen manchmal allerdings größere Zeitspannen. Zu jeder neuen Sicherheitslücke wird eine Kurzbeschreibung erstellt und durch Zusatzinformationen ergänzt. Der finale CVE-Datensatz (Record) wird von einem CNA gemäß den organisatorischen Vorgaben zusammengestellt und mit Produkt- und Herstellernamen in der frei zugänglichen CVE-Datenbank gespeichert. Danach ist eine Sicherheitslücke über die CVE-ID eindeutig referenzierbar. Der gesamte CVE-Datenbestand ist im Internet über verschiedene Webseiten abfrag- und durchsuchbar (also z. B. die Kombination »Hersteller = GNU« und »Produkt = Glibc«). Als Suchbegriffe lassen sich beispielwiese Hersteller- und Produktnamen nutzen. Zur Integration in spezielle Werkzeuge sind die CVEs auch als JSON-Objekte unter GitHub verfügbar. |
Zukunftssicherheit durch Cybersecurity-Maintenance
Die bisher praktizierte Vorgehensweise war:
➔ Fertigen der Messtechnikbaugruppe ohne irgendwelche Veränderungen an der Hardware und der Linux-Laufzeitumgebung, um unerwünschte Nebeneffekte durch Inkompatibilitäten auszuschließen.
➔ Bei Bedarf funktionales Software-Update für die Messtechnikfunktionen erstellen.
Diese Vorgehensweise wird zukünftig nicht mehr funktionieren. Neben der funktionalen Softwarewartung wird eine Cybersecurity-Maintenance benötigt. Dazu gehören auf jeden Fall regelmäßige Prüfungen der gesamten Baugruppensoftware in Bezug auf neu entdeckte Schwachstellen, geeignete Korrekturmaßnahmen sowie Software-Updates für alle Baugruppen. Dafür fehlt dem ADNP/1520 in erster Linie eine detaillierte Übersicht aller verwendeten Softwarekomponenten – also eine Softwarestückliste. Insofern plante das Entwicklerteam als eine Teilaufgabe der ADNP/2586-Neuentwicklung das Erstellen einer umfassenden Komponenteninventarliste zu allen Softwarebausteinen.
Dazu gehören nicht nur der Boot Loader, Linux Kernel plus Root-Dateisystem, alle Bibliotheken, Laufzeitumgebungen und individuellen Firmware-Bausteine sowie Konfigurations- und sonstige Dateien, sondern auch die verwendeten Werkzeuge zum Erzeugen der ausführbaren Binärdateien (z. B. GNU C C/C++ Tool Chain als Docker-Container). Eine solche Softwarestückliste muss Hersteller und Anwender über den gesamten Lebenszyklus einer Embedded-Linux-Baugruppe in die Lage versetzen, im Rahmen automatisierter Überwachungsprozesse die jeweils bekannten Sicherheitslücken und Schwachstellen (Known Vulnerabilities) abzufragen, z. B. durch einen Abgleich mit dem aktuellen CVE-Bestand.
- Verfügbarkeits- Retrofit mit Security-Perspektive
- Schwachstellen mittels Softwarestückliste im Blick behalten
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
