Erkennung von Security-Schwachstellen Grenzen und Anwendbarkeit der Common Weakness Enumeration (CWE)

Anbieter zum Thema

Axivion GmbH

MicroConsult Microelectronics Consulting & Training GmbH

Parasoft® Deutschland GmbH

Mit steigender Vernetzung eingebetteter Software in Systemen mit hohen Safety-Ansprüchen wachsen auch die Anforderungen hinsichtlich der Security. Die Common Weakness Enumeration (CWE) kann helfen, Schwachstellen und deren Behandlung realistisch einzuschätzen – wenn Sie denn regelmäßig genutzt wird.

Durch die zunehmende Vernetzung eingebetteter Software, durch Themen wie autonomes Fahren, Telemetrieanforderungen sowie Fernwartung rückt insbesondere die Sicherheit gegenüber Angriffen (Security) in den Vordergrund. Während die Überprüfung der funktionalen Sicherheit (Safety) gut etabliert und in die Entwicklungsprozesse integriert ist, ist die Überprüfung der Security noch weniger verbreitet und weniger automatisiert.

Im Folgenden werden wir die Common Weakness Enumeration (CWE) vorstellen und ausgewählte Schwachstellen in Bezug auf ihre (automatische) Prüfbarkeit einordnen. So zeigen wir, wie man zu einem ersten Prüfplan gelangen kann. Anschließend werden wir diskutieren, wieso für die Überprüfung einiger Schwachstellen zunächst eine Bedrohungsanalyse notwendig ist. Insgesamt werden so die Grenzen automatischer Analysewerkzeuge aufgedeckt und wie diese zusammen mit anderen Techniken dennoch eine effiziente Überprüfung der Sicherheit eingebetteter Software ermöglichen und unterstützen können.

Aufgrund immer neuer Angriffsszenarien muss diese Liste regelmäßig konsultiert werden. Hier präsentieren wir mögliche Wege von der Schwachstelle zur Prüfung. Nur ein ganzheitlicher Ansatz verschiedener Methoden wird im Zusammenspiel die Sicherheit so gut wie möglich gewährleisten können.

Die Common Weakness Enumeration

Die CWE ist eine Liste allgemeiner Sicherheitsschwachstellen von Software- und Hardware (1). Die Liste ist offen für Beiträge und wird durch die Community gepflegt. Zum Zeitpunkt der Erstellung dieses Beitrags (Oktober 2021) enthielt die CWE 922 mögliche Schwachstellen. Diese werden auf verschiedene Arten miteinander in Beziehung gesetzt (etwa Schwachstelle X kann als Folge von Schwachstelle Y auftreten). Kategorisierungen nach Programmiersprachen, Zeitpunkt des Auftretens im Entwicklungsprozess oder möglichen Techniken zur Erkennung helfen, die Schwachstellen einzuordnen und Zusammenhänge zu verstehen.

Die bekannten Standards aus dem Bereich Safety, z.B. MISRA (2), greifen bereits einzelne Aspekte der Security auf. Daneben gibt es einige speziell auf Security fokussierte Regelwerke, wie etwa Cert (C / C++) (3) oder die C Secure Coding Guidelines (ISO 17961) (4). Allen ist gemein, dass sie konkrete Vorgaben und Regeln definieren, wie etwas umgesetzt werden darf oder welche Konstrukte im Code vermieden werden müssen.

Im Gegensatz dazu enthält die CWE keine konkreten Richtlinien, sondern eine Sammlung möglicher Sicherheitsprobleme. Dadurch ist eine automatische herausfordernd: Zu den abstrakten Schwachstellen müssen mögliche Ausprägungen im Code herausgearbeitet werden. Diese sind meist projektspezifisch. Erst danach kann eine Überprüfung stattfinden.

Dabei sind von den 922 derzeit in der CWE gelisteten Schwachstellentypen nicht alle relevant für eingebettete Software, sondern richten sich etwa an Web- oder Desktopapplikationen. Während die CWE eine Kategorisierung nach verwendeter Programmiersprache (etwa C oder C++) anbietet, ist diese mit Vorsicht zu genießen. So können je nach Projekt auch Schwachstellen relevant sein, die sprachunabhängig sind aber auf bestimmte Technologien (wie Datenbanken, Verschlüsselung, …) abzielen.

Während diese Flexibilität zu einer gründlichen Abdeckung führt, behindert Sie gleichzeitig die effiziente automatisierte Prüfung durch automatisierte Analysewerkzeuge.

Beispiele aus der CWE – Allgemeine Schwachstellen in C und C++

Einige der gelisteten Schwachstellen beschreiben klassische Probleme in C und C++. Diese haben in der Regel auch einen Einfluss auf die Safety des Systems und werden daher bereits durch Regelwerkewie MISRA abgedeckt. Vielfach stehen etablierte Analysewerkzeuge zur Erkennung bereit. Im Rahmen der Top 25 kritischsten Schwachstellen nennt die CWE z.B.:

• Use after Free, d.h. den Zugriff auf einen bereits freigegebenen Speicherbereich,

• NULL Pointer Dereference,

• Integer Overflow, und

• Out-of-Bounds Access, d.h. Zugriffe außerhalb der Grenzen eines Puffers.

Beispiele aus der CWE – Projektspezifische Ausprägungen

CWE 22, „Improper Limitation of a Pathname to a Restricted Directory“, tritt auf, wenn eine Software eine externe Eingabe verwendet um einen Pfad zu einer Datei zu erzeugen. Ziel könnte beispielsweise sein, den Benutzer den Namen eines Logfiles unterhalb des Ordners /opt/my_app/logs auswählen zu lassen. Ein Angreifer kann nun durch Angabe eines relativen Pfades den Zielordner verlassen. So führt die Angabe des Pfads ../../../etc/passwd, insgesamt zu /opt/my_app/logs/../../../etc/passwd. Dieser Pfad wird letztlich zu /etc/passwd aufgelöst und referenziert die Kennwortdatei von Unixsystemem.

Schwachstellen wie CWE 22 können häufig ausgeschlossen werden, in dem die Verwendung kompletter Features ausgeschlossen wird. Dateizugriffe komplett zu verbieten ist jedoch nicht in allen Fällen möglich. Es bieten sich weitere Ansätze mit unterschiedlichen Einschränkungen an:

• Es wird nur der Zugriff auf vordefinierte Pfade erlaubt. Diese liegen dann als Konstanten vor und können durch ein Review geprüft werden.

• Es sollen weiterhin benutzerdefinierte Pfade möglich sein. Dann muss sichergestellt werden, dass die Eingaben auf Steuerzeichen überprüft und diese neutralisiert werden. Hier bieten sich im Wesentlichen zwei Ansätze an:

• - Falls die betreffenden Stellen im Code überschaubar sind kann auch hier auf Reviews gesetzt werden.

• - Alternativ kann eine statische Codeanalyse verwendet werden, um automatisiert Stellen zu markieren, in denen externe Daten ohne Prüfung verwendet werden. Eine solche Analyse kann dabei nur prüfen, ob eine vorher definierte Bereinigung der Eingaben verwendet wird (z.B. durch ein gegebenes Makro). Ob die Bereinigung an sich korrekt ist, ist kaum automatisch festzustellen.

• Zur Laufzeit des Programms die Eingaben auf Gefahrlosigkeit zu prüfen, wäre grundsätzlich durch das Injizieren von Prüfcode möglich. Dieser hätte jedoch dieselben Einschränkungen bezüglich seiner eigenen Korrektheit.

• Ein kombinierter semi-automatischer Ansatz kann verwendet werden, um Reviews zu unterstützen. So könnte ein statisches Analysewerkzeug alle „verdächtigen“ Stellen markieren und offensichtliche Fälle prüfen. Die Prüfung komplexer Fälle erfolgt dann manuell. Das Ergebnis wird dem Analysewerkzeug mit Hilfe speziell formatierter Kommentare mitgeteilt.

Nachdem eine projektspezifische Ausprägung der Schwachstellen definiert ist, kann diese häufig automatisiert geprüft werden.

Der sehr allgemeine Charakter der CWE zeigt sich auch bei CWE 193. Diese beschreibt den Sicherheitseinfluss eines Off-by-one Fehlers, der sich sicher nicht sinnvoll in einer generellen Form automatisiert erkennen lässt. Dennoch kann CWE 193 als Erinnerung verstanden werden, grade die Randbereiche von Eingaben durch gründliche Tests abzudecken und diese in Code Reviews entsprechend einzufordern.

Beispiele aus der CWE – Weitere Analysen notwendig

Einige der in der CWE gelisteten Probleme sind sehr allgemein und müssen für ein konkretes Projekt aufgearbeitet werden bevor eine Entscheidung für ein Prüfverfahren getroffen werden kann. Ein Beispiel ist CWE 200 „Exposure of Sensitive Information to an Unauthorized Actor”. Für eine Prüfung eines konkreten Softwareprojekts auf CWE 200 sind daher zunächst Fragen zu drei Themenkomplexen zu beantworten:

• Welche sensiblen Informationen werden durch die Software verarbeitet? Wo und wie werden diese gespeichert?

• Welche Aktoren interagieren mit dem System und wie? Wie werden Aktoren identifiziert und wie können Aktoren unterschieden werden?

• Im Kombination ergeben die beiden vorherigen Punkte die Definition eines unautorisierten Aktors in Bezug auf eine bestimmte sensible Information.

Das Ergebnis dieser Fragen kann z.B. wie in den folgenden Tabellen dokumentiert werden.

Aus der Kombination dieser Tabellen lassen sich nun die eigentlichen Prüfungen ableiten. Im Beispiel muss ein Abfluss der Daten aus den Variablen im Modul „User“ in die Logfiles verhindert werden. Wie für CWE 22 kommen dafür wieder mehrere Ansätze in Frage. Aufgrund der möglichen Komplexität den Datenfluss durch ein umfangreiches Softwaresystem nachzuvollziehen bieten sich hier insbesondere wieder automatisierte Softwareanalysen an.

Bedrohungsanalysen und Prüfpläne

Wie in den Beispielen gezeigt kann nicht jede in der CWE gelisteten Schwachstellen durch eine allgemeine Prüfung abgedeckt werden. Entsprechend können automatische Analysewerkzeuge auch immer nur einen Teil der CWE direkt im Funktionsumfang haben. Abhängig von der gewünschten Ausprägung bieten gängige Systeme jedoch die Möglichkeit bestehende Prüfungen anzupassen oder maßgeschneiderte Regeln zu implementieren. Auch eine Integration mit Reviewprozessen ist in der Regel möglich.

Um CWE 200 und weitere abstrakte Sicherheitslücken im konkreten Projekt zu identifizieren ist für diese Schwachstellen eine Bedrohungsanalyse notwendig.

Im Rahmen dieser Analyse muss zunächst geklärt werden, ob eine Schwachstelle für das Projekt relevant ist oder ob sie aus offensichtlichen Gründen nicht geprüft werden muss. Beispielsweise muss in einem C++ Projekt eine auf Java basierende Sicherheitslücke nicht geprüft werden.

Eine Analyse potentieller Bedrohungen kann auf diversen Wegen erfolgen. Denkbare Vorgehen sind Threat Modeling (5) oder eine Integration in die im Safety Umfeld häufig verwendete FMEA (6) Analyse (7).

Fazit

Zusammenfassend bietet die CWE eine gute Grundlage für die Sicherheitsanalyse eingebetteter Software. Aufgrund ihrer Struktur ist sie umfassender als typische Regelwerke. Die höhere Anpassbarkeit und Gründlichkeit haben jedoch einen Preis. Während gängige Analysewerkzeuge andere Regelsätze auf Knopfdruck aktivieren und prüfen können sind für eine Prüfung der CWE mehr Vorarbeiten notwendig. Hier kann sich eine Kombination anbieten, in der ein Regelsatz geprüft und durch projektspezifische Schwachstellen aus der CWE ergänzt wird.

Literaturverzeichnis

1. MITRE. Common Weakness Enumeration. [Online] 2021.
2. Misra. Misra C:2012 - Guidelines for the use of the C Language in Critical Systems. 2013.
3. Seacord, Robert. The CERT ® C Coding Standard: 98 Rules for Developing Safe, Reliable, and Secure Systems. s.l. : Addison-Wesley Professional, 2014.
4. ISO. ISO/IEC TS 17961:2013/COR 1:2016 - C secure coding rules. 2016.
5. Shostack, Adam. Threat Modeling: Designing for Security. s.l. : Wiley, 2014.
6. IEC. IEC 60812: Analysis techniques for system reliability-Procedure for failure mode and effects analysis (FMEA).
7. C., Schmittner, et al. Security Application of Failure Mode and Effect Analysis (FMEA). Computer Safety, Reliability, and Security. SAFECOMP 2014. Springer LNCS 8666. 2014.

Dieser Beitrag stammt, mit freundlicher Genehmigung des Autors, aus dem Tagungsband des ESE Kongress 2021.

* Sebastian Krings ist Softwareengineer bei Axivion, wo er sich mit dem Einsatz und der Weiterentwicklung statischer Verfikationswerkzeuge beschäftigt. Zuvor war er Postdoc am Institut für Informationssicherheit der Hochschule Niederrhein. Er promovierte 2017 an der Heinrich-Heine-Universität in Düsseldorf am Lehrstuhl für Softwaretechnik und Programmiersprachen. Seine Forschung dort drehte sich um formale Methoden für die Verifikation von Software, insbesondere um Model Checking Verfahren zur Überprüfung von Systemmodellen.

(ID:48110247)