25 Schwachstellen im RTOS Zephyr, darunter solche, die über ICMP-Pakete ausgenutzt werden.

Forscher der NCC Group haben Ergebnisse des Audits des freien Projekts Zephyr, entwickelnd ein Echtzeitsystem (RTOS), das auf die Ausstattung von Geräten abzielt, die dem Konzept des "Internets der Dinge" (IoT, Internet of Things) entsprechen. Im Verlauf des Audits wurden festgestellt 25 Schwachstellen in Zephyr und 1 Schwachstelle in MCUboot. Die Entwicklung von Zephyr erfolgt mit Beteiligung von Unternehmen wie Intel.

Insgesamt wurden 6 Schwachstellen im Netzwerk-Stack, 4 im Kernel, 2 in der Shell, 5 in den Systemaufrufbehandlern, 5 im USB-Subsystem und 3 im Firmware-Update-Mechanismus festgestellt. Zwei Probleme wurden als kritisch eingestuft, zwei als hoch, 9 als mäßig, 9 als niedrig und 4 zur Berücksichtigung. Kritische Probleme betreffen den IPv4-Stack und den MQTT-Parser, gefährliche die Treiber für USB-Massenspeicher und USB DFU. Zum Zeitpunkt der Offenlegung wurden nur für 15 der gefährlichsten Schwachstellen Patches vorbereitet, während Probleme, die zu einem Denial of Service führen oder mit Mängeln in den zusätzlichen Schutzmechanismen des Kernels verbunden sind, weiterhin ungelöst bleiben.

Im IPv4-Stack der Plattform wurde eine aus der Ferne ausnutzbare Schwachstelle festgestellt, die zu Speicherbeschädigungen bei der Verarbeitung bestimmter modifizierter ICMP-Pakete führt. Ein weiteres ernsthaftes Problem wurde im MQTT-Protokollparser gefunden, das durch unzureichende Überprüfung der Längen der Felder im Header verursacht wird und zu einer Ausführung von Code aus der Ferne führen kann. Weniger gefährliche Probleme, die zu einem Denial of Service führen, wurden im IPv6-Stack und in der Implementierung des CoAP-Protokolls gefunden.

Die übrigen Probleme können lokal ausgenutzt werden, um einen Denial of Service auszulösen oder Code auf Kernel-Ebene auszuführen. Der größte Teil dieser Schwachstellen hängt mit fehlenden Überprüfungen der Argumente von Systemaufrufen zusammen und kann zu Lese- und Schreibzugriffen auf beliebige Bereiche des Kernelspeichers führen. Die Probleme betreffen auch den Code zur Verarbeitung von Systemaufrufen selbst — der Zugriff auf eine negative Nummer des Systemaufrufs führt zu einem ganzzahligen Überlauf. Im Kernel wurden zudem Probleme bei der Implementierung des ASLR-Schutzes (Address Space Layout Randomization) und des Mechanismus zur Einrichtung von Canary-Werten im Stack festgestellt, die diese Mechanismen ineffektiv machen.

Viele Probleme betreffen das USB-Stack und einzelne Treiber. Zum Beispiel erlaubt ein Problem mit der USB-Massenspeicherfunktion das Auslösen eines Pufferüberlaufs und die Ausführung von Code auf Kernel-Ebene, wenn ein Gerät mit einem von einem Angreifer kontrollierten USB-Host verbunden wird. Eine Schwachstelle im USB DFU, dem Treiber für das Laden neuer Firmware über USB, ermöglicht das Laden eines modifizierten Firmware-Images in den internen Flash-Mikrocontroller ohne Verschlüsselung und umgeht den sicheren Boot-Modus mit Überprüfung der Komponenten durch digitale Signaturen. Zusätzlich wurde der Code des offenen Bootloaders untersucht MCUboot, in dem eine nicht schwerwiegende Schwachstelle gefunden wurde,
die zu einem Pufferüberlauf führen kann, wenn das SMP-Protokoll (Simple Management Protocol) über UART verwendet wird.

Erinnern wir uns daran, dass in Zephyr für alle Prozesse nur ein globaler, gemeinsam genutzter virtueller Adressraum (SASOS, Single Address Space Operating System) bereitgestellt wird. Anwendungs-spezifischer Code wird mit einem für die jeweilige Anwendung angepassten Kernel kombiniert und bildet eine monolithische ausführbare Datei zum Laden und Ausführen auf spezifischer Hardware. Alle Systemressourcen werden zur Kompilierungszeit festgelegt, was die Codegröße verringert und die Leistung erhöht. Im System-Abbild können nur die Kernel-Funktionen enthalten sein, die zur Ausführung der Anwendung benötigt werden.

Bemerkenswert ist, dass zu den wichtigsten Vorteilen von Zephyr wird erwähnt die Entwicklung unter Berücksichtigung der Sicherheit gehört. Es wird behauptet, dass alle Entwicklungsphasen obligatorische Sicherheits-Validierungsprozesse durchlaufen: Fuzzing-Tests, statische Analyse, Penetrationstests, Code-Reviews, Backdoor-Analysen und Bedrohungsmodellierung.

Quelle: opennet.ru

60GB SSD 8Gb DDR4