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
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.
