Analysewerkzeuge

Moderne statische Codeanalyse für das Internet der Dinge

Seite: 2/3

Firmen zum Thema

Viele Schwachstellen resultieren aus der irrigen Annahme der Programmierer, dass Datenquellen stets vertrauenswürdig sind. Die ausbleibende Prüfung von Eingangswerten auf Gültigkeit ist auch dann relevant, wenn das Thema Security Top-Priorität hat. Jede Software, die Werte aus einem Sensor einliest, sollte alle Werte als potenziell gefährlich einstufen.

Schließlich könnten diese wegen eines Hardwarefehlers außerhalb des zulässigen Bereichs liegen und einen Softwareabsturz verursachen, wenn sie vom Programm nicht geprüft werden. Die gleichen Techniken können auch zur Abwehr gegen böswillig verfälschte Daten benutzt werden und eignen sich ebenfalls, um Defekte zu finden und die riskantesten Codeabschnitte zu verstehen.

Nicht alle Datenquellen sind vertrauenswürdig

Programmierer können sich vor derartigen Defekten schützen, indem sie Eingangswerte aus potenziell riskanten Kanälen so lange als gefährlich einstufen, bis ihre Gültigkeit geprüft ist. Im Sprachgebrauch der sicheren Programmierung werden ungeprüfte Eingangswerte als ‚tainted‘ (verunreinigt) bezeichnet.

Möglicherweise ist es schwierig zu verstehen, ob ein Programm richtig mit tainted-Daten umgeht, denn hierzu müsste der Weg der Daten durch die Codestruktur verfolgt werden. Dies aber kann selbst bei kleinen Programmen recht mühsam sein und ist bei den meisten realen Applikationen auf manuellem Weg unmöglich.

Moderne statische Analysetools erstellen zunächst ein Modell des gesamten Programms, das aus abstrakten Syntaxbäumen jeder Kompilierungs-Einheit, Kontrollfluss-Graphen für jedes Unterprogramm, Symboltabellen und dem Aufrufdiagramm besteht.

Hochentwickelte Abhilfe: Das Programmmodell analysieren

Diese Darstellungen werden anschließend auf Fehler durchsucht. Bei der Auffindung etwaiger Anomalien erfolgen Warnungen, wobei sich die Defekte in drei Kategorien gliedern lassen:

  • Fehler, die grundlegende Konzeptregeln verletzen und ein undefiniertes Programmverhalten zur Folge haben (Nullzeiger-Dereferenzierungen, Pufferüberläufe, Nebenläufigkeitsfehler oder nicht initialisierter Speicher).
  • Fehler durch Verletzung der Regeln für die Benutzung eines Standard-API. Zum Beispiel gibt die C-Bibliothek nicht vor, was passiert, wenn ein Datei-Deskriptor zweimal geschlossen wird. Dies dürfte kaum absichtlich geschehen und deutet deshalb wahrscheinlich auf einen Fehler hin.
  • Unstimmigkeiten oder Widersprüche im Code, die vielleicht keinen Programmabsturz verursachen, aber ein Indiz dafür sein können, dass der Programmierer eine wesentliche Eigenschaft des Codes falsch verstanden hat. Zum Beispiel wird eine Bedingung, die stets wahr oder stets falsch ist, kaum absichtlich entstanden sein, da sie zu totem Code führt.

Statische Analysetools decken Defekte, die nur unter besonderen Umständen auftreten, sehr gut auf, und auch in einer sehr frühen Entwicklungsphase, noch bevor der Code wirklich zum Testen bereit ist. Sie sollten traditionelle Prüftechniken nicht ersetzen, aber ergänzen.

Quellcode- oder Binärcode-Analyse?

Traditionell wurden statische Analysetools nur für Quellcode eingesetzt, dabei sind sie auch aus folgenden Gründen bei Binärcode nützlich:

  • Der Quellcode steht nicht zur Verfügung (beispielsweise bei zugekauftem oder lizenziertem Code).
  • Compiler können den Quellcode unterschiedlich interpretieren. Durch Analysieren des Binärcodes können diese Abweichungen die Genauigkeit der Untersuchung nicht mehr beeinträchtigen.
  • Der Compiler selbst könnte wegen eines Defekts Code generieren, der fehlerhaft ist oder eine Sicherheitslücke entstehen lässt.

Inzwischen analysieren einige hochentwickelte statische Analysetools sowohl Quell- als auch Binärcode, etwa CodeSonar, das sich für die Analyse beliebiger Kombinationen aus Quellcode und x86- oder x64-Binaries und ARM-Binaries eignet.

Artikelfiles und Artikellinks

(ID:44230359)