Statische Codeanalyse verbessert die Software-Sicherheit

Moderne statische Quellcodeanalyse kann sehr effektiv sicherstellen, dass Code konform zu einem Programmierstandard ist. Zusätzlich findet sie viele ernste Fehler wie Buffer-Overruns, Null-Pointer-Dereferenzierungen, Race-Conditions und Ressourcen-Lecks. Diese Bugs treten auf, wenn Entwickler gegen fundamentale Regeln der Sprache verstoßen oder APIs falsch verwenden. Statische Analyse findet auch Widersprüche im Code, die andeuten, dass der Programmierer wichtige Teile des Codes nicht verstanden hat.

Herausforderung Third-Party-Code

Fast 30 % des Codes in Embedded-Anwendungen wie Medizingeräten besteht aus kommerzieller Fremdsoftware im Binärformat. Da der Entwickler keinen Zugriff auf den Quellcode hat, entzieht sich dieser Teil der statischen Analyse. Besonders gefährdet sind Systeme, die sich aus Code von mehreren Anbietern zusammensetzen. Sicherheitslücken an den Schnittstellen zwischen Modulen haben ihren Ursprung oft in Verständigungsproblemen, zum Beispiel wenn zwei Entwickler eine Aussage in der Spezifikation unterschiedlich interpretieren. Sind Teile des Quellcodes nicht verfügbar, eignen sich Mischformen der statischen Analysetools, die Quellcodeanalyse mit Binärcodeanalyse kombinieren.

Zu Best Practices bei sicherheitskritischer Software gehört, Daten und Eingabewerte aus potenziell gefährlichen Kanälen immer als risikoreich einzustufen, bis deren Gültigkeit geprüft wurde. Im Sprachgebrauch des sicheren Programmierens heißen ungeprüfte Eingabewerte „tainted“. Ein Check, ob ein Programm solche Daten korrekt verarbeitet, kann sehr schwierig sein. Man muss den Verlauf der Daten durch die Code-Struktur verfolgen. Sogar bei relativ kleinen Programmen ist das sehr mühsam, und für die meisten Echtzeitanwendungen manuell nicht mehr durchführbar.

Buffer-Overrun et al

Wenn Angreifer die Eingabewerte eines Geräts manipulieren können, denn besteht die Gefahr, dass sie per speziell konstruierter Daten eine Sicherheitsschwachstelle ausnutzen. Zu den typischen Fehlerarten aufgrund von Tainted-Daten zählen Buffer-Overruns, SQL-Injektion, Befehl-Injektion, Cross-Site Scripting, Zahlenüberläufe und Path-Traversal. Gerade der berüchtigte Buffer-Overrun verdient eine ausführlichere Beschreibung: Ihn gibt es in verschiedenen Ausprägungen. Im nachfolgenden Code liegt der angegriffene Buffer auf dem Stack:

void config(void)
{
   char buf[100];
   int count;
   …
   strcpy(buf, getenv(„CONFIG“));
   …
}

Die Eingabe kommt von außen über einen Aufruf der Funktion „getenv“, die den Wert der Umgebungsvariablen „CONFIG“ abruft. Der Programmierer erwartet, dass der Wert der Umgebungsvariablen in den Buffer passt, stellt das aber nirgendwo sicher. Erhält der Angreifer die Kontrolle über den Wert dieser Umgebungsvariablen, dann kann er auch mehr als 100 Zeichen angeben und damit einen Buffer-Overrun auslösen. Bei „buf“ handelt es sich um eine automatische Variable, die der Compiler auf dem Stack hinterlegt. Darum wird jedes Zeichen nach den ersten 100 auf die Teile des Programm-Stacks außerhalb der Grenze von „buf“ geschrieben. Dort liegt, je nach dem wie der Compiler den Stack organisiert, zum Beispiel die Variable namens „count“. Der Angreifer kann also indirekt den Wert dieser Variablen verändern – je nach Bedeutung dieser Variable kann das schon enormen Schaden anrichten.

Beispiel einer Buffer-Overrun-Schwachstelle. Das Tool markiert das Resultat seiner Taint-Analyse durch Unterstreichungen.Gramma-Tech

Zusätzlich liegt auf dem Stack aber auch die Rücksprungadresse der aktuellen Funktion. Wenn der Angreifer diese überschreibt, dann kann er den Ablauf der Software verändern und zum Beispiel direkt an die Adresse springen, an der „buf“ liegt. Wenn dann der Inhalt von „buf“ vom Angreifer so gewählt ist, dass es sich um ausführbaren Binärcode handelt, hat er die volle Kontrolle über den aktuellen Prozess erlangt.

Taint-Analyse

Die gefährlichsten Input-Kanäle sind die, die ein Angreifer kontrolliert. In einer Umgebung, in der Angreifer keinerlei Kontrolle über die Umgebungsvariablen haben, ist diese Schwachstelle vielleicht nicht ausnutzbar. Dennoch ist der Code risikoreich und bleibt ein Haftungsproblem. Außerdem könnte ein Entwickler versucht sein, diesen Code in einem anderen Programm wiederzuverwenden, wo er nicht mehr sicher wäre. In unserem Beispiel kommt der Input aus der Umgebung, aber der Code wäre genauso gefährlich, käme der String aus einer anderen Input-Quelle wie dem Dateisystem oder einem Netzwerkkanal. Die manuelle Suche nach Programmierfehlern, die für Tainted-Werte anfällig sind, gestaltet sich extrem zeitaufwändig – das macht die Automatisierung zum besten Ansatz.

Die Taint-Analyse zeigt Entwicklern, wie der Code riskante Daten von einem Programmteil zum nächsten weiterreicht. Ein modernes statisches Analysetool zur Taint-Analyse erklärt die Abläufe, damit der Entwickler mögliche Angriffsflächen in seinem Code erkennen und verstehen sowie Fehler aufspüren und korrigieren kann. Manche Tools führen die Taint-Analyse dynamisch aus. Ein statischer Ablauf hat aber wichtige Vorteile – nicht zuletzt um sicherzugehen, dass alle Ausführungspfade sicher sind, und nicht nur diejenigen, für die Testfälle vorliegen.

Gute Routine

Entwickler von Medizingeräte-Software verantworten Code, von dem die Gesundheit und Sicherheit der Patienten abhängen. Programmierstandards für sicherheitskritische Software haben sich in anderen Branchen bewährt und sollten auch für Medizingeräte zwingend sein. Einen guten Einstieg bieten die NASA/JPL „Power of Ten“, die bewährte Verfahren aus mehreren Standards bündeln. Moderne statische Analysetools finden auch Fehler, die nur unter ungewöhnlichen Umständen auftreten, und zwar sehr früh in der Entwicklung. Das spart Zeit und Kosten und erhöht die Qualität.