pyc-Datei als CGI-Skript ausführbar?

[numerix]

Kleine Anfängerfrage:

Lassen sich Bytecode-Dateien auch via CGI ausführen?

Meine Experimente waren da nämlich nicht erfolgreich. Das entsprechende py-Skript läuft, der Handler ist via .htaccess auf .py und .pyc eingestellt, das entsprechende pyc-File liefert aber statt des erwünschten Verhaltens nur eine Fehlermeldung.

Habe ich mich hier einfach nur dumm angestellt, oder geht das gar nicht bzw. anders als gedacht?

[BlackJack]

Kommt auf's Betriebssystem an. Unter Ubuntu ist der Kernel darauf vorbereitet `pyc`\s "direkt" auszuführen, wenn sie das "executable bit" gesetzt haben, da sollte das also gehen. Ansonsten müsste man ein Shell-Skript schreiben können, welches das `pyc` an den Interpreter verfüttert.

[Leonidas]

Da könnte man versuchen mit dem Kernel Binary Support für "misc" was zu machen und mal sehen wie Ubuntu das macht. Vermutlich genau so.

[numerix]

Danke für eure Hinweise.

Verstanden habe ich jetzt, dass ich es bisher nicht verstanden hatte.

Ich hatte es mir so vorgestellt: Wir ein py-Skript gestartet mit der entsprechenden Anweisung #! ... in der 1. Zeile, dann ruft es beim Start den py-Interpreter auf, der dann wiederum das py-Skript aufruft und ausführt. Lokal - also ohne CGI - ist es dem py-Interpreter egal, ob er ein py- oder ein pyc-File bekommt.

Gemäß dieser Vorstellung hat es aus meiner (falschen) Sicht auch keinen Unterschied gemacht, ob ich per CGI ein py-File oder ein pyc-File ausführen will.

Wenn ich es jetzt nicht wieder falsch verstanden habe, könnte man es kurz so zusammenfassen:

pyc-Files können in der Regel nicht ohne weiteres per CGI ausgeführt werden. Hat man Glück, dann ist das Betriebssystem(!?), mit dem der Webserver betrieben wird, so eingestellt, dass auch pyc-Files ausgeführt werden. Richtig?

[Leonidas]

Ich hatte es mir so vorgestellt: Wir ein py-Skript gestartet mit der entsprechenden Anweisung #! ... in der 1. Zeile, dann ruft es beim Start den py-Interpreter auf, der dann wiederum das py-Skript aufruft und ausführt. Lokal - also ohne CGI - ist es dem py-Interpreter egal, ob er ein py- oder ein pyc-File bekommt.

Gemäß dieser Vorstellung hat es aus meiner (falschen) Sicht auch keinen Unterschied gemacht, ob ich per CGI ein py-File oder ein pyc-File ausführen will.

Es ist so: wenn du im Webserver ein CGI-Skript ausführen willst, dann ist das analog dazu als wie wenn du es via ``./skriptname`` starten würdest. Also muss das Execute-Bit gesetzt sein. Wenn es eine ELF-Datei ist, dann kann die ausführbare Datei direkt ausgeführt werden, wenn der Kernel das unterstützt (tut jeder Linux-Kernel), wenn es eine a.out-Datei ist dann kann die ausgeführt werden, wenn der Kernel das entsprechende Modul geladen/einkompiliert hat. Wenn nun aber die Datei weder noch ist, dann wird der Kernel-Support für Misc-Binaries ausprobiert (etwa um Java-bytecode auszuführen oder Win32PE-Dateien mit .NET-Code). Wenn das nicht tut, dann wird die erste Zeile der Datei bis zum ersten ``\n`` gelesen und der Befehl nach dem ``#!`` ausgeführt (Shebang). Nun hat Python-Code so eine Shebang, Python-Bytecode hingegen nicht, kann also auf diese Weise nicht ausgeführt werden. Also muss man es über den Misc-Binary-Support des Kernels versuchen.

Eine alternative die ich mal in einem anderen HTTPd gesehen habe, ist für alle *.py[co]-Dateien immer den Python-Interpreter mit der Datei als Parameter auszuführen. Das geht natürlich auch.

[sma]

Zur Not könnte man sich vielleicht ein kleines Script bauen. Eine .pyc-Datei kann man mit marshal.load() ab Byte 9 laden. Man braucht also ein normales Script, welches die ersten 8 Bytes überspringt, dann das enthaltene Code-Objekt lädt und ausführt.

Ungetestet:

Code: Alles auswählen

#!/usr/bin/python

import sys, marshal
exec marshal.load(read(sys.argv[0])[8:])

Stefan

[jens]

Auch wenn die Thematik Interessant ist: Die Frage ist doch eigentlich, warum überhaupt das ganze so machen? Ist es eines von diesen "Ich will mein Code nicht raus geben" Problem?

[numerix]

Auch wenn die Thematik Interessant ist: Die Frage ist doch eigentlich, warum überhaupt das ganze so machen? Ist es eines von diesen "Ich will mein Code nicht raus geben" Problem?

So in der Art, wobei es mir mehr um Sicherheitsaspekte geht. Dahinter steckt ungefähr der folgende Fragenkomplex:

Wie schwer ist es z.B. ein via CGI ausgeführtes py-Skript, das z.B. zur Auswertung eines Formulars verwendet wird, vom Webserver herunterzuladen, obwohl der Betreiber der Website dies nicht möchte? Ist das - für einen Normalsterblichen - nahezu unmöglich, dann wäre der Einsatz von pyc-Dateien für mich uninteressant. Wäre das nicht sonderlich schwierig, dann wäre mir eine pyc-Datei lieber.

Irgendwo habe ich allerdings auch gelesen, dass man auch aus einer pyc-Datei den Quellcode mehr oder weniger wieder rekonstruieren kann. Aber auch hier weiß ich nicht, wie schwer das ist, ob es z.B. kursierende Tools gibt, die das mehr oder weniger zuverlässig erledigen usw.

[jens]

Pack einfach eine .htaccess dabei, die könnte z.B. so aussehen:

Code: Alles auswählen

# http://httpd.apache.org/docs/2.0/mod/mod_mime.html#addhandler
AddHandler cgi-script .cgi

# http://httpd.apache.org/docs/2.2/mod/core.html#files
<Files ~ "\.(py|pyc|pyo)$">
    Deny from all
</Files>

Deine "Startdatei" sollte dann *.cgi Enden. Somit dürften all anderen Dateien tabu sein...


pyc decompiler gibt es schon. Kosten aber teilweise Geld und funktionieren wohl nur für ältere Python Versionen... Dennoch könnte in pyc Dateien evtl. wichtige Daten zu sehen sein...

[Leonidas]

Wie schwer ist es z.B. ein via CGI ausgeführtes py-Skript, das z.B. zur Auswertung eines Formulars verwendet wird, vom Webserver herunterzuladen, obwohl der Betreiber der Website dies nicht möchte? Ist das - für einen Normalsterblichen - nahezu unmöglich, dann wäre der Einsatz von pyc-Dateien für mich uninteressant. Wäre das nicht sonderlich schwierig, dann wäre mir eine pyc-Datei lieber.

Hmm, so ziemlich unmöglich. Der einzige Fall wo der Code sichtbar ist, ist dann wenn der Server falsch konfiguriert ist und statt das auszuführen den Code anzeigt.

Irgendwo habe ich allerdings auch gelesen, dass man auch aus einer pyc-Datei den Quellcode mehr oder weniger wieder rekonstruieren kann. Aber auch hier weiß ich nicht, wie schwer das ist, ob es z.B. kursierende Tools gibt, die das mehr oder weniger zuverlässig erledigen usw.

Ist recht einfach - kein Schutz.

Eine andere Möglichkeit ist auch, ein *.py-Skript davorzuschalten, welches das *.pyc-Modul importiert und ausführt.

[numerix]

Vielen Dank euch für die Informationen.
Ich denke, ich habe das jetzt soweit verstanden und werde keine pyc-Files als CGIs ausführen müssen.
Richtig eingestellte Direktiven für den Webserver bieten dann ja ausreichenden Schutz vor Einblicken in die py-Files.

[Y0Gi]

Leider ist nunmal die Konfiguration einer der Hauptschwachpunkte bei Servern

Ich finde die Idee mit dem Ausführen des Bytecodes auch interessant und finde hoffentlich mal Zeit, das zu versuchen. Ich denke, da ist einfach ein entsprechender Handler erforderlich, der den Python-Interpreter entsprechend füttert. Ggf. noch ein Umbiegen von `.py`-Endungen auf `.pyc` aus sicht des Clients - wobei ich dem User gegenüber ohnehin verbergen will, wie die Website nun serverseitig erzeugt und verarbeitet wird.

[jens]

Habs nicht probiert, aber was passiert denn mit einem "AddHandler cgi-script .pyc" ?

[Leonidas]

Habs nicht probiert, aber was passiert denn mit einem "AddHandler cgi-script .pyc" ?

Vermutlich wird der CGI-Handler den Bytecode bis zum ersten "\n" lesen und versuchen das als Pfad zum Interpreter auszuführen. Da würde smas Bytecode-Interpreter ansetzen, indem man normalen Bytecode mit dem Pfad patcht und der Interpreter nur den Rest ohne den Pfad ausführt.

[Y0Gi]

Lässt sich der Python-Interpreter nicht auch mit .pyc/.pyo füttern? Dann sollte ein Handler das doch auch können - so meine Ausgangsposition.