it-swarm.com.de

Wie sicher ist es, einen Quellcode von einem zufälligen Fremden zu kompilieren?

Angenommen, ich überprüfe den Code, den Bewerber senden, um ihre Fähigkeiten unter Beweis zu stellen. Natürlich möchte ich keine ausführbaren Dateien ausführen, die sie senden. Nicht so klar, ich möchte lieber nicht das Ergebnis der Kompilierung ihres Codes ausführen (nur zum Beispiel Java erlaubt es, ausführbaren Code in Kommentaren zu verbergen ).

Was ist mit dem Kompilieren ihres Codes? Ich möchte Compiler-Warnungen, wenn überhaupt, aber was ist, wenn ihr Code einige clevere Zeichenfolgen enthält, die meinen Compiler ausnutzen und mein Compiler meinen Computer gefährdet?

Wenn ich nach "Compiler-Schwachstellen" suche, geht es bei den Treffern um Compiler-Optimierungen und Code-Emission und darum, ob der ausgegebene Code so sicher ist, wie es der ursprüngliche Quellcode beabsichtigt hatte.

Werden Compiler normalerweise validiert, um sicherzustellen, dass sie den Benutzercomputer beim Kompilieren eines cleveren Codes nicht gefährden? Wie sicher ist es, einen Code von einem Fremden zu kompilieren?

41
sharptooth

Es hängt davon ab, ob.

Dieses Makefile könnte Ihr Home-Verzeichnis löschen:

all:
    rm -rf ~

Wenn Sie also ein Tool (wie cmake oder makefile system) verwenden müssen, ist es nicht sicher. Es kommt nur darauf an, wie bösartig der Codierer ist.

Auf der anderen Seite werden Compiler von Leuten programmiert, daher haben sie Fehler. Vielleicht könnte jemand einen Weg gefunden haben, bösartigen Code während der Kompilierung auszuführen.

Verwenden Sie, wie in den Kommentaren vorgeschlagen, eine virtuelle Maschine, wenn Sie sicherstellen möchten, dass auf Ihrer Maschine keine lustigen Dinge geschehen.

34
BЈовић

Ich bin mir ziemlich sicher, dass es irgendwo im Geschäft einige clevere Leute gibt, die bereits einen solchen Hack für eine bestimmte Sprache und Compiler-Version erstellt haben. Mein Lieblingsort, um nach so etwas zu suchen, wäre wahrscheinlich der International Obfuscated C Contest - (weiß nicht, ob es etwas Vergleichbares für Java gibt). Wie hoch ist das Risiko in der Realität, wenn man davon ausgeht?

  • der Bewerber macht einen plausiblen Eindruck auf Sie. Er möchte wirklich den Job in Ihrem Unternehmen (und keine Klage).

  • der Typ weiß nicht, wie viel Überprüfung bei Ihnen durchgeführt wird

  • er/sie weiß nicht, welche genaue Compilerversion Sie verwenden

  • er/sie weiß nicht, ob Sie eine virtuelle Umgebung oder einen Online-Compiler verwenden, nur um sicher zu gehen

  • sie akzeptieren keine Programme, die zu groß sind, um effektiv überprüft zu werden

  • sie kompilieren nichts, was Ihnen verdächtig erscheint

  • es gibt nicht viele Menschen auf der Welt, die tatsächlich wissen, wie man eine solche Aufgabe technisch erledigt (und Googeln allein gibt Ihnen keine "schnelle Referenz" oder ein Tutorial dazu, wie Sie bereits selbst herausgefunden haben).

Obwohl das Kompilieren theoretisch nicht "absolut sicher" ist, ist IMHO in Wirklichkeit das Risiko extrem gering, dass Ihr "Compiler pwned wird".

23
Doc Brown

Wir müssen mehrere Fälle unterscheiden:

  1. Ein Fehler im Compiler. Wie jedes komplexe Programm kann ein Compiler Fehler aufweisen, und einer dieser Fehler kann ausgenutzt werden.
  2. Ein trojanisches Pferd. Der Angreifer kann Sie dazu bringen, im Rahmen des Kompilierungsprozesses beliebigen Code auszuführen. A Makefile, a build.xml, ein configure Shell-Skript usw. Technisch gesehen liegt dies nicht am Kompilieren des Code des Angreifers, sondern am Einrichten der Kompilierungsumgebung.
  3. Sprachen, in denen beliebiger Code zur Kompilierungszeit ausgeführt werden kann. Die Makrosprache von Scala ist Scala, die Makrosprache von Common LISP ist Common LISP, die Makrosprache von Template Haskell ist Haskell. Scala hat auch Compiler-Plugins, die wiederum willkürlich sind Scala Code, der zur Kompilierungszeit ausgeführt wird. F # hat Typanbieter.
  4. Sprachen, die Turing-Berechnungen zur Kompilierungszeit ermöglichen. Die Typsysteme von Scala und Haskell sind vollständig, ebenso wie die Vorlagen von C++. Sie können den Compiler veranlassen, zur Kompilierungszeit eine beliebige Turing-Berechnung durchzuführen, einschließlich, aber nicht beschränkt auf Endlosschleifen. Beachten Sie, dass Turing-complete nur bedeutet, dass Sie jede Turing-berechenbare Funktion berechnen können. Dies bedeutet nicht, dass Sie auf das Dateisystem oder ähnliches zugreifen können. Sie können jedoch ein Programm erstellen, dessen Kompilierung unendlich lange dauert.
  5. Sehr lange Kompilierzeiten. Beispielsweise sind die Regeln von C # für die Überlastungsauflösung so komplex, dass Sie jedes 3-SAT-Problem als C # -Überlastungsauflösung codieren können. 3-SAT ist natürlich bekanntermaßen NP-vollständig. Mit anderen Worten, nach unserem derzeitigen Kenntnisstand ist es unmöglich, einen effizienten Algorithmus für die Überlastungsauflösung in C # zu finden. Die Kompilierung kann nicht unendlich lange dauern, aber es ist kein großes Programm erforderlich, damit die Kompilierung länger dauert als die Lebensdauer des Universums, was praktisch dasselbe ist.

# 4. und # 5. wird höchstens zu einem Denial-of-Service führen. In der Praxis begrenzen C++ - und Scala - Compiler die Rekursionsmenge, die Sie ausführen können, so dass dies tatsächlich nicht möglich ist Schreiben Sie eine Endlosschleife. In Scala ist dies nur eine Implementierungsbeschränkung, aber in C++ ist dies meines Erachtens von der Spezifikation ausdrücklich erlaubt.

# 2. ist technisch nicht im Rahmen der Frage, da es um das Kompilieren von Code ging, der nicht ausgeführt wird (OTOH, es gibt die tiefe philosophische Frage: Wenn die Typprüfung eines Haskell-Programms eine beliebige Turing-Berechnung durchführen kann, ist das Kompilieren oder Ausführen eines Programms?)

# 1. ist unwahrscheinlich. Einerseits sind Produktions-Compiler sehr komplex, so dass die Wahrscheinlichkeit von Fehlern hoch ist. Auf der anderen Seite werden sie rigoros getestet, schließlich ist der ordnungsgemäße Umgang mit schlecht geformten Eingaben Teil der Jobbeschreibung eines Compilers. Selbst wenn sie nicht getestet werden, werden sie trotzdem mit schlecht geformtem Code bombardiert. Schauen Sie sich einfach einige StackOverflow-Fragen an, um Beispiele dafür zu finden, was Junk-Leute auf ihre Compiler werfen!

Dies lässt uns bei 3 zurück. Einige Compiler beschränken möglicherweise die Art des Zugriffs, den der Kompilierungszeitcode auf das System hat, aber in einigen Anwendungsfällen ist ein vollständiger Zugriff unvermeidbar. Der Zweck der Typanbieter von F # besteht beispielsweise darin, synthetische Typen für Daten zu "fälschen", deren Typsystem nicht mit denen von F # übereinstimmt, sodass Sie beispielsweise mit einem Webdienst interagieren können, der ein WSDL-Schema in einem stark typisierten Typ aufweist Mode. Zu diesem Zweck muss der Typanbieter jedoch entweder im Dateisystem oder im Web Zugriff auf die WSDL-Schemaressource haben, sodass er über Dateisystem- und Netzwerkzugriff verfügen muss.

Also ist es sicher? Technisch gesehen nein. Ist es riskant? Nicht wirklich.

13
Jörg W Mittag

Es sollte kein Risiko bestehen, nur Kompilieren den Code. In Theorie könnte es einen Fehler im Compiler geben, den ein cleverer Hacker ausnutzen könnte, der jedoch äußerst unwahrscheinlich klingt.

Beachten Sie, dass Gebäude möglicherweise unsicher ist. In C # können Sie mit 'build event' beispielsweise beliebige Befehlszeilen angeben, die vor und nach dem Erstellen ausgeführt werden sollen. Dies ist offensichtlich gefährlich und viel einfacher auszunutzen, als beispielsweise Pufferüberläufe im Compilercode.

3
JacquesB

Anstatt zu spekulieren, habe ich mich tatsächlich darum gekümmert, vor der Beantwortung einige Nachforschungen zu diesem Thema anzustellen und mich an die maßgeblichste Ressource zu wenden, die mir einfällt ( CVE Details ). Diese umfassende Liste öffentlich bekannt gegebener Sicherheits-Exploits ist wahrscheinlich das Beste, was man tun kann, um die Bedrohungsstufen verschiedener Softwaretypen zu bewerten.

Ich habe mir natürlich keine Zeit genommen, um alle des verfügbaren Materials zu lesen, aber ich habe einige "primäre" Compiler, IDEs und Texteditoren ausgewählt, um eine Beispiel-Bedrohungsbewertung zu erstellen. Wenn Sie es ernst meinen, überhaupt Software auszuführen, sollten Sie zumindest sehen, welche Bedrohungen es gibt. Beachten Sie auch, dass ältere Software im Allgemeinen fehlerhafter ist als neuere Software. Daher ist es ideal, die neueste Software auszuführen.

Zunächst können wir uns verschiedene Texteditoren ansehen. Es scheint, dass die besten Editoren die einfachsten sind. Vi, wenn Sie eine Linux-Shell verwenden, oder Notepad, wenn Sie unter Windows arbeiten. Etwas ohne Formatierungsfunktionen, ohne Analyse, nur einfache Anzeige von Daten und automatische Beendigung der Analyse, wenn sich ein einzelnes Zeichen außerhalb des aktuellen Codierungsschemas befindet. Sogar Notepad ++ hatte eine Handvoll Schwachstellen. Vermeiden Sie komplexe Inhalte, wenn Sie nicht vertrauenswürdige Dateien anzeigen.

Zweitens können wir uns IDEs ansehen. Wenn Sie die Datei in einer IDE öffnen möchten, sollten Sie sich bewusst sein, dass einige IDEs Fehler gemeldet haben. Anscheinend hat Visual Studio Exploits über den Erweiterungsmechanismus verfügbar, sodass das Öffnen einer Lösung problematisch sein kann. Durch das Vermeiden von IDEs wird eine ganze Reihe von Problemen zwischen Ihnen und dem nicht vertrauenswürdigen Code vermieden. Das Festhalten an VI scheint viel sicherer zu sein.

Drittens können wir uns die tatsächlichen Compiler ansehen. Ich habe ein paar davon durchsucht, darunter Adobe, Microsoft, Java und C/C++ von GNU, und festgestellt, dass im Allgemeinen Kompilieren Code (und sogar Erstellen, vorausgesetzt, keine benutzerdefinierte Make- Datei) ist relativ sicher, aber jeder dieser Compiler hat oder hatte Sicherheits-Exploits, die sich aus der tatsächlichen Ausführung der kompilierten Binärdateien ergeben könnten. Mit anderen Worten, sie konnten Ihr System nicht einfach durch Kompilieren übernehmen, sondern durch Ausführen von Code.

Angenommen, die Übermittlungsmethode hat Ihr System noch nicht entführt (z. B. Ihr E-Mail-Client wurde gehackt oder das USB-Laufwerk wurde infiziert ...), lautet das Lesen des Quellcodes und das Kompilieren des Quellcodes: wahrscheinlich sicher. Wenn Sie Ihre spezifische Software recherchieren, können Sie sie noch sicherer machen, indem Sie beispielsweise überprüfen, ob sich die Datei auf der richtigen Codepage usw. befindet. Das Ausführen des Codes sollte nur auf Hardware erfolgen, die Ihnen einfach egal ist. Keine VM, sondern ein ganz anderer Computer ohne Netzwerkzugriff und ohne vertrauliche Dateien oder externe Geräte. Selbst wenn Sie denken Sie den Code verstehen, zeigen einfache Untersuchungen, dass selbst Compiler Fehler aufweisen, die es einem versteckten Pufferüberlauf-Exploit ermöglichen könnten, sich von hinten zu schleichen und beliebigen Code auszuführen, aber nur, wenn Sie sich dafür entscheiden - run oder debug das Programm. Die tatsächliche Kompilierung sollte sicher sein.

3
phyrfox

Nun, ich würde mit "Überprüfung ihres Codes" beginnen. Warum muss der Code tatsächlich ausgeführt werden?

Abgesehen davon gibt es viele Online-Compiler, bei denen Sie einfach den Code eingeben und kompilieren und/oder ausführen können. Sie können dies zur Voraussetzung machen: Es wird in diesem und jenem Online-Compiler kompiliert.

Hier ist ein Beispiel für eine Seite mit Online-Compilern: Online-Compiler

Der Code für die Überprüfung eines Vorstellungsgesprächs sollte sowieso nicht so groß sein, dass Sie nicht verstehen, was los ist.

2
Pieter B

Werden Compiler normalerweise validiert, um sicherzustellen, dass sie den Benutzermaschinen beim Kompilieren eines cleveren Codes nicht stören?

Im Allgemeinen sind sie zu komplex und werden oft in Sprachen geschrieben, in denen es nicht praktikabel ist, diese Eigenschaft zu beweisen.

Möglicherweise nicht mit dieser speziellen Absicht, aber der Begriff der Fuzz-Test-Compiler ist zumindest bekannt ( LLVM kann sich jetzt selbst fuzz-testen ). Tests, die Eingaben abfangen sollen, die den Compiler aufgrund von Compilerfehlern zum Absturz bringen, führen dazu, dass auch ausnutzbare Fehler auftreten.

Natürlich müssten Sie prüfen, ob der spezifische Compiler, an dem Sie interessiert sind, getestet oder fuzz-getestet wurde, um mögliche Abstürze zu finden, und ob die so gefundenen Fehler tatsächlich behoben sind. Als Faustregel gilt: Wenn es zu Abstürzen kommt, die schlimmer sind als Ausnahmen, die nicht aus dem Speicher stammen, müssen Sie ohne weitere Untersuchung der Details eine ernsthafte Möglichkeit in Betracht ziehen, diese für Exploits zu nutzen.

Wie sicher ist es, einen Code von einem Fremden zu kompilieren?

Wie lang ist leider ein Stück Schnur. Im Prinzip kann die E-Mail Ihren E-Mail-Client ausnutzen, oder der Quellcode kann Ihren Texteditor oder cppcheck ausnutzen, bevor er überhaupt Ihren Compiler erreicht. Sebastians Vorschlag in Kommentaren, einen Online-Compiler zu verwenden, ist ziemlich gut, aber natürlich muss der Code in einer Form vorliegen, die der Compiler akzeptiert.

Jede Sprache oder jeder Compiler mit Funktionen zur Ausführung von allgemeinem Code zur Kompilierungszeit ist natürlich sehr verdächtig. C++ - Vorlagen sind funktional vollständig, haben jedoch keinen (beabsichtigten) Zugriff auf das System, sodass sie ein relativ geringes Risiko aufweisen. BЈовић erwähnt make als extrem risikoreich (da es den Code des Fremden ausführt, ist es nur so, dass der Code zufällig in der Sprache make geschrieben ist, nicht in C++). Wenn der Compiler system ausführt, befinden Sie sich im selben Boot. Früher habe ich mit einem Assembler gearbeitet, der, wenn ich mich recht erinnere, eine beliebige Ausführung von Code zur Kompilierungszeit durchführen kann. Es war für die Berechnung von Nachschlagetabellen gedacht, aber ich glaube, nichts hat Sie daran gehindert, Systemaufrufe zu tätigen.

In der Praxis , wenn der Code für mich in Ordnung aussieht und ich denke, ich verstehe ihn, dann würde ich es als äußerst risikoarm betrachten, ihn zu kompilieren, weitaus geringer Risiko als sagen "Surfen im Internet mit einem gesperrten Browser". Ich mache routinemäßig riskantere Dinge auf meiner Allzweckmaschine, aber viele davon würde ich nicht tun, z. in einem Virenlabor oder auf einem kritischen Server. Wenn der Code lustig aussieht oder offensichtlich verschleiert ist, riskiere ich möglicherweise nicht, ihn zu kompilieren, da er, abgesehen von dem Risiko, einen Exploit enthalten könnte, der im unlesbaren Müll versteckt ist, Müllcode ist. Hinterhältiger Code ist schwierig, aber möglich. Hinterhältiger Code, der die Maschine über einen Compiler-Exploit pwns, muss eine nicht triviale ausführbare Nutzlast enthalten, daher ist extrem äußerst schwierig.

Wenn Sie dies näher untersuchen möchten, fragen Sie die Leute, die Online-Compiler hosten. Wenn es ihnen dann nicht angetan wurde (es sei denn, Sie werden auf die NSA oder gleichwertig) aufmerksam), können Sie davon ausgehen, dass es Ihnen nicht angetan wird. Sie geben sich einige Mühe Das Ausführen des Compilers in einer geeigneten Sandbox ist möglicherweise aufwändiger als Sie möchten, aber sie können Ihnen möglicherweise zumindest mitteilen, wie oft diese Sandbox ihnen Probleme erspart.

2
Steve Jessop

Obwohl dies im Allgemeinen ein Problem darstellt, denke ich, dass das Problem aufgrund des Setups nicht vorhanden ist.

Der Antragsteller hat Ihnen einen Quellcode geschickt. Wie oder warum ist das passiert?

Natürlich gibt es nur drei Möglichkeiten:

  1. Sie haben dem Bewerber den Auftrag gegeben, ein bestimmtes (genau definiertes) Problem zu lösen, um seine Fähigkeiten zu bewerten.
  2. Der Antragsteller möchte etwas Cooles zeigen, das er geschrieben hat.
  3. Der Bewerber ist ein Idiot oder ein Spion oder eine anderweitig böswillige Person und nicht wirklich daran interessiert, eingestellt zu werden. Er hofft nur, dass Sie dumm genug sind, seinen Code auszuführen.

Über 2) und 3)

Das Hauptrisiko besteht in der Unterscheidung zwischen 2) und 3). Die Chancen stehen gut, dass wenn etwas, was er geschrieben hat, einen Blick wert ist, Sie entweder den Quellcode für online (von einer "neutralen" Quelle) erhalten können und mit dem Sie vielleicht sogar bereits vertraut sind. oder es ist etwas, das Sie eigentlich nicht wollen betrachten, weil Sie das geistige Eigentum eines Konkurrenten (ehemaligen Arbeitgebers) verletzen würden. Letzteres würde bedeuten, dass Sie diese Person sowieso nicht einstellen möchten.
Wenn Sie die Quelle online stellen können, tun Sie dies. Wenn Sie den Beitrag des Antragstellers zu einer bekannten Software (einschließlich proprietärer Software) anhand seines Namens irgendwo im Abspann überprüfen können, tun Sie dies.
In jedem anderen Fall ignorieren Sie einfach, was er Ihnen geschickt hat. Es lohnt sich entweder nicht, sich das anzuschauen, es ist illegal oder es besteht ein hohes Risiko.

Über 1)

Der Antragsteller hat Ihnen etwas geschickt, weil Sie ihm einen Auftrag gegeben haben. Wenn Sie über beliebige Kompetenzen verfügen (von denen ich annehme, dass Sie dies tun!), Können Sie für eine typische Programmieraufgabe (... die Sie selbst ausgewählt haben!) Feststellen, ob dies eine plausible Lösung ist Das sieht so aus, als würde es funktionieren, wenn man den Quellcode weniger als 30 Sekunden lang betrachtet (wahrscheinlicher 10 Sekunden).

Wenn Sie nicht sagen können, dass das Programm wahrscheinlich innerhalb von 30 Sekunden funktioniert (oder was es überhaupt tut), ist derjenige, der es geschrieben hat, nicht die Art von Person, die Sie einstellen möchten. Sie möchten Menschen, die Code schreiben, den andere Menschen verstehen und pflegen können. Sie wollen weder jemanden, der versucht, schlau auf Sie zu werden, noch jemanden, der regelmäßig den verschleierten C-Wettbewerb gewinnt. Es ist nicht einmal wichtig, ob das Programm funktioniert. Sobald eine andere Person den Code nicht verstehen kann, "funktioniert" er nie.
Wenn das Programm so aussieht, als würde es wahrscheinlich funktionieren, aber Sie finden alles, was "seltsam" aussieht (sagen wir Java Unicode-Escape-Sequenzen, C++ - Raw-String-Literale, Dinge, die aussehen) Trigraphen, was auch immer), behandeln die Aufgabe als "fehlgeschlagen", fahren mit dem nächsten Bewerber fort. Es ist nicht notwendig, in 99% aller Programme etwas Ähnliches aufzunehmen (und natürlich nicht in Ihrer Aufgabe - ich sollte hoffen). Wenn Sie also etwas "Seltsames" finden, ist der Bewerber nicht jemand, den Sie einstellen möchten.

Wenn der Code diese erste Triage besteht, möchten Sie möglicherweise weitere 2-3 Minuten damit verbringen, ihn genauer zu betrachten. Wenn Sie mit dem, was Sie danach sehen, immer noch zufrieden sind, können Sie es durch einen statischen Analysator laufen lassen und es in einer virtuellen Maschine mit einer hohen Warnstufe kompilieren.

Dies sollte zu Problemen führen, die Sie beim Lesen der Quelle möglicherweise übersehen haben (z. B. Aufrufen eines undefinierten Verhaltens oder Eingrenzen der Konvertierung).
Beim Kompilieren erfahren Sie in erster Linie, ob der Antragsteller über die erforderliche Sorgfalt und Liebe zum Detail verfügt, nicht so sehr, ob er über Programmierkenntnisse verfügt. Ähnlich wie Sie den Namen des Arbeitgebers korrekt in Ihre Bewerbung schreiben und Ihren Lebenslauf vor der Abgabe auf Rechtschreibprüfung prüfen, sollten Sie sicherstellen, dass der von Ihnen eingereichte Quellcode fehlerfrei (und vorzugsweise ohne Warnungen) kompiliert wird. Wenn jemand dies nicht tut, möchten Sie ihn nicht einstellen.

Das Risiko, dass an diesem Punkt böse Dinge passieren (Ausnutzung des Compilers nd Ausbruch aus der VM), ist vernachlässigbar, da Sie bereits eine Plausibilitätsprüfung für den Code durchgeführt haben. Das wird nicht passieren.

1
Damon

Quellcode lesen: absolut sicher. Quellcode kompilieren: absolut sicher. Kompilierte Binärdateien ausführen: Nun ... das hängt davon ab.

Beim Kompilieren liest nur der Computer den Quellcode und schreibt sein Äquivalent in binärer Form. Nach dem Kompilieren haben Sie nur zwei Dokumente: ein für Menschen lesbares und ein anderes für Computer lesbares. Wenn Sie den Computer nicht dazu bringen, das zweite Dokument zu lesen (dh auszuführen), wird nichts passieren.

0
gbjbaanb

Wenn Sie sich Sorgen machen, nehmen Sie einen älteren Computer (haben die meisten von uns nicht ein paar herumgesessen?), Installieren Sie die aktuelle Version von Linux und Compiler & c, kopieren Sie den Quellcode darauf, ziehen Sie das Netzwerkkabel ab (oder schalten Sie WLAN aus ) und kompilieren. Wenn etwas Böses passiert, wird es nichts anderes beeinflussen.

Führen Sie Malware im Makefile mit dem Flag -n (IIRC, RTMF) aus, um zu sehen, was sie tut, ohne sie tatsächlich auszuführen.

* Es sei denn natürlich, Ihr Programmierer hat die Malware so codiert, dass sie auf eine erneute Verbindung wartet. In diesem Fall müssen Sie jedoch a) den Computer löschen. und b) den Lebenslauf des Mannes an die NSA weiterleiten, weil er in der Geschäftswelt verschwendet ist :-)

0
jamesqf

Die Quintessenz ist, dass dort Risiko besteht. Das Risiko ist relativ gering, wie andere Antworten vermerken, aber es besteht ein Risiko. Das heißt, Sie müssen zwei Fragen stellen:

  1. Was kann ich tun, um das Risiko zu minimieren?
  2. Ist das Risiko hoch genug, dass es mich interessieren sollte?

Das zweite ist das, was Sie hier in dieser Frage postuliert haben, aber es ist der falsche Fokus für diesen speziellen Fall. Die Antwort auf die Risikominderung ist klar und leicht verfügbar: Kompilieren Sie den Code nicht auf Ihrem Computer. Sie haben zwei offensichtliche Möglichkeiten, es zu kompilieren, ohne Ihren Computer zu verwenden:

  1. Verwenden Sie eine virtuelle Maschine (wie @FlorianMargaine in den Kommentaren sofort hervorhob). Sie erstellen vor dem Kompilieren einfach einen Snapshot und stellen den Snapshot dann wieder her, wenn Sie fertig sind.
  2. Verwenden Sie einen gehosteten Dienst (z. B. einen Online-Compiler).

Diese Möglichkeiten zur Risikominderung sind so offensichtlich, billig und leicht zugänglich, dass es sich nicht lohnt, viel Zeit damit zu verbringen, zu analysieren, wie groß das Risiko ist. Mach einfach einen von ihnen und sei fertig damit.

0
jpmc26

Visual Studio warnt Sie tatsächlich, wenn Sie ein Projekt von einem nicht vertrauenswürdigen Speicherort aus öffnen (z. B. heruntergeladen oder Netzwerkfreigabe).

Ein Beispiel dafür, wie dies ausgenutzt werden könnte, wäre ein WPF-Projekt: Sie können auf .NET-Klassen aus XAML verweisen und IntelliSense bereitstellen. VS lädt und führt die referenzierten Klassen zur Entwurfszeit aus.

Das bedeutet, dass ein Angreifer eine böswillige DLL in das bin-Verzeichnis ablegen, den Quellcode durch einen nicht böswilligen ersetzen und zur Entwurfszeit die DLL] ausführen kann. Nach Ihrem ersten Build wird jede Die Spur der bösartigen Binärdatei ist verschwunden.

Obwohl der gesamte bereitgestellte Code "sauber" ist, ist der Compiler fehlerfrei und Sie können natürlich niemals eine bereitgestellte EXE-Datei manuell ausführen. Bösartiger Code kann dennoch im Hintergrund ausgeführt werden. (Um vor diesem bestimmten Angriff sicher zu sein, können Sie vor dem Öffnen der Lösung sicherstellen, dass sich KEINE Binärdateien im Verzeichnisbaum befinden. VS fordert Sie dann auf, die Lösung zu erstellen, bevor Sie IntelliSense zur Entwurfszeit bereitstellen.)

Ähnliche Vektoren existieren wahrscheinlich mit anderen Sprachen/Betriebssystemen.

0
Lukas Rieger