Wie prüft man die Arbeit eines Compilers?

[Osmoses]

Hallo!

Ich stelle mir die Frage was ein Compiler macht und wie sehr sich dies von dem unterscheidet was man denkt, dass er macht.

Du verstehst jetzt nur :confused: oder :freak: ?

Ok, dann zu einem Beispiel:
Ein Programm wird geschrieben - nichts Besonderes.

Sagen wir es kann Bilder anzeigen oder ich lese damit die Temperatur meiner CPU aus oder es ist ein FTP-Client.
Die Entwickler stehen auf Opensource und veröffentlichen neben dem Programm auch den Quellcode.

Zu 90% wird das Programm aber heruntergeladen und der Quellcode nicht beachtet.
Selbst wenn, dann fällt nichts auf - die Entwickler haben nichts falsch gemacht oder keine böse Absicht.

Jetzt gibt es eine andere Gruppe.
Diese Gruppe will Informationen sammeln und bietet einen bestimmten Compiler an.
Dieser baut in jedes Compilat eine kleine Backdoor ein.

:frown: :eek:

Also: Wie prüft man die Arbeit eines Compilers?

Eventuell spricht hier meine Paranoia und ich diese Frage ist einfach beantwortet - man entschuldige meine Unwissenheit in diesem Fall.

[sei laut]

Ein Compiler ist ein Übersetzer von menschenlesbarer Sprache in Maschinensprache.
Woher soll der Compiler nun wissen, wie und wo die Backdoor ins Programm einzubauen ist? An der falschen Stelle eingebaut produziert das Programm am Ende einen Fehler oder die Backdoor wird im schlimmsten Fall niemals ausgelöst.

Das müsste man in meinen Augen also speziell an den Quellcode anpassen - und dann kann man gleich den Quellcode manipulieren.
Eine Universal-Backdoor ist wohl der feuchte Traum eines jeden Geheimdienstes. ;D

[Osmoses]

Ein Compiler ist ein Übersetzer von menschenlesbarer Sprache in Maschinensprache.
Woher soll der Compiler nun wissen, wie und wo die Backdoor ins Programm einzubauen ist? An der falschen Stelle eingebaut produziert das Programm am Ende einen Fehler oder die Backdoor wird im schlimmsten Fall niemals ausgelöst.

Das müsste man in meinen Augen also speziell an den Quellcode anpassen - und dann kann man gleich den Quellcode manipulieren.
Eine Universal-Backdoor ist wohl der feuchte Traum eines jeden Geheimdienstes. ;D

Ich habe ja gemient, dass der Quellcode sauber ist. Aber der Compiler könnte doch ein Programm davorsetzen, welches als Backdoor fungiert und danach das eigentliche Programm starten.

[ESAD]

Ein Compiler ist ein Übersetzer von menschenlesbarer Sprache in Maschinensprache.
Woher soll der Compiler nun wissen, wie und wo die Backdoor ins Programm einzubauen ist? An der falschen Stelle eingebaut produziert das Programm am Ende einen Fehler oder die Backdoor wird im schlimmsten Fall niemals ausgelöst.

Das müsste man in meinen Augen also speziell an den Quellcode anpassen - und dann kann man gleich den Quellcode manipulieren.
Eine Universal-Backdoor ist wohl der feuchte Traum eines jeden Geheimdienstes. ;D

Naja warum nicht? Main methode muss vorhanden sein, methodencall dazu, thread damit aufmachen der einen Port aufmacht und darauf wartet shell commandos zu empfangen. So als primitivlösung.

[hell_bird]

Folgende Überlegungen von mir:

- Einfach zusätzlichen Code einbauen, der einen Port öffnet, auf Dateien zugreift, Threads erstellt etc ist zu offensichtlich: fast jeder, der ein Programm produziert testet es auch auf irgendeine Weise. Dazu gehört auch manchmal, dass man schaut welche Ressourcen das Programm benutzt oder mal mit dem Debugger hineinschaut

- Backdoors in die Standardbibliothek einer Sprache einzubauen würde gehen auch subtil als Programmierfehler getarnt: das hat aber meiner Meinung nach die gleiche Qualität und Konsequenzen wie ein Fehler im Betriebssystem... Hier kann man vor allem darauf hoffen, dass der Fehler frühzeitig auffällt, da er ja in jedem Programm präsent ist

- Der praxisfernste, aber interessanteste Fall ist wenn der Compiler Muster erkennt. Beispielsweise könnte eine Prüfung von Anmeldedaten erkannt werden und auch ein masterpasswort zugelassen werden. Man könnte sogar so weit gehen, dass der Compiler die Debugging und Monitoringtools beim compilieren in einer Weise verändert, dass sie das Backdoor nicht mehr aufspühren können. Der Compilerquellcode muss den Backdoor nicht einmal enthalten, sondern das wird immer eingefügt, wenn der Compiler sich selbst baut. Dem kann man dann nur auf die Schliche kommen, wenn man einen zweiten unabhängigen Compiler zur Hand hat.

[sei laut]

Ich habe ja gemient, dass der Quellcode sauber ist. Aber der Compiler könnte doch ein Programm davorsetzen, welches als Backdoor fungiert und danach das eigentliche Programm starten.
Naja warum nicht? Main methode muss vorhanden sein, methodencall dazu, thread damit aufmachen der einen Port aufmacht und darauf wartet shell commandos zu empfangen. So als primitivlösung.
Gings hier nicht um eine Hintertür? Also etwas, was man nicht sofort sieht. Etwas unauffälliges.
Sowas ist für mich keine Backdoor.

Aber ich gebe zu, meine Ausführung war zu kurz gedacht (wie hell_birds Post beweist), vielleicht will ich es auch nur nicht wahrhaben. :D

[lumines]

Viel interessanter ist dabei doch die Frage, wie man zuverlässig prüfen kann, ob ein Programm wirklich aus dem vorliegenden Quellcode kompiliert wurde, wenn man es als Binary einfach so installiert und nicht selbst aus dem Quellcode übersetzt hat.

Man könnte annehmen, dass ein Compiler mit dem selben Quellcode immer das genau gleiche Programm erzeugt. Aber schon kleine Versionsunterschiede bei bestimmten Libraries oder besondere Flags können das zunichte machen. Man kann dann ja schon nicht mehr mit z.B. Hashes überprüfen, ob nicht jemand vor dem Kompilieren den Quellcode doch noch ein bisschen modifiziert hat. Das muss nicht einmal am Compiler liegen.

Dass jemand den Compiler selbst unterwandert, halte ich für weniger wahrscheinlich, als dass jemand Open Source Programme als Binary in einer „modifizierten“ und vielleicht auch schädlichen Version verteilt.

Aber das könnte man natürlich auch auf den Compiler anwenden. Compiler-Suites wie der GCC müssen ja auch erst einmal kompiliert werden. Wer sagt mir also, dass der GCC in z.B. Debian wirklich der GCC ist, den sie dann wieder als Source Code in ihrem Repo anbieten?

[tomvos]

Hallo!

…

Also: Wie prüft man die Arbeit eines Compilers?



Die Frage hat sich bereits Ken Thompson (http://de.wikipedia.org/wiki/Ken_Thompson) gestellt. Hier ist der Link zu dem Artikel.

http://cm.bell-labs.com/who/ken/trust.html

Die Zusammenfassung: Du kannst einem Compiler nur dann trauen, falls dieser zu 100% von dir oder einer vertrauenswürdigen anderen Partei geprüft wurde.

In der Praxis begnügt man sich oft mit dem Nachweis, dass sich aus den Sourcen und genau spezifizierten Libraries sowie einem bestimmten Compiler bzw. bestimmter Build Umgebung eine Anwendung zusammenbauen lässt, welche z.B. mit MD5 die gleichen Checksummen liefert.

[Ganon]

Also: Wie prüft man die Arbeit eines Compilers?

In kurz: Gar nicht.

Man vergleicht im allgemeinen nur "das was das zu compilierende Programm ausspucken soll" mit dem "was das Programm ausspuckt". Es dürfte praktisch unmöglich sein für jeden Flag des Compilers den entsprechenden Assembler-Code anzugeben, der rauskommen soll, für jedes Testprogramm auf jeder unterstützten Architektur.

Aber wenn deine Paranoia schon so weit geht, dann darfst du deiner Hardware auch nicht vertrauen. Dem Microcode in der CPU, der Firmware auf deiner Netzwerkkarte oder dem BIOS deiner Grafikkarte.

Aber eine Backdoor wie "ich mache Port 64000 auf", dürfte recht schnell auffallen. Denkbarer wäre eher sowas wie "ich erlaube einen Buffer-Overflow". Da aber von Version zu Version an den Codegeneratoren und Stack-Protektoren gearbeitet wird, dürfte sowas bei einem OpenSource-Projekt schon recht schnell auffallen.

Da sind so Lücken wie Heartbleed deutlich einfacher unterzubringen.