© thelightwriter, 123RF

Software wird immer komplexer und gleichzeitig im Internet der Dinge immer leichter von außen angreifbar. Hier springt Cppcheck in die Bresche: Das quelloffene Werkzeug spürt Programmierfehler und potenzielle Sicherheitslücken in C/C++-Quellcode schnell und mit wenig Aufwand auf.

Die deutsche Gesellschaft für Informatik hat 2014 fünf große Herausforderungen der kommenden Jahre und Jahrzehnte definiert, die sogenannten Grand Challenges der Informatik [1]. Bedenkt man, wie allgegenwärtig Software heute ist und in welchem Ausmaß wir uns auf sie verlassen müssen, überrascht es nicht, dass eine dieser Herausforderungen “Zuverlässigkeit der Software” heißt.

Das betrifft besonders eingebettete Systeme, wo Software oft sicherheitskritische Aufgaben übernimmt – sei es in einem Herzschrittmacher, einem hochautomatisierten Fahrzeug, einem Verkehrsleitsystem oder einer vernetzten Industrieanlage. Fehlerfreier Code ist so wichtig wie noch nie. Die (teilweise noch offene) Frage lautet, wie man das erreichen kann.

Ein Allheilmittel ist zwar nicht in Sicht, doch es gibt mittlerweile auch Open-Source-Werkzeuge, die der Entwickler zur Erhöhung der Codequalität einsetzen kann. Dieser Artikel stellt einen Vertreter dieser Gattung vor: Cppcheck [2], ein Tool für statische Analyse von C- und C++-Quellcode.

Statische Codeanalyse

Der Begriff statische Codeanalyse (SCA) steht für eine Vielzahl teilweise sehr unterschiedlicher Methoden zur Programmanalyse. Programmanalyse bezeichnet hier eine automatisierte Analyse des Programmverhaltens zur Aufdeckung von Qualitätsmängeln im Quellcode. Dazu zählen insbesondere Eigenschaften wie die Korrektheit und Robustheit des Programms.

Das sehr breite Spektrum von SCA-Methoden reicht von einfacher Suche auf dem in Einzeltokens zerlegten Quellcode (also einem “besseren Grep”) bis hin zu komplexen, semantikbasierten Analysemethoden. Dazu gehören etwa abstrakte Interpretation, Datenflussanalyse und symbolische Ausführung (Symbolic Execution), die teilweise sogar formale Garantien bezüglich des Aufdeckens bestimmter Fehlerklassen bieten.

Gemeinsam ist allen SCA-Methoden, dass die Analysen auf einer abstrakten Repräsentation des Programms stattfinden, und somit ohne ein tatsächliches Ausführen des Codes. Dadurch lassen sich unter anderem auch Teilprogramme oder Programme untersuchen, die (noch) nicht kompilierfähig sind, beispielsweise wenn Bibliotheken fehlen, gegen die diese Programme gelinkt werden müssen.

Der Ursprung statischer Codeanalysen liegt im Compilerbau, wo SCA ursprünglich vor allem dazu diente, redundanten Code zu identifizieren. Auch heutige Compiler nutzen statische Codeanalyse in breitem Ausmaß. Mit den Ergebnissen solcher Analysen lassen sich redundante Berechnungen eliminieren und das transformierte Programm somit wesentlich effizienter ausführen. Optimierungen dieser Art umfassen beispielsweise:

• das Herausziehen von Berechnungen aus dem Schleifenrumpf, die sich über Schleifendurchläufe hinweg nicht ändern,
• das Vermeiden überflüssiger Berechnungen, deren Ergebnisse man bereits zur Compile-Zeit bestimmen kann, etwa wenn das Ergebnis einer Berechnung nur von Konstanten abhängt,
• oder das Wiederverwenden von Zwischenergebnissen des Programms, um identische Berechnungen nicht mehrfach auszuführen.

Neben den Analysen in Compilern gibt es seit einigen Jahren eine zunehmende Anzahl dedizierter Werkzeuge zur statischen Codeanalyse. Mit ihnen kann der Entwickler Quellcode auf seine Korrektheit überprüfen, und zwar mittels zusätzlicher Analysen, die der Compiler nicht abdeckt. Ein Beispiel dafür bieten Analysen zur korrekten Verwendung von Bibliotheken wie STL oder Boost. Ein ebenfalls sehr häufiger Anwendungsfall für dedizierte SCA-Werkzeuge stellt das Überprüfen des Quellcodes auf die Einhaltung bestimmter Richtlinien dar, wie MISRA C oder den CERT C Coding Standard. Des Weiteren kommen solche Werkzeuge auch oft zum Einsatz, um sicherheitsrelevante Schwachstellen im Quellcode aufzuspüren.

Cppcheck

Cppcheck, ein quelloffenes Werkzeug für statische Codeanalyse von C/C++-Quellcode, kommt vorpaketiert mit rund 180 Checks, die vor allem undefiniertes Programmverhalten und gefährliche Codekonstrukte finden sollen. Dazu zählen Checks zum Auffinden von ungültigen Zeigern (Dead Pointers), Divisionen durch Null, Integer-Überläufen, ungültiger Nutzung der STL-Bibliothek, Dereferenzieren von Null-Zeigern (Null Pointer), Zugriffe außerhalb von Array-Grenzen sowie Verwenden nicht initialisierter Variablen.

In Hinblick auf Security bringt Cppcheck Prüfungen mit, die Pufferüberläufe (Buffer Overflow), fehlende Validierung der Benutzereingaben und ähnliche Probleme im Quellcode aufspüren. Allerdings zielt Cppcheck nicht schwerpunktmäßig auf Security-Schwachstellen ab und prüft den Quellcode auch nicht dediziert auf (teils sehr spezielle) Programmierkonstrukte, die oftmals zu Security-Schwachstellen führen.

Cppcheck lässt sich nicht nur, wie im Folgenden gezeigt, alleine einsetzen. Es steckt zudem auch bei so manchem kommerziellen Tool zur statischen Codeanalyse unter der Haube. So setzt etwa Codacy, eine Lösung zur automatisierten Codeanalyse, Cppcheck ein. Für SonarQube, eine Plattform für kontinuierliche Codeinspektion, gibt es ein Open Community Plugin für die Programmiersprachen C und C++, über das sich Cppcheck einbinden lässt.

Denkt der Entwickler über eine hochgradige Automatisierung der statischen Codeanalyse nach, zum Beispiel als Teil der CI/CD-Pipeline, erweist sich Cppcheck als durchaus interessanter Kandidat: Es ist darauf ausgelegt, möglichst nur echte Fehler im Quellcode zu finden, also so wenige False Positives wie möglich zu melden. Weitaus mächtigere SCA-Tools sind in der Lage, alle Fehler bestimmter Klassen im Quellcode garantiert zu finden, allerdings auf Kosten einer großen Anzahl von False Positives, die der Entwickler dann manuell überprüfen muss.

Installation von Cppcheck

Unter Fedora und Debian liegt Cppcheck als Paket vor; unter Debian lässt es sich beispielsweise einfach per »sudo apt-get install cppcheck« einrichten. Ein Nachteil dieser Option besteht allerdings darin, dass das Paket eventuell auf einer veralteten Version von Cppcheck basiert. Darum sollte man den Codeprüfer am besten direkt aus dem Quellcode bauen.

Um das eigene Host-Betriebssystem nicht mit ansonsten unnötiger Software zu belasten, empfiehlt sich eine Installation in einem Docker-Container, der sich dann interaktiv verwenden lässt. Dazu legt der Entwickler am besten ein neues Verzeichnis an, wechselt dorthin und speichert die in Listing 1 gezeigten Befehle in der Datei »Dockerfile«. Der Container lässt sich anschließend im selben Verzeichnis mit dem folgenden Befehl bauen:

# docker build . -t cppcheck-interactive

FROM ubuntu:latest
RUN apt-get update && \
    apt-get install build-essential -y && \
    apt-get install libpcre3-dev -y && \
    apt-get install git -y && \
    apt-get install python -y && \
    git clone https://github.com/danmar/cppcheck.git
WORKDIR cppcheck
RUN make MATCHCOMPILER=yes FILESDIR=/cppcheck HAVE_RULES=yes CXXFLAGS="-O2 -DNDEBUG -Wall -Wno-sign-compare -Wno-unused-function"
WORKDIR /opt/cppcheck
ENV PATH="${PATH}:/cppcheck"

Das Erstellen des Containers dauert eine Weile, da zusätzlich zur Installation der benötigten Tools und dem Auschecken des Cppcheck-Repositorys Cppcheck selbst aus dem Quellcode gebaut wird. Nach dem erfolgreichen Erstellen des Containers sollten als letzte Docker-Ausgaben im Terminal die Meldungen aus den Zeilen 2 und 3 von Listing 2 erscheinen (wobei der Hash »c6f939…« sich von System zu System unterscheidet). Um das Image noch einmal zu validieren, kann der Entwickler mit dem Befehl »docker image ls« prüfen, ob es verfügbar ist (Zeile 4).

[...]
Successfully built c6f939b311b2
Successfully tagged cppcheck-interactive:latest
# docker image ls
REPOSITORY             TAG      IMAGE ID       CREATED         SIZE
cppcheck-interactive   latest   c6f939b311b2   4 minutes ago   492MB
[...]

Cppcheck in Aktion

Nun geht es an den ersten praktischen Einsatz von Cppcheck. Dabei dient der gerade gebaute Docker-Container als Basis und die in Listing 3, Listing 4 und Listing 5 gezeigten C-Dateien als Beispiele. Sie liegen alle im Unterverzeichnis »src/«.

int main() {
  char a[10];
  a[10] = 0;
  return 0;
}

#include <string.h>
#include <stdio.h>
int main(int argc, char** argv) {
  char buf[20];
  strcpy(buf, argv[1]);
  printf("%s\n", buf);
  return 0;
}

int main() {
  char b[5];
  char c[10];
  c[10] = 0;
  b[5] = 1;
  return 0;
}

Nun startet der Entwickler den Cppcheck-Container mittels des Befehls aus Listing 6. Der Schalter »–rm« teilt Docker mit, dass der Container nicht langfristig benötigt wird, sondern nach der Nutzung gleich weggeworfen werden kann. Der Schalter »-it« bewirkt, dass der Container im interaktiven Modus startet und der Anwender damit Zugriff auf die Kommandozeile innerhalb des Containers erhält. Über den Schalter »-v« bindet der Nutzer schließlich das Verzeichnis »./src/« auf dem Host-Betriebssystem unter dem Verzeichnis »/opt/src/« im Docker-Container ein. Das erlaubt es, innerhalb des Docker-Containers auf den zu prüfenden Quellcode im Host-Verzeichnis »./src/« zuzugreifen.

$ docker container run --rm -it -v $(pwd)/src:/opt/src cppcheck-interactive

Sobald der Cppcheck-Container im interaktiven Modus gestartet ist, erhält der Anwender Zugriff auf die Konsole innerhalb des Docker-Containers und kann mit dem ersten Aufruf aus Listing 7 die Datei »file1.c« auf etwaige Programmierfehler überprüfen. Cppcheck findet auch sofort einen Fehler in »file1.c«.

Da das Array »a[]« gemäß der Definition nur eine Länge von 10 Elementen hat, ist der Zugriff auf das Element »a[10]« illegal. C spricht, wie viele andere Programmiersprachen, das erste Element des Arrays mit »a[0]« an, sodass »a[10]« auf ein nicht definiertes 11. Element verweist. Die Cppcheck-Meldung enthält für den Entwickler wertvolle Informationen wie den Namen der fehlerhaften Datei, die Zeilen- und Spaltennummer der illegalen Operation sowie eine kurze, aber gut verständliche Erklärung des Fehlers.

# cppcheck /opt/src/file1.c
Checking /opt/src/file1.c ...
/opt/src/file1.c:3:4: error: Array 'a[10]' accessed at index 10, which is out of bounds. [arrayIndexOutOfBounds]
  a[10] = 0;
   ^
# cppcheck src/
Checking src/file1.c ...
src/file1.c:3:4: error: Array 'a[10]' accessed at index 10, which is out of bounds. [arrayIndexOutOfBounds]
  a[10] = 0;
   ^
1/2 files checked 26% done
Checking src/file2.c ...
2/2 files checked 100% done
# cppcheck src/ -isrc/file1.c
Checking src/file2.c ...

Praktischerweise kann man Cppcheck nicht nur eine Datei als Argument übergeben, sondern gleich ein ganzes Verzeichnis mit C/C++-Dateien (Listing 7, zweiter Aufruf). Darüber hinaus kann der Entwickler mit der Option »-i« bestimmte Dateien oder Pfade von der Analyse ausschließen (dritter Aufruf).

Als Unterstützung für den Entwickler klassifiziert Cppcheck seine Findings und ordnet sie automatisch einer Kategorie zu. Als »error« stuft es alle Findings ein, die es als Programmierfehler ansieht. Die Kategorie »warning« enthält Findings, die als Vorschläge im Sinne eines defensiven Programmierstils gemeint sind und die Wahrscheinlichkeit von Bugs reduzieren (aber nicht notwendigerweise Bugs sind).

Findings zu sogenannten Code Smells, zum Beispiel nicht genutzten Funktionen oder redundantem Code, ordnet Cppcheck der Kategorie »style« zu. In die Kategorie »performance« fallen Findings zu potenziellen Performance-Problemen sowie Vorschläge, wie man diese Codefragmente besser umformulieren kann. Findings zu möglichen Portierbarkeitsproblemen gehören in die Kategorie »portability«. Schließlich ordnet Cppcheck potenzielle Konfigurationsprobleme noch der Kategorie »information« zu.

Unterdrücken ausgewählter Findings

Möchte der Entwickler bestimmte Cppcheck-Findings unterdrücken, weil sie beispielsweise für seine aktuelle Analyse nicht relevant sind, nutzt er dazu den Schalter »–suppress«. Dabei stehen ihm drei Möglichkeiten zur Verfügung, um eine Unterdrückungsregel für Cppcheck-Meldungen zu definieren:

• »[Fehler-ID]«
• »[Fehler-ID]:[Dateiname]«
• »[Fehler-ID]:[Dateiname]:[Zeile]«

Listing 8 zeigt die Auswirkung der unterschiedlichen Schemata zur Definition von Unterdrückungsregeln. Die Option »[Fehler-ID]« bewirkt, dass Cppcheck alle Findings zu einem bestimmten Fehlertyp unterdrückt, im konkreten Beispiel »arrayIndexOutOfBounds« (erster Aufruf). Mit der zweiten Option (»[Fehler-ID]:[Dateiname]«) weist der Entwickler Cppcheck an, Findings zu diesem Fehlertyp in einer bestimmten Datei zu ignorieren (zweiter Aufruf: Datei »file3.c«). Um noch präziser zu werden, greift er zum Schema »[Fehler ID]:[Dateiname]:[Zeile]« und unterdrückt damit sehr gezielt bestimmte Findings nur für ganz bestimmte Stellen im Quellcode (dritter Aufruf).

# cppcheck --suppress=arrayIndexOutOfBounds src/
Checking src/file1.c ...
1/3 files checked 18% done
Checking src/file2.c ...
2/3 files checked 71% done
Checking src/file3.c ...
3/3 files checked 100% done
# cppcheck --suppress=arrayIndexOutOfBounds:src/file3.c src/
Checking src/file1.c ...
src/file1.c:3:4: error: Array 'a[10]' accessed at index 10, which is out of bounds. [arrayIndexOutOfBounds]
  a[10] = 0;
   ^
1/3 files checked 18% done
Checking src/file2.c ...
2/3 files checked 71% done
Checking src/file3.c ...
3/3 files checked 100% done
# cppcheck --suppress=arrayIndexOutOfBounds:src/file3.c:5 src/
Checking src/file1.c ...
src/file1.c:3:4: error: Array 'a[10]' accessed at index 10, which is out of bounds. [arrayIndexOutOfBounds]
  a[10] = 0;
   ^
1/3 files checked 18% done
Checking src/file2.c ...
2/3 files checked 71% done
Checking src/file3.c ...
src/file3.c:6:4: error: Array 'b[5]' accessed at index 5, which is out of bounds. [arrayIndexOutOfBounds]
  b[5] = 1;
   ^
3/3 files checked 100% done

Um die gewünschten Unterdrückungen nicht jedes Mal manuell auf der Kommandozeile eingeben zu müssen, bietet Cppcheck die Möglichkeit, eine sogenannte Suppression-Datei anzulegen, in der der Entwickler die gewünschten Unterdrückungen auflistet. Diese Datei übergibt er Cppcheck dann beim Aufruf mittels des Schalters »–suppressions-list«.

Vollautomatisierte Analysen

Möchte der Entwickler seinen Quellcode regelmäßig beziehungsweise kontinuierlich mit Cppcheck überprüfen, ist das oben beschriebene interaktive Vorgehen nicht sehr nützlich. Es enthält zu viele manuelle Schritte, die der Entwickler jedes Mal wiederholen muss. Für eine solche Aufgabe ist es sinnvoller, den Docker-Container so zu bauen, dass man lediglich beim Starten des Containers das Quellcodeverzeichnis einbinden muss und Cppcheck seine Arbeit völlig automatisch im Hintergrund erledigt.

Listing 9 zeigt das Dockerfile für einen solchen Container. Dabei handelt es sich lediglich um eine kleine Erweiterung des interaktiven Cppcheck-Containers. Die beiden vorletzten Docker-Befehle kopieren das in Listing 10 gezeigte Skript »cppcheck_examine.sh« in den Docker-Container und machen es ausführbar. Das letzte Kommando setzt den sogenannten Entrypoint des Containers auf dieses Skript, was bewirkt, dass es nach dem Start des Containers automatisch ausgeführt wird. Somit lässt sich der Container sehr einfach in einer CI/CD-Pipeline oder als Kommandozeilenwerkzeug nutzen.

FROM ubuntu:latest
RUN apt-get update && \
    apt-get install build-essential -y && \
    apt-get install libpcre3-dev -y && \
    apt-get install git -y && \
    apt-get install python -y && \
    git clone https://github.com/danmar/cppcheck.git
WORKDIR cppcheck
RUN make MATCHCOMPILER=yes FILESDIR=/cppcheck HAVE_RULES=yes CXXFLAGS="-O2 -DNDEBUG -Wall -Wno-sign-compare -Wno-unused-function"
WORKDIR /opt/cppcheck
ENV PATH="${PATH}:/cppcheck"
ADD cppcheck_examine.sh /opt/cppcheck/cppcheck_examine.sh
RUN chmod +x /opt/cppcheck/cppcheck_examine.sh
ENTRYPOINT ["/opt/cppcheck/cppcheck_examine.sh"]

#!/bin/bash
echo "Running Cppcheck ..."
cppcheck /opt/cppcheck/src &> /opt/cppcheck/report/cppcheck.report

Das Skript »cppcheck_examine.sh« startet seinerseits Cppcheck. Dabei übergibt es ihm das Verzeichnis »/opt/cppcheck/src/« als Argument, wo sich (innerhalb des Containers) der zu analysierende Quellcode befinden muss. Die Ausgabe von Cppcheck leitet das Skript in die Datei »/opt/cppcheck/report/cppcheck.report« um. Analog zur interaktiven Variante baut der Entwickler den automatisierten Cppcheck-Container mit folgendem Befehl:

# docker build . -t cppcheck-automated

Jetzt muss er nur noch beim Starten des Containers die entsprechenden Verzeichnisse richtig einbinden. Das nachfolgende Beispiel geht davon aus, dass der zu analysierende Quellcode auf dem Host-System im Ordner »src/« des aktuellen Verzeichnisses liegt. Zudem sollen die Ergebnisse der Cppcheck-Analyse im Unterverzeichnis »report/« auf dem Host-System landen. Dann ruft der Entwickler den Docker-Container mit dem Befehl aus Listing 11 auf.

# docker container run --rm -v $(pwd)/src/:/opt/cppcheck/src -v $(pwd)/report/:/opt/cppcheck/report/ cppcheck-automated

Das Kommando startet den Docker-Container »cppcheck-automated«. Zudem sorgt es dafür, dass das Quellcodeverzeichnis und das Verzeichnis zum Speichern des Cppcheck-Berichts richtig eingebunden und somit für das im Container laufende Skript »cppcheck_examine.sh« erreichbar sind. Die Ergebnisse der Analyse schreibt Cppcheck in die Datei »cppcheck.report« (wie in »cppcheck_examine.sh« definiert) im Unterverzeichnis »report/« auf dem Host-System.

Grenzen von Cppcheck

Um die Grenzen von Cppcheck zu verstehen, muss man sich die Cppcheck-Ergebnisse für die in Listing 4 gezeigte Datei »file2.c« etwas genauer ansehen. Der Code enthält einen schweren Programmierfehler, den ein Angreifer sogar für eine böswillige Attacke ausnutzen kann. Dazu muss er das Programm mit einer Eingabe seiner Wahl aufrufen können, was man als wahrscheinlich annehmen sollte.

Konkret handelt es sich um einen klassischen Buffer-Overflow: Die Größe des Arrays »buf[]« beträgt fix 20 Byte. Die Funktion »strcpy()« kopiert in dieses Array jedoch eine Zeichenkette beliebiger Länge, das vom Benutzer frei wählbare Argument »argv[1]«. Ist also die Benutzereingabe länger als 20 Zeichen, schreibt »strcpy()« über die Grenzen von »buf[]« hinaus. Ein Angreifer könnte damit den Programm-Stack mit beliebigen Daten überschreiben und somit die volle Kontrolle über das Programm erlangen (Control Flow Hijacking).

Diese kritische Schwachstelle in »file2.c« ist für einen einigermaßen geübten C-Programmierer eigentlich leicht zu entdecken, gehört sie doch zu den typischen Anfängerfehlern. Es wäre daher intuitiv zu erwarten, dass Cppcheck dieses Problem findet. Lässt man Cppcheck auf »file2.c« los, erhält man jedoch lediglich die in Listing 12 gezeigte Ausgabe. Offensichtlich findet keiner der Default-Checker diese triviale Schwachstelle, was zu einem False Negative führt – ein tatsächlich existierender Fehler im Code fällt unter den Tisch.

# cppcheck /opt/src/file2.c
Checking /opt/src/file2.c ...

Fazit

Cppcheck bietet dem C/C++-Entwickler eine einfache Möglichkeit, den Quellcode auf Programmierfehler und sicherheitsrelevante Schwachstellen zu untersuchen. Baut man sich einen entsprechenden Docker-Container, kann die Code-Analyse auch vollautomatisiert als Teil einer CI/CD-Pipeline oder als Cron-Job laufen. Mit den rund 180 Checkern, die Cppcheck von Haus aus mitbringt, findet es bereits viele Fehler im Quellcode und qualifiziert sich damit als wertvolles Helferlein für den Entwickler.

Wie die meisten Bug-Finding-Tools legt auch Cppcheck Wert darauf, die Anzahl der False Positives möglichst gering zu halten. Das hat allerdings zur Folge, dass es nur vergleichsweise einfache Analysen vornimmt, die bestimmte Fehler im Code nicht finden und somit zu False Negatives führen. Deswegen bedeutet ein “sauberer” Cppcheck-Durchlauf keineswegs, dass der Programmcode frei von Fehlern ist.

Andererseits ermöglicht gerade die niedrige False-Positives-Rate, Cppcheck routinemäßig und sogar als Teil einer CI/CD-Pipeline zu nutzen. Bei größeren Software-Projekten sollte man sich jedoch mit den Einstellungen des Werkzeugs vertraut machen und es entsprechend den Gegebenheiten der zu untersuchenden Software konfigurieren. Für wirklich gute Analyseresultate empfiehlt es sich, eigene Checker zu schreiben. Die Cppcheck-Dokumentation [3] beschreibt, wie man mithilfe regulärer Ausdrücke eigene Regeln definiert und überprüft.