Scriptsicherheit

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Y0Gi
User
Beiträge: 1454
Registriert: Freitag 22. September 2006, 23:05
Wohnort: ja

Beitragvon Y0Gi » Freitag 1. Februar 2008, 01:16

Software bzw. deren Funktion ist immer duplizier- und reproduzierbar. Das sollte jeder Entwickler wissen und daher erübrigt sich meiner Meinung nach auch die Idee, Code vor fremden Augen schützen zu wollen.

Bonusfrage: Nenne mir einen Kopierschutz, der nicht geknackt oder ausreichend umgangen wurde.
lunar

Beitragvon lunar » Freitag 1. Februar 2008, 08:07

Y0Gi hat geschrieben:Bonusfrage: Nenne mir einen Kopierschutz, der nicht geknackt oder ausreichend umgangen wurde.

Miese Qualität! Schlechte Programme will niemand haben, ergo werden sie auch nicht kopiert. Beispiel: Vista

scnr
lunar
droptix
User
Beiträge: 521
Registriert: Donnerstag 13. Oktober 2005, 21:27

Beitragvon droptix » Freitag 1. Februar 2008, 08:50

Okay, damit sind wir nun endgültig doch vom eigentlichen Thema abgedriftet… Es ist zwar interessant, aber in der Praxis dann doch wieder egal, ob ihr einen Schutz als unnötig betrachtet. Fakt ist, dass es Unternehmen gibt, die das als nötig erachten.

Scriptschutz hat schon eine Relevanz, sonst würden Unternehmen kein Geld darin investieren. Und dass sie das tun, sieht man z.B. am Zend Guard (1. Posting). Ohne das Interesse am Schutz des geistigen Eigentums könnte ja jeder Open-Source entwickeln.

Der Schutz hat zudem auch noch eine weitere positive Eigenschaft: das Einschränken von Risiko. Die Hürde, um eine Sicherheitslücke im Programm zu finden, ist weitaus niedriger, wenn der Quellcode verfügbar ist. Das heißt zwar nicht, dass Closed-Source vom Ansatz her sicherer ist, jedoch gibt es andere Vorteile durch Unwissenheit. (Klar, bei Open-Source könnten mehr mitarbeiten und Sicherheitslücken im Vorhinein schließen.)

Fassen wir zusammen:
    Für Python gibt es keine derartige Scriptschutzfunktion, abgesehen von pyobfuscate, was aber noch buggy ist.
    Knackbar ist nichts.


Wöllte man so etwas im Eigenbau basteln, müsste der Scriptschutz während dem `import` Befehl greifen. Kann man den denn so erweitern, dass nach dem Einlesen der .py Datei ein Decrypt-Verfahren über den Dateiinhalt läuft?
Zap
User
Beiträge: 533
Registriert: Freitag 13. Oktober 2006, 10:56

Beitragvon Zap » Freitag 1. Februar 2008, 09:17

Ich vermute das man noch viel tiefer gehen müsste.
Ein Skript (so verschlüsselt es auch ist) muss ja in letzter Konsequenz dem Interpreter zum verarbeiten vorgelegt werden. Und genau da liegt dann die Chance für die (ach so Böswilligen) Neugierigen zuzuschlagen.
IMHO wäre es nötig seine Programme mit einem eigenen PythonInterpreter auszuliefern, welcher bestimmte Entschlüsselungsarbeiten im Kern vornimmt.
Damit schneidet man sich zwar noch aggresiver von der Außenwelt ab. Aber bitte, sollen se doch ;)

Ein letzter Schwenk auf die Grundsatzdiskusion:
Firmen wollen kostenfrei das Wissen und die Arbeit anderer(hier in Form von Python) nutzen. Sind dann aber nicht bereit ihr Wissen im gegenzug mit anderen zu teilen. Das finde ich moralisch doch sehr verwerflich. :roll:

Wenn es im firmeninterne Daten geht die wirklich nicht nach außen dürfen dann sollte man darüber nachdenken was die beim Kunden auf dem Rechner zu suchen haben.
Der einzige Anwendungsfall den ich akzeptabel finde sind Lizensierungen von Software. Aber dafür gibt es kryptographische Algorithmen unter Verwendung von Private und Public Keys, welche meines Wissens nach heutigem Stand ausreichend sicher sind.
droptix
User
Beiträge: 521
Registriert: Donnerstag 13. Oktober 2005, 21:27

Beitragvon droptix » Freitag 1. Februar 2008, 09:36

Zap hat geschrieben:Ich vermute das man noch viel tiefer gehen müsste.
Ein Skript (so verschlüsselt es auch ist) muss ja in letzter Konsequenz dem Interpreter zum verarbeiten vorgelegt werden. Und genau da liegt dann die Chance für die (ach so Böswilligen) Neugierigen zuzuschlagen.


Nichts ist unknackbar, soweit waren wir schon. Wer wirklich will, macht sich die Mühe. Kommt drauf an wie einfach es einem "Angreifer" gemacht wird. Wenn es schwer genug war und trotzdem geknackt wurde, dann hat sich der Angreifer den Quellcode auch verdient :twisted: Nur wenn es durch decompyle quasi in Sekunden möglich ist, den Ursprungsquellcode wieder herzustellen, dann liegt die Messlatte sicher für viele zu niedrig.

Zap hat geschrieben:Firmen wollen kostenfrei das Wissen und die Arbeit anderer(hier in Form von Python) nutzen.


Macht ihr das nicht ständig auch? Nicht unbedingt im Python-Forum, aber in anderen Bereichen…

Zap hat geschrieben:Sind dann aber nicht bereit ihr Wissen im gegenzug mit anderen zu teilen.


Das sehe ich nicht so. Ich bin der Meinung dass viele ihr Wissen wieder anbieten, in welcher Form auch immer. Ich fände es ebenfalls verwerflich, wenn es so wäre. Wenn es um die Entwicklung neuartiger Dinge geht, kann man sein Wissen nicht immer teilen, allein schon nicht im Interesse des Auftraggebers/Arbeitgebers. Letztlich sind es meistens Angestellte, die programmieren und im Python-Forum auch mal nachfragen.

Zap hat geschrieben:Wenn es im firmeninterne Daten geht die wirklich nicht nach außen dürfen dann sollte man darüber nachdenken was die beim Kunden auf dem Rechner zu suchen haben.


Wenn man sein Wissen in ein Programm packt, dass einem Kunden Vorteile und Erfolg bringt, dann liegt das Wissen nun mal beim Kunden auf der Platte. Wenn ich den Quellcode als "firmeninterne Daten" bezeichne, ist dieser Umstand von Haus aus bereits erfüllt.
BlackJack

Beitragvon BlackJack » Freitag 1. Februar 2008, 13:25

Zu dem `decompyle` *nochmal* das Argument: Es ist nicht unsicherer als Java. Eher noch sicherer weil es AFAIK nur dieses eine Programm gibt, dass kein aktuelles Python beherrscht. Python 2.3 ist da glaube ich der Stand. Wohingegen es bei Java sogar mehrere Decompiler-Projekte gibt.

Eine Firma die keine Probleme hat Java-`class`-Dateien an Kunden aus zu liefern, sollte auch mit `pyc`- bzw. `pyo`-Dateien keine Probleme haben. Wenn die Einstellung zu `class` und `pyo` nicht übereinstimmt, ist das etwas rein psychologisches. Da helfen keine technischen Massnahmen, sondern ein Arzt. ;-)

Mir ist ehrlich gesagt auch immer noch zu schwammig von was für tollem Wissen Du da redest, dass niemand sehen darf, das aber trotzdem zum Kunden auf die Platte darf. Ich würde mal sagen 99% an Anwendungsoftware-Quelltext ist absolut langweilig. GUI-Code, ein bisschen Daten hin und her schieben, alles nix wirklich Aufregendes.

Neue innovative Ideen sind oft, dass das Programm im ganzen etwas ermöglicht, was vorher noch niemand angedacht hat. Oder Bedienkonzepte. Das sind aber Sachen, die man von aussen sehen und entsprechend nach programmieren kann.

Und das eine Prozent wo wirklich ein Wissensvorsprung so bedeutend ist, dass er vor den Augen der Konkurrenz versteckt werden muss, sollte das einfach mal nicht auf der Festplatte von Kunden landen. Denn wenn die Konkurrenz da wirklich hinterher ist, werden die's "reverse engineeren", egal wie stark der Schutz ist. Wenn keiner es knacken will, ist es andererseits nicht ökonomisch Zeit in eine Verschlüsselung o.ä. zu investieren.
lunar

Beitragvon lunar » Freitag 1. Februar 2008, 13:53

droptix hat geschrieben:Scriptschutz hat schon eine Relevanz, sonst würden Unternehmen kein Geld darin investieren.

Auch Unternehmen sind vor Fehlern nicht gefeigt. Die Leute, die das Geld für Technik verwalten bzw. ausgeben, sind nämlich in den seltensten Fälle auch Leute, die wirklich Ahnung von Technik haben.

Tatsache ist schlichtweg, dass Script"schutz" nicht existiert. Ein "geschütztes" Script ist nicht sicherer als ein ungeschütztes. Der einzige Schutz gegen Missbrauch des Quellcodes ist das Gesetz. Dekompilierung und Reverse Engineering sind in Deutschland Urheberrechtsverstöße. Auf diesem Wege gewonnenes Wissen ist für Firmen nicht zu gebrauchen, es sei denn, sie wollen sich dem Vorwurf der Urheberrechtsverletztung aussetzen.

Zudem stellt sich die Frage, ob Code in Programmen wirklich schützenswert ist. Ideen äußern sich nicht so sehr im Quellcode wie in der äußeren Erscheinung. Beispiel Aero: Es sieht toll aus, aber wen interessiert schon der Code? Eine Aero-ähnliche Oberfläche kann man leicht nachprogrammieren, egal ob der Code nun geschützt ist oder nicht.

Der Schutz hat zudem auch noch eine weitere positive Eigenschaft: das Einschränken von Risiko. Die Hürde, um eine Sicherheitslücke im Programm zu finden, ist weitaus niedriger, wenn der Quellcode verfügbar ist.

Security by obscurity funktioniert nicht. Die wenigen Firmen, die noch immer daran glauben (z.B. Microsoft), werden regelmäßig von katastrophalen Lücken heimgesucht. Das liegt daran, dass nur die wenigsten Lücken direkt aus dem Quelltext ersichtlich sind. Das sind vor allem Buffer-Fehler und ähnliches, was durch die unsichere Verwendung von C-Standardfunktionen verursacht wird.

Diese Sicherheitslücken sollten es bei einem entsprechend modernen Entwicklungsprozess aber eigentlich gar nicht mehr in die Öffentlichkeit schaffen, da entsprechende Security-Tools existieren, mit denen man derartiges aufspüren kann. Auch braucht man den Quelltext nicht, um diese Lücken von außen aufzuspüren. Da reicht es schon, wenn man verdächtigen Stellen (z.B. Nutzereingaben) einfach ein bisschen experimentiert. Dann sieht man meist recht schnell, ob dort eine Sicherheitslücke verborgen sein könnte.

Zudem sind Programme in High-Level-Sprachen wie Python oder Java davon sowieso nicht wirklich betroffen, da Speicherallokation und Manipulation im Interpreter bzw. Jit-Compiler geschieht. Problematisch sind nur Lücken in der Runtime, auf die man aber wenig Einfluss hat.

Richtig schlimm sind Sicherheitslücken, die durch logische Fehler im Programm auftreten. Ein Beispiel ist z.B. die WMF-Lücke, die es ermöglichte, Code aus Bilddateien heraus auszuführen. Solche Lücken erkennt man aber gerade in komplexen Systemen nicht aus dem Quellcode.

Der umgekehrte Schluss, dass offener Code die Sicherheit erhöht, ist der richtige. Zum einen macht man damit professionellen Experten die Arbeit leichter, was die Chance erhöht, dass Lücken von der "guten" Seite gefunden und beseitigt werden, bevor sie von der "bösen" ausgenützt werden können. Zum anderen überträgt man damit das bewährte Kerckhoffs-Prinzip aus der Kryptographie auf Software: Sicherheit muss selbst dann garantiert werden, wenn dem Angreifer alles bekannt ist!
droptix
User
Beiträge: 521
Registriert: Donnerstag 13. Oktober 2005, 21:27

Beitragvon droptix » Freitag 1. Februar 2008, 14:04

BlackJack hat geschrieben:Zu dem `decompyle` *nochmal* das Argument: Es ist nicht unsicherer als Java. Eher noch sicherer weil es AFAIK nur dieses eine Programm gibt, dass kein aktuelles Python beherrscht. Python 2.3 ist da glaube ich der Stand. Wohingegen es bei Java sogar mehrere Decompiler-Projekte gibt.


Meines Wissens nach geht mittlerweile auch Python 2.5:
decompyle hat geschrieben:The 'decompyle' service converts Python byte-code back into equivalent Python source. It accepts byte-code from any Python version starting with 1.5 up to 2.5


BlackJack hat geschrieben:Mir ist ehrlich gesagt auch immer noch zu schwammig von was für tollem Wissen Du da redest, dass niemand sehen darf, das aber trotzdem zum Kunden auf die Platte darf.


Hum, hab ich das so schlecht dargestellt? Ich konstruiere hier nur Zusammenhänge und erzähle keine konkreten Geschichten…

Was du z.B. in dein Python-Programm steckst ist dein Wissen. Sicher könnte das auch jemand anders haben, aber dein Programm löst vielleicht ein spezielles Problem, welches bislang unbedient blieb. Weil du dein Wissen mit einer neuartigen Idee auf besondere Weise gebündelt hast, entsteht so vielleicht ein Programm mit einem Alleinstellungsmerkmal. Genau so ergeht es StartUp-Unternehmen: Ihr einziges Verkaufspotenzial ist ein Technologievorsprung durch irgend eine noch nie dagewesene Idee, die vorhandenes Wissen neuartig zusammensetzt.

Also stimme ich dir zu: ich spreche wohl eher von neuen Ideen. Das Wissen dafür ist meistens schon lange da. Ich denk da immer an die IBM-Werbung mit dem geschnitten Brot…

BlackJack hat geschrieben:Und das eine Prozent wo wirklich ein Wissensvorsprung so bedeutend ist, dass er vor den Augen der Konkurrenz versteckt werden muss, sollte das einfach mal nicht auf der Festplatte von Kunden landen.


Wie sollte man denn das umgehen? Da fällt mir nur ein Webservice ein. Ansonsten landet die Idee bzw. das gebündelte Wissen auf der Festplatte des Kunden, nur eben nicht lesbar.
lunar

Beitragvon lunar » Freitag 1. Februar 2008, 14:19

droptix hat geschrieben:Ansonsten landet die Idee bzw. das gebündelte Wissen auf der Festplatte des Kunden, nur eben nicht lesbar.

Ein "nicht lesbares" Programm gibt es nicht. Jedes Programm, welches auf der Platte des Users liegt, muss lesbar sein. Sonst wäre es ja nicht ausführbar.

Deswegen gilt: Alles, was auf der Platte des Kunden landet, ist potentiell lesbar. Dagegen hilft kein Scriptschutz, dagegen hilft noch nicht mal der Allmächtige selbst ;)

Folglich musst du abwägen: Ist der Code wirklich so wertvoll (was ich mich nicht vorstellen kann)? Dann muss du das Programm eben als Webservice ausführen, und nur dumme GUI-Clients für die Kundenrechner ausliefern. Fraglich ist dann allerdings wieder, ob die Firmen dieses Programm dann überhaupt kaufen werden. Die IT-Sicherheit einer Firma ist nämlich sicherlich nicht begeistert davon, geschäftskritische Daten auf fremden Servern zu verarbeiten.
droptix
User
Beiträge: 521
Registriert: Donnerstag 13. Oktober 2005, 21:27

Beitragvon droptix » Freitag 1. Februar 2008, 14:33

lunar hat geschrieben:Der umgekehrte Schluss, dass offener Code die Sicherheit erhöht, ist der richtige. Zum einen macht man damit professionellen Experten die Arbeit leichter, was die Chance erhöht, dass Lücken von der "guten" Seite gefunden und beseitigt werden, bevor sie von der "bösen" ausgenützt werden können. Zum anderen überträgt man damit das bewährte Kerckhoffs-Prinzip aus der Kryptographie auf Software: Sicherheit muss selbst dann garantiert werden, wenn dem Angreifer alles bekannt ist!


Das regt zum Nachdenken an :roll:
BlackJack

Beitragvon BlackJack » Freitag 1. Februar 2008, 14:52

@droptix: Ah, `decompyle` kostet dann aber etwas. Ist auch eine gewisse Hürde. Und wenn man es als Webservice nutzt, kommt noch dazu, dass dann eventuell ein Dritter, nämlich der Anbieter von `decompyle` vor Gericht als Zeuge gegen einen auftreten kann, wenn man unberechtigt fremden Code in Quelltext verwandelt hat.

Du "konstruierst Zusammenhänge", nichts konkretes, das ist es was ich mit "schwammig" meine. Und dagegen kann man fast nichts tun. Wenn man sich gegen etwas schützen möchte, muss man schon *genau* wissen, wogegen und wie stark. Gegen dieses allgemeine "Kunde darf Implementierung von Idee nicht sehen" hilft wirklich nur der Webservice. Wie das zum Beispiel bei `decompyle` gemacht wird. :-)

Bei dem beschriebenen Szenario ist die Kombination der Ideen das Wesentliche und nicht der Quelltext. Die Kombination bekommt man auch ohne den Quelltext heraus, in dem man sich anschaut was das Programm bekommt und was es daraus macht. Auf die IBM-Werbung bezogen: Wenn ich vorher das Brot sehe, und nachher die geniale Idee mit den Scheiben, werde ich auch ohne gesehen zu haben wie jemand ein Brotmesser benutzt, einen Weg finden können Brot in Scheiben zu zerteilen.

Wenn man ausführbaren Code rausgibt, kann man nur gewisse Hürden aufbauen, die das "reverse engineering" erschweren. `pyo`-Dateien sollten für den Anfang genügen. Schau Dir mal die Preise vom `decompyle`-Webservice an. Die sind nicht ohne. Entweder eine Beschränkung auf 5 Dateien pro Monat mit mindestens 10€ pro Datei (10€ pro angefangene 5 KiB/Datei), oder mindestens 500€ für bis zu 5 Dateien und für jede weitere Datei nochmal 100€.

Man kann sich einen eigenen Python-Interpreter bauen, bei dem die Werte der Bytecodes anders sind. Dann funktioniert `decompyle` nicht mehr so einfach, bis der Angreifer herausgefunden hat, wie die neuen Werte zu den alten stehen.

Und man kann Teile des Programms in Pyrex/Cython oder C schreiben und zwingt damit den Angreifer zu einem Disassembler zu greifen. Ist aber letztendlich auch ein recht schwacher Schutz, der nur ein wenig aufhält. Wenn überhaupt. "Reverse engineering" von `pyo`-Dateien ist relativ exotisch, für x86-Maschinencode gibt's wesentlich mehr Werkzeuge und sicher auch erfahrene (Cr|H)acker.
Benutzeravatar
Leonidas
Administrator
Beiträge: 16023
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Beitragvon Leonidas » Freitag 1. Februar 2008, 14:55

decompyle für Python 2.5 ist komerziell, die freie Version die von einigen Debian-Leuten maintaint wird ist auf dem Stand von 2.3. Somit kann man neuen Python Bytecode zumindest nicht umsonst disassemblieren. Java-Bytecode schon.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Benutzeravatar
BlackVivi
User
Beiträge: 762
Registriert: Samstag 9. Dezember 2006, 14:29
Kontaktdaten:

Beitragvon BlackVivi » Freitag 1. Februar 2008, 14:56

Ich glaube, dass größte Problem für den OP ist...

Ich mach'n Programm und verkauf's. Einer kauft's, kopiert den Quelltext, ändert 2 Zeilen und verkauft es für 10 € weniger oder macht's frei.

(Natürlich ist es im Endeffekt nicht so leicht.... Aber ich denke halt, dass dies seine Bedenken sind.)
lunar

Beitragvon lunar » Freitag 1. Februar 2008, 15:09

BlackVivi hat geschrieben:Ich glaube, dass größte Problem für den OP ist...

Ich mach'n Programm und verkauf's. Einer kauft's, kopiert den Quelltext, ändert 2 Zeilen und verkauft es für 10 € weniger oder macht's frei.

Dekompilieren und Reverse Engineering ist - bis auf wenige Ausnahmen - durch das Urheberrecht untersagt! In dem Moment, in dem eine Firma geklauten Code in ihr Programm einbaut, begeht sie eine Urheberrechtsverletzung. Folglich wird keine seriöse Firma ihr Programm auf solchem Code aufbauen!

Die unseriösen Firmen/Personen dagegen würde sowieso mehr oder weniger alles tun, um die Code zu erhalten, da schützt auch kein Obfuscator.

Geheimhaltung des Codes und bessere Sicherheit sind keine Argumente für verschlüsselten Code. Ersteres lässt sich damit nicht erreichen, letztere wird durch Verschlüsselung eher noch verringt als erhöht.

Warum also sollte eine Firma Geld in Dinge investieren, die entweder nichts bringen oder sogar schädlich sind? Hinter einem solchen Vorhaben steht keine kluge Geschäftsführung.
Benutzeravatar
veers
User
Beiträge: 1219
Registriert: Mittwoch 28. Februar 2007, 20:01
Wohnort: Zürich (CH)
Kontaktdaten:

Beitragvon veers » Freitag 1. Februar 2008, 15:48

Wäre sich eine Firma die Quelltext klaut würde ich den geklauten Code auch verschlüsseln. :wink:
My Website - 29a.ch
"If privacy is outlawed, only outlaws will have privacy." - Phil Zimmermann

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder