Etwas seltsam, aber: Es handelt sich um ein Denial-of-Service-Risiko oder eine potenzielle Offenlegung von Informationen.

Da der Präprozessor von C alle in einer #include -Anweisung angegebenen Dateien fröhlich enthält, kann jemand #include "../../../../. ./../../../../../dev/zero " und der Präprozessor versuchen, bis zum Ende von / dev / zero zu lesen (viel Glück ).

In ähnlicher Weise könnte jemand versuchen, verschiedene Dateien einzuschließen, die möglicherweise auf Ihrem System vorhanden sind oder nicht, und insbesondere Informationen über Ihren Computer erhalten, insbesondere wenn Sie die Ausgabe ihrer Kompilierungsversuche anzeigen lassen. In Kombination mit der cleveren Verwendung von #pragma gift können sie sogar etwas über den Dateiinhalt erfahren, selbst wenn Sie keine vollständigen Fehlermeldungen angeben.

In ähnlicher Weise können Pragmas das Verhalten von Präprozessoren, Compilern oder Linkern stark verändern und werden in Quelldateien angegeben. Es gibt wahrscheinlich keine, mit der jemand den Namen der Ausgabedatei oder ähnliches angeben kann. Wenn dies jedoch der Fall ist, kann er missbraucht werden, um vertrauliche Dateien zu überschreiben oder sich selbst ausführen zu lassen (indem er in cron schreibt) oder ähnliches). Es könnte etwas ähnlich Gefährliches geben. Sie sollten wirklich vorsichtig sein, wenn Sie nicht vertrauenswürdigen Code kompilieren.

Compiler-Bomben

C ist eine sehr mächtige Sprache, und einige der schrecklichen Dinge, die Sie damit tun können, würden Sie schockieren. Sie können beispielsweise ein 16-Byte-C-Programm erstellen, dessen Kompilierung 27 Minuten dauert . Nach Abschluss wird es auf 16 Gigabyte em kompiliert > ausführbare Datei. Und das mit nur 16 Bytes. Wenn Sie den Präprozessor und größere Quellcodedateien berücksichtigen, können Sie sicher viel größere Compilerbomben erstellen.

Dies bedeutet, dass jeder, der Zugriff auf Ihren Server hat, effektiv ein DoS a ausführen kann > Angriff auf Ihren Server. Um fair zu sein, ist dies deutlich weniger gefährlich, als wenn jemand eine Sicherheitsanfälligkeit im Compiler missbraucht oder vertrauliche Dateien einschließt, um Informationen über Ihren Server zu erhalten (wie die anderen Antwortenden, über die gesprochen wurde).

Aber es ist noch eine andere Mögliche Belästigung beim Kompilieren von beliebigem Code. Ich bin sicher, Sie könnten ein Zeitlimit für alle Builds festlegen und sicherstellen, dass die Binärdateien niemals gespeichert werden. Obwohl Sie es natürlich immer noch auf der Festplatte behalten müssen, während es erstellt wird . Wenn also jemand eine Compilerbombe hypothetisch größer als Ihre Festplatte gemacht hat, sind Sie in Schwierigkeiten (wenn Sie den Build zulassen beenden).

@ AndréBorie ist korrekt. Compiler und die entsprechende Konfiguration werden nicht gut auf Sicherheitsprobleme überprüft. Daher sollten Sie im Allgemeinen keinen nicht vertrauenswürdigen Code kompilieren.

Das Risiko besteht darin, dass ein Pufferüberlauf oder eine Sicherheitsanfälligkeit bezüglich der Bibliotheksausführung ausgenutzt wird Der Angreifer erhält Zugriff auf das Benutzerkonto (hoffentlich nicht root !), auf dem der Compiler ausgeführt wurde. Selbst ein Nicht- root -Hack ist in den meisten Fällen schwerwiegend. Dies könnte in einer separaten Frage erläutert werden.

Das Erstellen einer VM ist eine gute Lösung, um potenzielle Exploits einzudämmen, damit sie den Rest Ihrer Anwendung nicht schädigen können.

Es ist am besten Um eine Linux-Vorlagen-VM zu haben, können Sie diese nach Bedarf mit einer sauberen Slate-Compiler-Umgebung starten.

Idealerweise würden Sie sie nach jedem Gebrauch wegwerfen, dies ist jedoch möglicherweise nicht unbedingt erforderlich. Wenn Sie die VM gut genug isolieren und die Antwortdaten von der VM ordnungsgemäß bereinigen, sollten Sie dies trotzdem tun. Dann ist das Schlimmste, was ein Hack tun kann, DoS oder das Erstellen falscher Kompilierungszeiten. Dies sind keine ernsthaften Probleme für sich; Zumindest nicht annähernd so ernst wie der Zugriff auf den Rest Ihrer Anwendung.

Das Zurücksetzen der VM nach jeder Verwendung (dh statt täglich) sorgt jedoch insgesamt für eine stabilere Umgebung und kann die Sicherheit in bestimmten Bereichen verbessern Fälle.

Einige Betriebssysteme bieten Container als Alternative zu VMs an. Dies mag ein schlankerer Ansatz sein, es gelten jedoch dieselben Grundsätze.

Ja, es ist gefährlich, aber wie die Leute gesagt haben, ist es möglich. Ich bin der Autor und Betreuer der Online-Compiler unter https://gcc.godbolt.org/, und ich fand es ziemlich praktikabel, sie mit einer Kombination aus: p sicher zu machen >

• Die gesamte Site wird auf einer VM-Instanz mit geringen Berechtigungen ausgeführt. Das Netzwerk ist stark eingeschränkt, da nur Port 80 sichtbar ist und ssh nur über IPs auf der Whitelist (meine eigenen) aktiviert ist.
• Jede Kompilierungsinstanz wird in einem wegwerfbaren Docker-Container mit noch weniger Berechtigungen
• ausgeführt Der Compiler wird von einem Skript ausgeführt, das alle Prozessgrenzen (Speicher, CPU-Zeit usw.) auf niedrige Grenzen setzt, um Codebomben zu verhindern.
• Der Compiler wird mit einem LD_PRELOAD ausgeführt Wrapper ( Quelle hier), der verhindert, dass der Compiler Dateien öffnet, die nicht auf einer expliziten Whitelist stehen. Dies verhindert, dass es / etc / passwd oder andere solche Dinge liest (nicht, dass das allzu viel helfen würde).
• Als Nizza analysiere ich die Befehlszeilenoptionen und führe den Compiler nicht aus, wenn Es gibt etwas besonders Verdächtiges. Dies ist kein wirklicher Schutz. Nur eine Möglichkeit, eine Fehlermeldung "Ernsthaft, versuchen Sie es nicht" zu geben, anstatt dass LD_PRELOAD ein schlechtes Verhalten erkennt.

Die gesamte Quelle befindet sich auf GitHub, ebenso wie die Quelle für die Docker-Container-Images und Compiler und dergleichen.

Ich habe einen Blog-Beitrag geschrieben, in dem erklärt wird, wie die Das gesamte Setup wird ebenfalls ausgeführt.

Sie möchten den Compiler nicht als Root ausführen, obwohl ich dies aus Gründen der "Einfachheit und Bequemlichkeit" gesehen habe. Für einen Angreifer wäre es allzu einfach, Folgendes einzuschließen:

  #include "../../../../etc/passwd"#include" ../. ./../../etc/shadow" 

und den Inhalt dieser Dateien als Teil der Compiler-Fehlermeldung zurückerhalten.

Auch Compiler sind Programme Wie alles andere und mit Fehlern, die anfällig sein könnten, wäre es für jemanden zu einfach, nur C-Programme zu fuzzeln und Probleme zu verursachen.

Die meisten Anwendungssicherheiten konzentrieren sich in erster Linie auf die Eingabevalidierung. Leider ist die Definition der 'sicheren und gültigen' Eingabe für einen C-Compiler wahrscheinlich mit dem Problem des Anhaltens in Bezug auf die Schwierigkeit verbunden :)

Wenn Sie einem Benutzer erlauben, ein Archiv mit dem Code bereitzustellen, können Probleme auftreten, nicht genau mit dem Compiler, sondern mit dem verwendeten Linker;)

ld folgt symbolischen Links wenn sie auf eine Datei verweisen, die nicht vorhanden ist. Dies bedeutet, dass, wenn Sie test.c in die Ausgabe a.out kompilieren, aber bereits einen symbolischen Link mit dem Namen a.out in Ihrem Verzeichnis haben, der auf eine nicht vorhandene Datei verweist, die kompilierte ausführbare Datei an der Stelle geschrieben wird, die auf die verweist Datei (mit Einschränkung der Benutzerrechte).

In der Praxis könnte ein Angreifer beispielsweise eine Zeichenfolge mit einem öffentlichen SSH-Schlüssel in seinen Code aufnehmen und einen symbolischen Link mit dem Namen a.out bis ~ / .ssh / autorisierte_Tasten . Wenn diese Datei noch nicht vorhanden ist, kann der Angreifer seinen SSH-Schlüssel in den Zielcomputer einfügen, sodass er von außen darauf zugreifen kann, ohne ein Kennwort knacken zu müssen.