Wie sicher ist es, einen Quelltext von einem zufälligen Fremden zu kompilieren? [geschlossen]

Angenommen, ich überprüfe den Code, den Bewerber senden, um ihre Fähigkeiten zu beweisen. Natürlich möchte ich keine ausführbaren Dateien ausführen, die sie senden. Nicht so klar, dass ich das Ergebnis der Codekompilierung lieber nicht ausführen möchte (nur zum Beispiel erlaubt Java, ausführbaren Code in Kommentaren auszublenden ).

Was ist mit dem Kompilieren ihres Codes? Ich möchte Compiler-Warnungen, aber was ist, wenn ihr Code einige clevere Zeichenfolgen enthält, die meinen Compiler ausnutzen und meinen Compiler meinen Rechner kompromittieren?

Wenn ich nach "Compiler-Schwachstellen" google, dreht sich alles um Compiler-Optimierungen und Code-Emission und darum, ob der ausgegebene Code so sicher ist, wie der ursprüngliche Quellcode es sein sollte.

Werden Compiler in der Regel überprüft, um sicherzustellen, dass sie den Benutzercomputer beim Kompilieren eines cleveren Codeteils nicht gefährden? Wie sicher ist es, einen Code von einem Fremden zu kompilieren?

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 hat jemand während der Kompilierung einen Weg gefunden, um bösartigen Code auszuführen.

Verwenden Sie, wie in den Kommentaren vorgeschlagen, eine virtuelle Maschine, wenn Sie sicherstellen möchten, dass auf Ihrem Computer keine lustigen Aktionen ausgeführt werden.

Ich bin mir ziemlich sicher, dass es irgendwo im Geschäft einige clevere Typen gibt, die bereits einen solchen Hack für eine bestimmte Sprach- und Compilerversion erstellt haben. Mein Lieblingsort für so etwas wäre wahrscheinlich der International Obfuscated C Contest (ich weiß nicht, ob es etwas Vergleichbares für Java gibt). Wie hoch schätzen Sie das Risiko in der Realität ein?

• 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 das Googeln allein gibt Ihnen keine "schnelle Referenz" oder ein Tutorial dazu, wie Sie bereits selbst herausgefunden haben).

Obwohl das Kompilieren in der Theorie nicht "absolut sicher" ist, ist das Risiko, dass Ihr "Compiler pwned" wird, meiner Meinung nach extrem gering.

Wir müssen mehrere Fälle unterscheiden:

1. Ein Fehler im Compiler. Wie jedes komplexe Programm kann ein Compiler Fehler aufweisen, von denen einer ausgenutzt werden kann.
2. Ein trojanisches Pferd. Der Angreifer fordert Sie möglicherweise auf, im Rahmen des Kompilierungsvorgangs einen beliebigen Code auszuführen. A Makefile, a build.xml, ein configureShell-Skript usw. Technisch ist dies nicht auf das Kompilieren des Angreifer-Codes zurückzuführen, sondern auf das 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 verfügt auch über Compiler-Plugins, die wiederum beliebigen Scala-Code darstellen, der zur Kompilierungszeit ausgeführt wird. F # hat Typanbieter.
4. Sprachen, die eine Turing-Berechnung zur Kompilierungszeit ermöglichen. Die Typensysteme von Scala und Haskell sind ebenso wie die Templates von C ++ Turing-vollständig. 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 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. Sie können das Kompilieren nicht unendlich lange dauern lassen, aber es ist kein großes Programm erforderlich, um das Kompilieren länger als die Lebensdauer des Universums in Anspruch zu nehmen, was praktisch dasselbe ist.

# 4. und # 5. wird höchstens zu einer Dienstverweigerung führen. Praktisch begrenzen C ++ und Scala Compiler die Menge der Rekursion Sie tun können, so dass es nicht wirklich möglich , eine Endlosschleife zu schreiben. In Scala ist dies nur eine Implementierungsbeschränkung, aber in C ++ ist dies meiner Meinung nach in der Spezifikation explizit zulässig.

# 2. ist technisch nicht erfassbar, da die Frage lautete, ob Code kompiliert werden soll, ohne dass er ausgeführt wird.

# 1. ist unwahrscheinlich. Einerseits sind Produktionscompiler sehr komplex, sodass die Wahrscheinlichkeit von Fehlern hoch ist. Auf der anderen Seite werden sie rigoros getestet, schließlich gehört es zur Aufgabenbeschreibung eines Compilers, mit falsch geformten Eingaben angemessen umzugehen. Selbst wenn sie nicht getestet werden, werden sie ohnehin 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 mit 3 zurück. Einige Compiler beschränken möglicherweise die Art des Zugriffs, den der Compile-Zeitcode auf das System hat, aber für einige Anwendungsfälle ist ein vollständiger Zugriff unvermeidlich. Der Zweck der Typanbieter von F # besteht beispielsweise darin, synthetische Typen für Daten zu "fälschen", deren Typsystem nicht mit den von F # übereinstimmt, damit Sie beispielsweise mit einem Webdienst interagieren können, der ein WSDL-Schema in einem stark typisierten Typ hat Mode. Dazu muss der Typanbieter jedoch Zugriff auf die WSDL-Schemaressource haben, entweder im Dateisystem oder im Web. Daher muss er über Dateisystem- und Netzwerkzugriff verfügen.

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

Es sollte kein Risiko bestehen, nur den Code zu kompilieren . In der Theorie könnte es ein Fehler in dem Compiler sein , dass ein kluger Hacker ausnutzen könnte , ist aber äußerst unwahrscheinlich klingt.

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

Anstatt zu spekulieren, habe ich mich vor der Beantwortung damit beschäftigt, einige Nachforschungen zu diesem Thema anzustellen und die maßgeblichste Ressource aufzusuchen, die mir in den Sinn kam ( CVE-Details ). Diese umfassende Liste von öffentlich bekannt gegebenen Sicherheitslücken ist wahrscheinlich das Beste, was man tun kann, um die Bedrohungsstufe verschiedener Softwaretypen zu bewerten.

Ich habe mir natürlich nicht die Zeit genommen, das gesamte verfügbare Material zu lesen , aber ich habe einige "primäre" Compiler, IDEs und Texteditoren ausgewählt, um eine Beispielbewertung der Bedrohung zu erstellen. Wenn Sie es ernst meinen mit Software, sollten Sie zumindest nachsehen, welche Bedrohungen es gibt. Beachten Sie auch, dass ältere Software in der Regel fehlerhafter ist als neuere. Daher ist es ideal, immer die neueste Software zu verwenden.

Zunächst können wir uns verschiedene Texteditoren ansehen. Es scheint, dass die besten Redakteure die einfachsten sind. Vi, wenn Sie eine Linux-Shell verwenden, oder Notepad, wenn Sie sich in Windows befinden. Etwas ohne Formatierungsmöglichkeiten, ohne Parsing, nur mit direkter Anzeige der Daten und automatischem Abbruch des Parsings, wenn sich ein einzelnes Zeichen außerhalb des aktuellen Codierungsschemas befindet. Sogar Notepad ++ hatte eine Handvoll Schwachstellen. Vermeiden Sie komplexe Vorgänge beim Anzeigen nicht vertrauenswürdiger Dateien.

Zweitens können wir IDEs betrachten. Wenn Sie die Datei in einer IDE öffnen möchten, sollten Sie wissen, dass einige IDEs Fehler gemeldet haben. Anscheinend hatte Visual Studio Exploits über den Erweiterungsmechanismus, sodass das Öffnen einer Lösung problematisch sein könnte. Das Vermeiden von IDEs vermeidet eine ganze Reihe von Problemen zwischen Ihnen und dem nicht vertrauenswürdigen Code. Sich an VI zu halten 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 GNU C / C ++, und festgestellt, dass das Kompilieren von Code (und sogar das Erstellen , vorausgesetzt, dass keine benutzerdefinierte Make-Datei vorhanden ist) im Allgemeinen relativ sicher ist, aber jeder dieser Compiler funktioniert oder funktioniert Sicherheitslücken, die durch das Ausführen der kompilierten Binärdateien entstehen können. Mit anderen Worten, sie konnten Ihr System nicht einfach durch Kompilieren übernehmen, sondern durch Ausführen von Code.

Angenommen, die Übermittlungsmethode hat Ihr System nicht bereits überfallen (z. B. Ihr E-Mail-Client wurde gehackt oder das USB-Laufwerk wurde infiziert ...), ist es wahrscheinlich sicher , den Quellcode zu lesen und den Quellcode zu kompilieren . Indem Sie nach Ihrer spezifischen Software suchen, können Sie sie noch sicherer machen, indem Sie beispielsweise überprüfen, ob sich die Datei auf der richtigen Codepage befindet usw. Das Ausführen des Codes sollte nur auf Hardware erfolgen, die Sie einfach nicht interessieren. Keine VM, sondern ein ganz anderer Computer ohne Netzwerkzugriff und ohne vertrauliche Dateien oder externe Geräte. Selbst wenn Sie glauben , den Code zu verstehen, zeigen einfache Untersuchungen, dass sogar Compiler Fehler aufweisen, die es einem versteckten Pufferüberlauf ermöglichen, sich von hinten zu schleichen und beliebigen Code auszuführen, aber nur, wenn Sie dies möchtenFühren Sie das Programm aus, oder debuggen Sie es . Die tatsächliche Kompilierung sollte sicher sein.

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 den Code einfach eingeben und kompilieren und / oder ausführen können. Sie können dies zu einer Anforderung 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.

Werden Compiler in der Regel überprüft, um sicherzustellen, dass sie den Benutzercomputer beim Kompilieren eines cleveren Codeteils nicht beschädigen?

Im Allgemeinen sind sie zu komplex und werden oft in Sprachen geschrieben, in denen es nicht praktisch 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 auf Fuzz testen ). Tests sollen Fang Eingang, der den Compiler aufgrund Compiler - Fehler abstürzt wird dazu neigen , auch verwertbare Fehler auftauchen.

Natürlich müssten Sie prüfen, ob der spezielle Compiler, an dem Sie interessiert sind, getestet oder fuzzgetestet ist, 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 aufgrund fehlenden Arbeitsspeichers, dann müssen Sie, ohne die Details weiter zu untersuchen, eine ernsthafte Möglichkeit in Betracht ziehen, dass sie zu Exploits führen können.

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

Leider, wie lang ist 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 akzeptieren wird.

Jede Sprache oder jeder Compiler, der die Möglichkeit hat, allgemeinen Code zur Kompilierungszeit auszuführen, 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 makeals extrem risikoreich (da es den Code des Fremden ausführt, ist es nur, dass der Code in der makeSprache geschrieben ist, nicht in C ++). Wenn der Compiler ausgeführt wird, befinden systemSie sich im selben Boot. Ich habe mit einem Assembler gearbeitet, der, wenn ich mich recht erinnere, eine beliebige Ausführung von Code zur Kompilierungszeit ausführen konnte. 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, dass ich ihn verstehe, würde ich das Risiko, ihn zu kompilieren, als äußerst gering einschätzen. Ich mache routinemäßig riskantere Dinge auf meinem Allzweckcomputer, aber viele davon würde ich nicht tun, z. B. in einem Virenlabor oder auf einem kritischen Server. Wenn der Code komisch 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. Verdeckter Code, der den Computer über einen Compiler-Exploit pwnt, muss eine nicht triviale ausführbare Nutzlast enthalten, was äußerst schwierig ist.

Wenn Sie dies weiter untersuchen möchten, fragen Sie die Leute, die Online-Compiler hosten. Wenn es ihnen nicht angetan wurde (es sei denn, Sie werden von der NSA oder einer vergleichbaren Behörde darauf hingewiesen), können Sie davon ausgehen, dass es Ihnen nicht angetan wird. Sie geben sich etwas Mühe, ihren Compiler in einer richtigen Sandbox auszuführen, was möglicherweise mehr Aufwand bedeutet, als Sie bereit sind, aber sie können Ihnen möglicherweise zumindest mitteilen, wie oft diese Sandbox ihnen Probleme erspart.

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

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

Nun, offensichtlich 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 beurteilen.
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 eigentlich nicht daran interessiert, eingestellt zu werden. Er hofft nur, dass Sie so dumm sind, seinen Code auszuführen.

Über 2) und 3)

Das Hauptrisiko besteht in der Unterscheidung zwischen 2) und 3). Die Chancen stehen gut, dass Sie, wenn etwas, das er geschrieben hat, einen Blick wert ist, entweder den Quellcode für das Internet (von einer "neutralen" Quelle) erhalten und vielleicht sogar bereits kennen oder ihn tatsächlich nicht verwenden Ich möchte nicht darauf achten, dass Sie das geistige Eigentum eines Konkurrenten (des ehemaligen Arbeitgebers) verletzen. Letzteres würde bedeuten, dass Sie diese Person sowieso nicht einstellen möchten.
Wenn Sie die Quelle online erhalten können, tun Sie dies. Wenn Sie den Beitrag des Antragstellers zu einer bekannten Software (einschließlich proprietärer Software) anhand seines Namens in den Credits überprüfen können, tun Sie dies.
Ignorieren Sie in jedem anderen Fall einfach alles, was er Ihnen geschickt hat. Entweder lohnt es sich nicht, sie anzuschauen, oder sie ist illegal oder birgt ein hohes Risiko.

Über 1)

Der Bewerber hat Ihnen etwas geschickt, weil Sie ihm einen Auftrag gegeben haben. Wenn Sie eine Kompetenz haben (von der ich annehme, dass Sie sie haben!), Dann können Sie für einen typischen Programmierauftrag (... den Sie sich selbst ausgesucht haben!) Feststellen, ob es sich um eine plausible Lösung handelt, die so aussieht, als ob sie funktionieren könnte durch weniger als 30 Sekunden langes Betrachten des Quellcodes (wahrscheinlicher 10 Sekunden).

Wenn Sie nicht sagen können, dass das Programm wahrscheinlich innerhalb von 30 Sekunden funktioniert (oder was es überhaupt tut), wird derjenige, der es geschrieben hat, nicht die Person sein, 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, sich schlau zu machen, noch jemanden, der regelmäßig den verschleierten C-Wettbewerb gewinnt. Es spielt keine Rolle, 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 (z. B. Java-Unicode-Escape-Sequenzen, C ++ - Zeichenfolgenliterale, Dinge, die wie Trigraphen aussehen, was auch immer), behandeln Sie die Zuweisung als "fehlgeschlagen", verschieben Sie sie weiter zum nächsten Bewerber. Es ist nicht notwendig, in 99% aller Programme etwas Ähnliches aufzunehmen (und natürlich nicht in Ihrem Auftrag - das sollte ich hoffen). Wenn Sie also etwas "Seltsames" finden, ist der Bewerber nicht jemand, den Sie einstellen möchten.

Wenn der Code diese erste Prüfung besteht, sollten Sie sich noch 2-3 Minuten länger damit befassen. Wenn Sie mit dem, was danach angezeigt wird, immer noch zufrieden sind, können Sie es über einen statischen Analysator ausführen und in einer virtuellen Maschine mit einer hohen Warnstufe kompilieren.

Dies sollte Probleme aufwerfen, die Sie beim Lesen der Quelle möglicherweise übersehen haben (z. B. Aufrufen von undefiniertem Verhalten oder Eingrenzen der Konvertierung).
Beim Kompilieren erfahren Sie in erster Linie, ob der Bewerber ü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 Einreichung überprüfen, sollten Sie sicherstellen, dass der Quellcode, den Sie einreichen, fehlerfrei (und vorzugsweise ohne Warnungen) kompiliert wird. Wenn das jemand nicht tut, möchten Sie ihn nicht einstellen.

Das Risiko, dass zu diesem Zeitpunkt böse Dinge passieren (Ausnutzen des Compilers und Herausbrechen der VM), ist vernachlässigbar, da Sie bereits eine Plausibilitätsprüfung des Codes durchgeführt haben. Das wird nicht passieren.

Wenn die Möglichkeit Sie beunruhigt, nehmen Sie einen älteren Computer (haben die meisten von uns keine Probleme?), Installieren Sie die aktuelle Version von Linux und Compiler & c, kopieren Sie den Quellcode darauf, ziehen Sie das Netzwerkkabel ab (oder deaktivieren Sie WiFi) ) und kompiliere. Wenn etwas Schlimmes passiert, wird es nichts anderes beeinflussen.

Und für Malware im Makefile führen Sie es mit dem Flag -n (IIRC, RTMF) aus, um zu sehen, wie es funktioniert, ohne es tatsächlich zu tun.

* Es sei denn, 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) leite den Lebenslauf des Typen an die NSA weiter, weil er in der Geschäftswelt verschwendet ist :-)

Unterm Strich ist , dass es ist Risiko. Das Risiko ist ziemlich gering, wie andere Antworten bemerken, aber es gibt ein Risiko. Das bedeutet, dass Sie zwei Fragen stellen müssen:

1. Was kann ich tun, um das Risiko zu verringern?
2. Ist das Risiko hoch genug, dass es mich kümmern sollte?

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

1. Verwenden Sie eine virtuelle Maschine (wie @FlorianMargaine in den Kommentaren sofort betonte). Sie erstellen einfach einen Snapshot, bevor Sie ihn kompilieren, und stellen den Snapshot 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 hoch das Risiko ist. Tu einfach einen von ihnen und sei fertig damit.

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

Ein Beispiel, wie dies ausgenutzt werden könnte, wäre ein WPF-Projekt: Sie können auf .NET-Klassen aus XAML verweisen und IntelliSense, VS, die referenzierten Klassen zur Entwurfszeit laden und ausführen.

Das bedeutet, dass ein Angreifer eine schädliche DLL in das Verzeichnis bin ablegen, den Quellcode durch eine nicht schädliche DLL ersetzen und zur Entwurfszeit die DLL ausführen kann. Nach Ihrem ersten Build ist jede Spur der schädlichen Binärdatei 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. Der schädliche Code kann dennoch im Hintergrund ausgeführt werden. (Um vor diesem Angriff sicher zu sein, müssen Sie lediglich sicherstellen, dass der Verzeichnisbaum KEINE Binärdateien enthält, bevor Sie die Lösung öffnen. VS fordert Sie dann auf, die Lösung zu erstellen, bevor Sie IntelliSense zur Entwurfszeit bereitstellen.)

Ähnliche Vektoren existieren wahrscheinlich mit anderen Sprachen / Betriebssystemen.

Quellcode lesen: absolut sicher. Quellcode kompilieren: absolut sicher. Kompilierte Binaries ausführen: na ja ... das kommt drauf an.

Kompilieren ist nur der Computer, der den Quellcode liest und sein Äquivalent in binärer Form schreibt. Nach der Kompilierung haben Sie nur zwei Dokumente: eines für Menschen lesbar und eines für Computer lesbar. Solange Sie den Computer nicht dazu bringen, das zweite Dokument zu lesen (dh auszuführen), geschieht nichts.

Ich denke, Sie sind besorgt über eine von zwei Varianten:

• Ausgefeilte, von Exploits getriebene Malware : Unwahrscheinlich, insbesondere, weil diese auf sehr spezifische Hardware und / oder Software abzielt und Ihr Angreifer (basierend auf Ihrer Frage) wahrscheinlich nicht über diese Systemkenntnisse verfügt.
• Dinge, die sich in Ihre Umgebung einfügen: böswillige Streiche (z. B. Löschen Ihres Home-Verzeichnisses) oder rücksichtslose / inkompetente Anweisungen, die Ihr Systemverhalten ändern (z. B. Umschreiben von PATH- oder LIBRARY-Umgebungsvariablen)

Einige Leute haben virtuelle Maschinen oder alte Systeme vorgeschlagen, aber ich biete eine viel einfachere Lösung an: Kompilieren Sie als ein anderer Benutzer mit reduzierten / unterschiedlichen Berechtigungen . Viel einfacher als das Einrichten einer virtuellen Maschine oder eines dedizierten Computers.

Wenn es unwahrscheinlich ist, dass Ihr System von Exploits während der Kompilierung heimgesucht wird, stellen Sie es von Backups wieder her (Sie haben diese, oder?).