Elektroniknet Logo

Software-Test

Mit statischer Code-Analyse zum Erfolg


Fortsetzung des Artikels von Teil 1

Schwachstellen erkennen

Um solche Fehler bereits deutlich früher im SDLC aufzudecken, bietet sich die statische Codeanalyse an. Vorzugsweise kommen hierfür Werkzeuge zum Einsatz. Sie führen den Code nicht aus, sondern überführen ihn zunächst in ein Modell (Bild 1). Anhand des Modells überprüft das Analyse-Tool alle Steuerungs- und Datenströme und prüft deren Korrektheit anhand so genannter Checker. Beim Erstellen des Modells aus dem Code arbeitet das Werkzeug ähnlich einem Compiler, der Code wird für das Untersuchen in eine Intermediate Representation (IR) überführt.

Da die statische Analyse alle Zustände berücksichtigt die das Programm theoretisch einnehmen kann, lassen sich potenzielle Fehler mit deutlich höherer Trefferquote aufspüren.

Relevante Anbieter

Bei der statischen Code-Analyse wird der Code in eine Intermediate Representation überführt, anhand derer alle Steuerungs- und Datenströme überprüft werden
Bild 1. Bei der statischen Codeanalyse wird der Code in eine Intermediate Representation überführt, anhand derer alle Steuerungs- und Datenströme überprüft werden.
© Grammatech

Zudem geben die Analyse-Tools den Entwicklern viele hilfreiche Informationen, die beim Beseitigen der Fehler helfen. Standards zur Softwareentwicklung von sicherheitskritischen Anwendungen, etwa ISO 26262 in der Automobilbranche oder DO-178 B/C in der Luftfahrt, schreiben deswegen die statische Analyse entweder explizit vor oder empfehlen sie dringend.

Zu den Fehlern, die im Fokus der Analyse stehen, gehören unter anderem die klassischen Einfallstore für Malware:

  • Buffer Overrun/Underrun
  • Command Injection
  • Integer Overflow of Allocation Size
  • SQL Injection
  • Non-constant Format String

Ein entscheidender Vorteil des Ansatzes ist, dass die statische Codeanalyse keinen lauffähigen Code voraussetzt. Hiermit ist sie in allen Phasen des SDLC einsetzbar.

Mit der Prüftiefe ist eben- so der Zeit- und Ressourcenaufwand skalierbar: Je nach den gewählten Checkern benötigt die Analyse mehr oder weniger Rechenzeit. Zudem sind Checker bei professionellen Tools individuell definierbar, um den spezifischen Anforderungen des Unternehmens gerecht zu werden. Im Rahmen agiler Entwicklungsansätze wie Continuous Integration/Continuous Deployment (CI/CD), die ebenfalls in der Embedded-Entwicklung immer weiter verbreitet sind, kann das etwa bedeuten: Am Arbeitsplatz der Entwickler findet eine erste Analyse statt, bevor die Integration in die Mainline erfolgt. Um Zeit zu sparen, kann sich die Analyse hier auf sehr typische Fehler oder das Einhalten von Programmierrichtlinien beschränken.

 Das Analyse-Tool CodeSonar hat einen potenziellen Buffer Overrun im Code erkannt und liefert dem Entwickler genaue Informationen und Hilfen zur Beseitigung
Bild 2. Das Analyse-Tool CodeSonar hat einen potenziellen Buffer Overrun im Code erkannt und liefert dem Entwickler genaue Informationen und Hilfen zur Beseitigung.
© Grammatech

Eine weitere Analyseinstanz kann am Build-System arbeiten. Ebenso bietet es sich an, während der normalen Arbeitszeiten ausschließlich einfache Analysen durchzuführen, um die Produktivität der Teams nicht negativ zu beeinflussen. Für tiefe Untersuchungen, die etwas Rechenzeit erfordern, bieten sich zum Beispiel nächtliche Zeitfenster an. Da professionelle Analyse-Tools wie das von Verifysoft Technology vertriebene »CodeSonar« von GrammaTech ein hohes Maß an Automatisierung ermöglichen, ist eine nicht-überwachte Analyse problemlos möglich (Bild 2).

Fehler frühzeitig aufdecken

Die statische Code-Analyse als fester Bestandteil des SDLC kann den Testvorgang um ein frühzeitiges Überprüfen des Codes ergänzen. Vor allem klassische Sicherheitslücken – die sich bei komplexen Projekten kaum vermeiden lassen – können Entwickler somit früh erkennen und beheben. Gerade bei Embedded-Systemen ist eine hohe Codequalität unverzichtbar – nicht nur wegen der Schwierigkeiten bei Updates und Patches. In immer mehr Bereichen müssen die Embedded-Systeme nach strengen Standards zertifiziert sein. Hierfür setzen viele Normen den Einsatz der statischen Analyse implizit oder explizit voraus. Ebenso in Bereichen, in denen die Normierung noch eine untergeordnete Rolle spielt, gilt die alte Regel: Je früher ein Fehler gefunden wird, desto weniger Kosten verursacht das Beseitigen.

________________________________________________________________________

Data Race betrifft die Variable Console device - grosses Risiko
Erster Thread
© Grammatech

Großes Risiko aufgrund kleiner Fehler

Oft sind es gerade die kleinen Fehler, die eine Software angreifbar machen und die mithilfe der statischen Analyse relativ einfach zu beseitigen wären. Ein typisches Beispiel dafür ist die Sicherheitslücke in »beep«, einem kleinen Kommandozeilen-Tool bei Linux mit nicht einmal 250 Code-Zeilen. Beep gibt einfach einen Ton auf dem PC-Lautsprecher aus, Frequenz und Dauer sind über Parameter beim Aufruf einstellbar. Bis Version 1.3.4 fand sich hier ein Bug, über den ein Angreifer privilegierte Benutzerrechte auf dem System erlangen konnte. Voraussetzung für einen Exploit des Bugs ist, dass Beep mit »setuid root« ausgeführt wird.

Data Race betrifft die Variable Console device - grosses Risiko
Zweiter Thread
© Grammatech

Bei zahlreichen Linux-Distributionen wie etwa Debian war das der Fall, da das Tool einen Schreibzugriff auf die virtuelle Konsole benötigt. Beep parst einige Argumente der Kommandozeile und übergibt den Befehl zum Erzeugen eines Tons an die Systemfunktion »ioctl()«. Über einen Signal-Handler erkennt der Anwender Interrupts. Im Signal-Handler liegt die Ursache für eine »Race Condition«. Eine Folge: Ein Angreifer kann während der Ausführung eine beliebige Datei angeben, in die Beep dann schreibt. So kann die Datei ein symbolischer Link zu jeder beliebigen Datei sein – ebenso zu Systemdateien.

Data Race betrifft die Variable Console device - grosses Risiko
Dritter Thread
© Grammatech

Das Data Race betrifft die geteilte Variable »console_device«. Als erster Thread wird das Hauptprogramm erkannt (Bild a), der zweite Thread ist der Signal-Handler (Bild b). Beide greifen auf die Variable console_device zu, ohne dass ein Locking oder ein anderer Mechanismus zur Synchronisation vorhanden ist (Bild c). Mithilfe der statischen Code-Analyse hätte ein Entwickler den Fehler frühzeitig erkennen können.

________________________________________________________________________

 

Der Autor

Klaus-Lambertz von Verifysoft
Klaus-Lambertz von Verifysoft.
© Verifysoft

Klaus Lambertz

ist Geschäftsführer von Verifysoft Technology. Er studierte Betriebswirtschaftslehre an der Fachhochschule Köln und dem Institut Supérieur de Gestion in Paris. Von 1993 bis 1999 verantwortete er den Export bei zwei der größten Druckereien Frankreichs. Vor Gründung von Verifysoft Technology im Jahr 2003 hatte Klaus Lambertz verschiedene Positionen im Vertrieb und im Management mehrerer Unternehmen im Bereich Software-Testing inne.

 


  1. Mit statischer Code-Analyse zum Erfolg
  2. Schwachstellen erkennen

Das könnte Sie auch interessieren

Verwandte Artikel

Verifysoft Technology