Startseite > Embedded > Software > Schutz vor faulen Daten

Taint-Analyse

Schutz vor faulen Daten

18. Dezember 2014, 14:57 Uhr | Dr. Paul Anderson

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Gefahrenstellen identifizieren

In der Terminologie der Taint-Analyse bezeichnet eine Taint Source (Quelle) einen Ort im Programm, wo Daten aus einer gefährlichen Quelle eingelesen werden. Im oben angeführten Code-Beispiel ist es der Aufruf an getenv(). Eine Taint Sink (Senke) ist ein Ort, wohin potenziell fehlerhafte Daten keinesfalls fließen sollten, es sei denn, sie wurden auf Gültigkeit geprüft, wie im Beispiel der Aufruf von strcpy(). Wurde ein Wert überprüft, spricht man davon, dass er vom Taint gereinigt wurde.

Die meisten Programme beziehen ihren Input aus vielen Quellen, und die Umgebung, in der das Programm ausgeführt wird, bestimmt die Gefahrenstufe jeder Quelle. Zu Taint-Quellen gehören

Umgebungsvariable,
Dateiinhalte,
Datei-Metadaten, z.B. Berechtigungen oder Datenstempel einer Datei,
das Netzwerk,
Netzwerk-Dienste, z.B. die Inhalte einer DNS-Anfrage,
System Clock, die Registry (auf Windows-Systemen).

Jedes Programm kann andere Arten von potenziell gefährlichem Input haben. Beispielsweise sollte ein Programm, das Input aus einem Gerät mit Infrarotsensor erhält, diesen Kanal als gefährlich betrachten. Sicherheitsanalysten definieren die Schwachstellen für potenzielle Angreifer als „Angriffsfläche eines Programms“. Um das Risiko eines Programms zu bewerten, ist es hilfreich, zunächst ein Verständnis einer Angriffsoberfläche aufzubauen. Dies ist den Taint Sources des Programms sehr ähnlich. Das Auffinden von Programmierfehlern, die empfänglich für Tainted-Daten sind, kann sehr aufwendig sein. Deshalb ist ein automatisierter Suchvorgang der beste Ansatz.

Automatisierte Taint-Analyse

Die Taint-Analyse ist eine Form der statischen Analyse. Grob gesagt funktionieren moderne statische Analyse-Tools wie folgt: Zuerst müssen sie ein Modell des gesamten Programms erstellen; dazu zergliedern und analysieren sie jede Eingabedatei. Das Modell besteht aus Darstellungen wie „Abstract Syntax Trees“ für jede Kompilierungseinheit, Kontrollfluss-Diagrammen für jedes Unterprogramm, Symboltabellen und dem Call Graph. Prüfroutinen finden dann Fehler in Bezug auf verschiedene Anfragearten an diese Darstellungen. Oberflächliche Fehler werden durch Musterabgleich mit dem Abstract Syntax Tree oder den Symboltabellen aufgedeckt.

Die wirklich ernsten Fehler, die das Programm zum Ausfall bringen, wie Null-Pointer und Buffer Overruns, lassen sich nur über anspruchsvolle Abfragen finden. Man kann sich diese als abstrakte Simulationen vorstellen – der Analysator simuliert die Ausführung des Programms, aber anstelle konkreter Werte werden den abstrakten Programmstatus darstellende Gleichungen eingesetzt. Bei Unregelmäßigkeiten erfolgt eine Warnung.

Jobangebote+ passend zum Thema

MACNICA ATD EUROPE - Ihre berufliche Zukunft

MACNICA ATD Europe GmbH, Ingolstadt

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Bild 1 zeigt ein Beispiel einer Buffer-Overrun-Warnung von CodeSonar. Der Weg durch den Code zur Ansteuerung des Fehlers ist dargestellt, interessante Punkte entlang des Wegs sind hervorgehoben. Eine Erklärung, was schieflaufen kann, erfolgt am Punkt des Überlaufs. Es kann schwierig sein, den Fluss fehlerhafter Daten durch ein Programm zu verfolgen. Denn dazu muss der Wert zurückverfolgt werden, wie er von einer zur nächsten Variablen kopiert wurde, möglicherweise über Prozedurgrenzen und mehrere Ebenen indirekter Aufrufe hinweg.Ein Beispiel: Ein Programm liest eine Zeichenkette aus einem risikoreichen Netzwerkport aus. Weil Strings in C normalerweise durch Pointer verwaltet werden, muss die Analyse sowohl die Inhalte des String als auch den Wert aller Pointer, die auf den String verweisen, nachverfolgen. Die Zeichen bzw. der Inhalt des String selbst gelten als „tainted“ (fehlerhaft), während man vom Pointer sagt, er zeigt auf die „Taintedness“. Kopiert man den Inhalt des String, z.B. durch strcpy(), führt das zur Übertragung der fehlerhaften Daten auf den neuen String. Werden die Pointer kopiert, dann muss die Übertragung der Point-to-Taint-Eigenschaft auf den neuen Pointer erfolgen.

Natürlich kann es Pointer auf diese Pointer geben, und sogar Pointer auf diese, und die Analyse muss auch diese prüfen. Letztendlich läuft das Problem auf eine Art Alias-Analyse hinaus, also eine Analyse, die sagen kann, welche Variablen dieselben Speicherorte erreichen. Eine Erklärung der ‚Alias-Analyse‘ würde in diesem Artikel zu weit reichen; eine gute Einführung in das Thema ist hier zu finden: www.wikipedia.org/wiki/Alias_analysis.