Hallo, ist es möglich als Schutz vor backdoors etc ein zufällig generiertes operating system einzusetzen? Mit zufällig ist gemeint, im Quelltext Systemparameter (i.e. Einsprungadressen, namen der shared libraries, addressmapping, device identifiers etc) der API per Zufallsgenerator zu setzen, und die Quelltexte der Anwendungsoftware automatisiert anzupassen. Fremdsoftware dürfte es dann schwerfallen das system über die API zu steueren bzw. auszuspionieren (Screenshots ziehen). Gibbets da schon eine Linux-Baukasten/Distri? MfG, B.B.
Hallo Bodo, Die Einsprungaddressen per Zufallsgenerator zu setzen wäre toll. Aber der Linker wird Dir einen Strich durch die Rechnung machen. Den Sourcecode zu verwürfeln wird vom Compiler wieder ausgeglichen. Dieser Ansatz ist also zum Scheitern verurteilt. Distri-Baukästen gibts wie Sand am Meer. Ich selber verwende Gentoo und compilier alles selber. Wenn Du die CFLAGS etwas "unkonventionell" setzt, hast Du von der Seite nur eine kleine Gefahr. Es bleibt aber immer noch das Problem, wenn der eingeschleuste Code eine "NOP-Rutsche" enthält. Es steht und fällt die Systemsicherheit also mit der Aktualität der eingesetzten Pakete. Das ist bei Gentoo aber hervorragend. Gruß Olaf
zum schluss hast du aber einen Interpreter wie Perl laufen und schon kann es ein virus in Perl geben.
Bodo Bodenlos schrieb: > ist es möglich als Schutz vor backdoors etc ein zufällig generiertes > operating system einzusetzen? Mit zufällig ist gemeint, im Quelltext > Systemparameter (i.e. Einsprungadressen ... OpenBSD setzt wo imemr möglich zufallsgenerierte Werte im Betrieb ein. Beispielsweise läßt sich die Einsprungadresse auf dem CPU-Stack nicht vorhersagen, weil vor jeder Einsprungadresse ein Stack-Segment von zufällig erzeugter Länge liegt. Das Ausnutzen etwaiger Exploits wird deutlich erschwert.
Bodo Bodenlos schrieb: > Hallo, > > ist es möglich als Schutz vor backdoors etc ein zufällig generiertes > operating system einzusetzen? Na ein zufällig generiertes System wird wohl auch nur zufällig funktionieren... ;-) > Mit zufällig ist gemeint, im Quelltext Systemparameter (i.e. > Einsprungadressen, Trivial für die meisten Sachen, z.B. wenn Du Sachen wegkonfigurierst ändern sich viele Adressen. Ausser die natürlich die per Definition bekannt sein müssen - die Einsprungadressen eben, die zu ändern ist richtig Arbeit. > namen der shared libraries, Sehr schwierig - man müsste sämtliche Software anpassen, in Makefiles oder SW die dlopen() etc. benutzt stehen die Namen drin. Macht auch Bugreports und andere Kommunikation, ähh, interessant, auf eine sehr interessante Art und Weise natürlich. > addressmapping, Standardfeature moderner OS. Man sollte 64Bit benutzen damit das vernünftig funktioniert. > device identifiers etc) Kannst Du zumindest bei Linux im Prinzip machen, wäre kein Spass - wenn /dev/null auf einmal /dev/discard heisst hast Du eine Menge Probleme zu lösen. Die unterliegenden Device-IDs bleiben aber weitgehend fest. > der API per Zufallsgenerator zu setzen, und die > Quelltexte der Anwendungsoftware automatisiert anzupassen. Ja, nun, das ist genau der wirklich schwere Teil der Aufgabe... Könntest Du sowas zuverlässig machen würdest Du ziemlich sicher Millionär oder Milliardär damit werden. > Fremdsoftware > dürfte es dann schwerfallen das system über die API zu steueren bzw. > auszuspionieren (Screenshots ziehen). Ähhh, das habe ich jetzt nicht verstanden, Screenshots? Uuhhh, dieses Trojanerteil? Unterschätze nicht die Fähigkeiten eines Angreifers, immerhin stehen ja die neuen Devicenamen etc. notwendigerweise in den neuen Binaries (und also im Speicher auch) irgendwo drin. Hat der Code Sicherheitslücken hilft das alles nicht viel. > Gibbets da schon eine Linux-Baukasten/Distri? Schau Dir mal "Linux from Scratch" (LFS) an, ist Linux auf die harte Tour.
>> Fremdsoftware >> dürfte es dann schwerfallen das system über die API zu steueren bzw. >> auszuspionieren (Screenshots ziehen). > > Ähhh, das habe ich jetzt nicht verstanden, Screenshots? Uuhhh, dieses > Trojanerteil? Die Grundidee ist die Programmierschnittstelle des Betriebssystem die jede Software benutz automatisiert so zu verändern, das ebenfalls jede Software die auf dem system läuft und nicht direkt auf die Hardware greift unangepasst nicht aufs Betriebssystem/Treiber zugreifen kann. Will die Software also OS oder treiberroutinen nutzenum die Bildschirmgröße zu ermittel, und das angezeigte bitmap im Filesystem zwischenzuspeichern (screenshot anlegen), funktioniert das nicht da diese routinen nicht wie beieinem Standardsystem aufgerufen werden. Ganz old school gesprochen, im DOS werden alle Software Intterrupts individuell verbogen, (in Quelltext des OS) , dann muss die gesamte Anwendungssoftware darauf angepasst werden. anderes Beispiel als Pfadtrenner wird statt "/" "%" oder ein anderes zufällig gewähltes Zeichen verwendet. (Ich weiss das ist wenig praktikabel, soll hier nur als Beispiel dienen) > > Unterschätze nicht die Fähigkeiten eines Angreifers, immerhin stehen ja > die neuen Devicenamen etc. notwendigerweise in den neuen Binaries (und > also im Speicher auch) irgendwo drin. Hat der Code Sicherheitslücken > hilft das alles nicht viel. Der Angreifer muesste aber seine Soft individuell anpassen, kann also keine Massenangriffe. MfG,
natürlich geht das, nur ist es nicht praktikabel, weil du dann ja erst jahrelang die software anpassen müsstest, bis sie überaupt läuft.. und wenn du diese anpassungen irdgendwie automatisierst, hast du dein sicherheitskonzept auch schon wieder ausgehebelt..
Solange das OS NICHT mit der Außenwelt in Kontakt tritt werden kaum Probleme auftauchen. Daher glaubte man z.B. NT ohne Netzwerkkarte relativ "sicher" :-) Sobald jedoch ein Speicherplatz oder Systemordner zur Kommunikation mit anderen Programmen oder der Tastatur gebraucht wird, ist die Sache schon fraglich.
Bodo Bodenlos schrieb: > old school gesprochen, im DOS werden alle Software Intterrupts > individuell verbogen, (in Quelltext des OS) , dann muss die gesamte > Anwendungssoftware darauf angepasst werden. Und genau da ist das Problem. >> Unterschätze nicht die Fähigkeiten eines Angreifers, immerhin stehen ja >> die neuen Devicenamen etc. notwendigerweise in den neuen Binaries (und >> also im Speicher auch) irgendwo drin. Hat der Code Sicherheitslücken >> hilft das alles nicht viel. > > Der Angreifer muesste aber seine Soft individuell anpassen, kann also > keine Massenangriffe. Das könnte ein gefährlicher Irrtum sein... Szenario: original steht irgendwo in einem vorhandenen Standardprogramm, sagen wir /bin/bash, der Device-Name "/dev/null" drin, an einer bekannten Stelle. Geändert steht dort jetzt "/foo/ball", aber natürlich an derselben Stelle. Wie schwer ist es also für die Angreifersoftware in /bin/bash nachzuschauen wie das Device nun heisst, root oder so braucht sie dafür nicht? ;-) Und natürlich kann der Angreifer da noch wesentlich cleverere Methoden benutzen. Hach, vor einer Weile gab es z.B. mal ein Paper das beschrieb wie man Crypto-Schlüssel in Binaries findet - weil die sich halt statistisch von Normaldaten unterscheiden, cooles Zeug. Usw. usf. Lies mal über "security by obscurity" und Kerckhoff-Prinzip nach.
>Das könnte ein gefährlicher Irrtum sein... >Szenario: original steht irgendwo in einem vorhandenen Standardprogramm, >sagen wir /bin/bash, der Device-Name "/dev/null" drin, an einer >bekannten Stelle. >Geändert steht dort jetzt "/foo/ball", aber natürlich an derselben >Stelle. >Wie schwer ist es also für die Angreifersoftware in /bin/bash >nachzuschauen wie das Device nun heisst, root oder so braucht sie dafür >nicht? ;-) Gerade setzt doch gerade die defensiv-maßnahme : individuelles OS an, die Angreifersoft benötigt zum nachschauen die Betriebssystenroutinen fopen fseek etc.. Die diese software aber nich aufrufen kann, da sie nicht für dieses System gelinkt wurde. Die Angreifesoftware wäre in einer ähnlichen Situation wie ein Windows-maus nutzer, der plötzlich vor einem Amiga/Atari/C64 ohne maus steht und dort eine datei kopieren soll. Die Tastatur ist natürlich in Suaheli mit kyrillischen zeichen beschriftet. >Lies mal über "security by obscurity" und Kerckhoff-Prinzip nach. Das hilft mir nicht weiter beim Entwurf eines übertrieben gesagt OS-Baukasten. Ich werde mich wohl eher über Linker und Load/Execute systeme schlau machen. Bodo Bodenlos schrieb: >> old school gesprochen, im DOS werden alle Software Intterrupts >> individuell verbogen, (in Quelltext des OS) , dann muss die gesamte >> Anwendungssoftware darauf angepasst werden. >Und genau da ist das Problem. Nein es ist kein Problem beim dem geschilderten beispiel ein paar Zeilen zu modifizieren. Tauschen der Interrupt für filelesen und file schreiben (AH=0x39 resp. AH=0x40) die Subroutinenummern, ist nur der Quelltext (z.B. der vom C-Compiler erzeugte ASM-Code nach dem entsprechenden API-Aufruf zu durchsuchen und dort auszutauschen. da es mindestens hundert verschiedene Servicenummer gibt, muss der Angreifer alle Kombinationen dieser einen Testprogramm schreiben und übersetzen um dieses anzugreifen. ferner muss man eben nicht alle Anwendungen anpassen, sondern nur die Stelle (Linker?) bei der die modifizierten OS-Calls angesprochen werden. Gruß
Bodo Bodenlos schrieb: >>Das könnte ein gefährlicher Irrtum sein... > >>Szenario: original steht irgendwo in einem vorhandenen Standardprogramm, >>sagen wir /bin/bash, der Device-Name "/dev/null" drin, an einer >>bekannten Stelle. > >>Geändert steht dort jetzt "/foo/ball", aber natürlich an derselben >>Stelle. > >>Wie schwer ist es also für die Angreifersoftware in /bin/bash >>nachzuschauen wie das Device nun heisst, root oder so braucht sie dafür >>nicht? ;-) > > Gerade setzt doch gerade die defensiv-maßnahme : individuelles OS an, > die Angreifersoft benötigt zum nachschauen die Betriebssystenroutinen > fopen fseek etc.. Die diese software aber nich aufrufen kann, da sie > nicht für dieses System gelinkt wurde. Wenn Du soweit gehen willst/kannst stimmt das (fopen und Freunde sind übrigens aus der C RTL und nicht aus dem OS). Denk dran dass Du auch den Syscall-Mechanismus des OS ändern musst - sonst ruft die Malware die Syscalls einfach direkt auf. Unter Linux z.B. würde das bedeuten statt INT 80 einen anderen zu nehmen und Sachen wie Sysenter (die man nicht umbiegen kann) ganz abzuschalten. Klingt nach Spass. >>Lies mal über "security by obscurity" und Kerckhoff-Prinzip nach. > Das hilft mir nicht weiter beim Entwurf eines übertrieben gesagt Hmm, ich denke doch, zumindest konzeptionell. Die zumindest in der Theorie bessere Lösung wäre ein OS wo der Angreifer den Code haben kann und trotzdem nichts machen kann. Man darf ja noch träumen... ;-) > OS-Baukasten. Ich werde mich wohl eher über Linker und Load/Execute > systeme schlau machen. Ja, die musst Du natürlich auch verändern, vielleicht sogar zusammen mit dem Binärformat.
Jasch schrieb: > Die zumindest in der Theorie bessere Lösung wäre ein OS wo der Angreifer > den Code haben kann und trotzdem nichts machen kann. Man darf ja noch > träumen... ;-) Doch, doch das ist mit zufällig generierten OS gemeint. Die Sourcen darf er gerne haben, aber eben nicht die Parameter (Header)-Datei in der steht wie die sys-Calls neusortiert wurden. Das wäre dann der Schlüssel. Bei jeder Installation wird zufällig eines Speichermapping/INT-Verteilung/etc Konzept/liste erstellt, in die erwähnte header-Datei geschrieben, dann alles kompiliert und die headerDatei "fern-gelagert" (Falls Anwendersoft für dieses System nachcompiliert werden sollte). Den Compiler etc sollte man natürlich auch nicht auf dem System lassen. MfG, B.B.
Bodo Bodenlos schrieb: > Jasch schrieb: >> Die zumindest in der Theorie bessere Lösung wäre ein OS wo der Angreifer >> den Code haben kann und trotzdem nichts machen kann. Man darf ja noch >> träumen... ;-) > > Doch, doch das ist mit zufällig generierten OS gemeint. Die Sourcen darf > er gerne haben, aber eben nicht die Parameter (Header)-Datei in der > steht wie die sys-Calls neusortiert wurden. Das wäre dann der Schlüssel. Hmm, OK, so kann man das sehen. Wobei ich eher ein OS meinte wo die Sicherheitsmechanismen so stark sind dass der Angreifer auch bei Kenntnis der Parameter oben nichts machen kann. Keine Bugs ist natürlich zwingende Voraussetzung. Sehr utopisch, schon klar. Wobei Deine Variante ein Problem haben müsste: wenn es Sachen wie Buffer Overflows gibt könnte der Angreifer Code einschleusen der die Syscalls selber nicht mehr wissen muss - weiss ja sein "Gastgeberprozess". Uuhhhh, funktioniert nicht dieses Staatstrojaner-Ding so ähnlich, halt per DLL Preload oder sowas statt Overflow? Unter Linux hiesse das dann LD-PRELOAD. Ich glaube nicht dass man nur mit Syscalls verwürfeln auskommen kann.
Jasch schrieb: > Ich glaube nicht dass man nur mit Syscalls verwürfeln auskommen kann. Das sehe ich auch so. Jeder Interpreter bietet die Möglichkeit, die Verwürfelung zu umschiffen. Ansonsten müßten sich Eindringlinge nur um bekannte Programme als Einfallstor kümmern - die kennen ja die Syscalls.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.