Unsicheren C-Code mit Valgrind erkennen und mit Snyk Code beheben

C und C++ sind nach wie vor grundlegend für die Entwicklung kritischer Software. Diese Programmiersprachen kommen in einer Vielzahl von Systemen zum Einsatz – von eingebetteten Geräten bis hin zu Hochleistungsanwendungen in der Fertigung, der Betriebstechnik (OT) und der Industrie. Ihre Effizienz, die Kontrolle über Systemressourcen und ihre Leistungsfähigkeit machen sie für Entwicklerinnen und Entwickler unverzichtbar, die an geschäftskritischen Projekten arbeiten.

C und C++ sind besonders in Japan weit verbreitet, wo die Fertigungs- und Industriesektoren wichtige Wirtschaftsmotoren sind. Japanische Entwicklerinnen und Entwickler setzen auf diese Programmiersprachen, um robuste und effiziente Software zu entwickeln, die alles von Fahrzeugsystemen bis zur Fabrikautomatisierung unterstützt. Die Präzision und Zuverlässigkeit von C und C++ sind entscheidend, um die hohen Standards dieser Branchen einzuhalten.

Die Bedeutung von Code-Sicherheit in C und C++

C und C++ bieten zwar beispiellose Kontrolle und Leistung, stellen aber auch erhebliche Sicherheitsherausforderungen dar. Da integrierte Sicherheitsfunktionen wie die automatische Speicherverwaltung fehlen, sind diese Programmiersprachen anfällig für Schwachstellen wie Pufferüberläufe, Use-after-free und Speicherlecks. Diese Schwachstellen mögen zunächst harmlos und einfach erscheinen, können jedoch schwerwiegende Folgen haben – insbesondere in kritischer Software, bei der Zuverlässigkeit und Sicherheit oberste Priorität haben.

Anfälliger C-Code verursacht ein Speicherleck

Sehen wir uns ein Beispiel für anfälligen C-Code an, den Entwicklerinnen und Entwickler schreiben könnten und der eine Sicherheitslücke durch ein Speicherleck verursacht.

Hier sehen Sie unseren C-Programmcode. Erkennen Sie die Sicherheitslücke?

#include <stdio.h>
#include <stdlib.h>

void allocateMemory() {
    int *ptr = (int *)malloc(10 * sizeof(int));
    if (ptr == NULL) {
        printf("Memory allocation failed\n");
        return;
    }
}

int main() {
    allocateMemory();
    return 0;
}

Die Datei program1.c enthält ein Beispiel für eine Schwachstelle bei der dynamischen Speicherzuweisung (MISRA Dir 4.12, MISRA Rule 21.3). Die Sicherheitslücke in der Funktion allocateMemory() besteht darin, dass sie mit malloc() Speicher reserviert, ihn aber nicht wieder freigibt. Dadurch entsteht ein Speicherleck. Dies lässt sich verhindern, indem Sie die MISRA-Richtlinien befolgen, die die dynamische Speicherzuweisung einschränken.

Das ist ein häufiger Fehler bei der C-Programmierung und kann dazu führen, dass Ihr Programm mit der Zeit immer mehr Speicher belegt. Irgendwann kann der Speicher ausgehen, sodass Ihr Programm abstürzt oder anderen Programmen auf Ihrem System kein Speicher mehr zur Verfügung steht.

Warum verwenden wir nicht einfach eine statische Speicherzuweisung wie int arr[10]? In manchen Situationen lässt sich Speicher nicht auf dem Stack zuweisen. Angenommen, Sie schreiben eine Funktion, die eine Datei in den Speicher einliest. Die Dateigröße ist erst zur Laufzeit bekannt, daher können Sie kein Array mit fester Größe verwenden. Stattdessen können Sie mit malloc genau die benötigte Speichermenge reservieren, sobald Sie die Dateigröße kennen.

Kompilieren Sie das Programm und führen Sie es anschließend aus:

$ gcc program1.c -o program1
$ ./program1

Enthält das Programm ein Speicherleck? Wie können Sie es beheben? 

C-Sicherheitslücken mit Valgrind finden

Valgrind ist ein leistungsstarkes Tool, mit dem Sie Speicherlecks in Ihrem Programm finden können. Wir können das Programm mit Valgrind ausführen und prüfen, ob Speicherlecks vorhanden sind.

Installieren Sie Valgrind auf Ihrem System. Wenn Sie ein Linux-basiertes System verwenden, können Sie es über den Paketmanager installieren. Hier ein Beispiel für ein Debian-basiertes System:

sudo apt-get install valgrind

Hinweis: Wenn Sie macOS mit ARM-basierten Chips verwenden, wird Valgrind nicht unterstützt. Daher überspringen wir diesen Schritt und führen Valgrind in einem Docker-Container aus:

docker build -t "valgrind" . -f Dockerfile

Starten Sie anschließend den Container und binden Sie das aktuelle Verzeichnis in das Verzeichnis /tmp des Containers ein:

docker run -it -v $PWD:/tmp -w /tmp valgrind

Kompilieren Sie dann das Programm program1.c im Container:

gcc program1.c -o program1.app

Anschließend können wir das Programm mit Valgrind ausführen, um nach Speicherlecks zu suchen:

valgrind --leak-check=full ./program1.app

Anschließend sollte Valgrind eine Ausgabe mit dem Speicherleck anzeigen:

/tmp # valgrind --leak-check=full ./program1.app

==29== Memcheck, a memory error detector
==29== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
==29== Using Valgrind-3.23.0 and LibVEX; rerun with -h for copyright info
==29== Command: ./program1
==29==
==29==
==29== HEAP SUMMARY:
==29==     in use at exit: 40 bytes in 1 blocks
==29==   total heap usage: 1 allocs, 0 frees, 40 bytes allocated
==29==
==29== 40 bytes in 1 blocks are definitely lost in loss record 1 of 1
==29==    at 0x48E978C: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-arm64-linux.so)
==29==    by 0x108823: allocateMemory (in /tmp/program1)
==29==    by 0x108857: main (in /tmp/program1)
==29==
==29== LEAK SUMMARY:
==29==    definitely lost: 40 bytes in 1 blocks
==29==    indirectly lost: 0 bytes in 0 blocks
==29==      possibly lost: 0 bytes in 0 blocks
==29==    still reachable: 0 bytes in 0 blocks
==29==         suppressed: 0 bytes in 0 blocks
==29==
==29== For lists of detected and suppressed errors, rerun with: -s
==29== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

Valgrind ist ein großartiges Tool. Doch für die tägliche Arbeit in der C-Entwicklung ist dieser Workflow nicht skalierbar, da das vollständige Programm für die Analyse erst kompiliert und erstellt werden muss.

Mit Snyk Code können Sie diese Schwachstelle in Ihrer Codebasis erkennen, ohne den Code kompilieren zu müssen. Installieren Sie einfach die Erweiterung und öffnen Sie die Datei – schon wird die Schwachstelle angezeigt. Snyk Code ist ein Tool zur statischen Codeanalyse, das Machine-Learning-Techniken einsetzt, um statischen Code zu untersuchen, ohne dass dafür ein Build- und Kompilierungsschritt erforderlich ist. So erhalten Sie schnelles und zuverlässiges Feedback mit wenigen falsch positiven Ergebnissen, wenn Snyk Ihren Code auf Sicherheitslücken untersucht.

Path Traversal, Pufferüberläufe und weitere C-Schwachstellen erkennen

Die SAST-Engine hinter Snyk Code erkennt mehr Schwachstellentypen als nur Speicherlecks durch malloc.

Sehen wir uns ein komplexeres Beispiel an, das mehrere unsichere Programmierpraktiken in C vereint und Sicherheitslücken verursacht:

#include<stdio.h>
#include<stdlib.h>
#include<string.h>

int main(int argc, char *argv[]) {
    // get the filename from the first command line argument 
    char *filename = argv[1];
    // append the filename to the current directory
    char path[50] = "./";
    strcat(path, filename);

    FILE *file = fopen(path, "r");
    if (file == NULL) {
        printf("Error opening file!\n");
        exit(1);
    }

    // read the contents of the file into memory and print the size of the file:
    fseek(file, 0, SEEK_END);
    long fsize = ftell(file);
    fseek(file, 0, SEEK_SET);
    char *string = malloc(fsize + 1);
    fread(string, fsize, 1, file);
    free(string);

    printf("Size of the file: %ld\n", fsize);
    printf("Contents of the file: %s\n", string);

    if (string != NULL) {
        free(string);
    }

    if (fsize == 0) {
        string[0] = 'A';
    }

    fclose(file);
    return 0;
}

Das obige C-Programm ist voller Schwachstellen. Es ist jedoch ein sehr knappes und vereinfachtes Beispiel für unsicheren Code, das vor allem der Kürze halber dient. Einige der subtileren Programmierpraktiken könnten dennoch leicht in realen Codebasen auftauchen.

Nach der Kompilierung können Sie das Programm ausführen:

$ ./program3.app "text.txt"

Wenn sich im selben Verzeichnis eine Datei namens text.txt befindet und sie nicht leer ist, liest das Programm die Datei ein und gibt ihren Inhalt aus.

Zum Beispiel:

Size of the file: 44
Contents of the file: FROM alpine:latest
RUN apk add g++ valgrind

Sieht gut aus. Was passiert, wenn Sie eine Datei übergeben, die die Verzeichnisstruktur durchläuft?

$ ./program3.app "../../../../../etc/passwd"

Das Programm weist eine Path-Traversal-Schwachstelle auf, die Angreifenden das Lesen vertraulicher Dateien auf dem System ermöglicht.

Um weitere Schwachstellen zu testen, versuchen Sie Folgendes:

• Übergeben Sie eine Datei, die nicht existiert

• Übergeben Sie eine leere Datei

• Übergeben Sie einen Dateinamen oder vollständigen Pfad, der zu lang ist (mehr als 50 Zeichen)

Einige dieser Sicherheitsprobleme gehen weit über die C-Kenntnisse von Entwicklerinnen und Entwicklern hinaus. Path Traversal erfordert beispielsweise mehr Bewusstsein für Anwendungssicherheit als für sichere Speicherverwaltung und fundierte C-Entwicklung.

Zum Glück analysiert die Snyk-Erweiterung den C-Code auf unsichere Programmierkonventionen und häufige Probleme der Anwendungssicherheit, sobald Sie den Programmcode in die IDE einfügen. Sie meldet diese schnell und zeigt den jeweiligen Codekontext direkt inline an: 

Schützen Sie Ihren C- und C++-Code mit Snyk

Ein Sicherheitsvorfall in der Fertigungs- und Industriebranche kann katastrophale Folgen haben – darunter Betriebsunterbrechungen, Sicherheitsrisiken und finanzielle Verluste. Die Sicherheit von C- und C++-Code zu gewährleisten, ist nicht nur eine Best Practice, sondern notwendig. Snyk unterstützt Entwicklerinnen und Entwickler dabei, Schwachstellen früh im Entwicklungsprozess zu erkennen und zu beheben.