Lowlevel
Lowlevel => OS-Design => Thema gestartet von: Svenska am 25. May 2005, 19:53
-
Ich hab mal nen Beitrag gefunden auf einer Webseite, wo das nur nebenbei erwähnt wurde. Gibt mir aber sehr zu denken.
Quelle: http://www.edugrid.ac.in/webfolder/courses/os/os_faq14.htm
4. Microkernel
[...]
AmigaOS, for example, was a microkernel - and an unusual one: Since AmigaOS had no memory protection, its messaging was as quick as it could get (passing a pointer to memory), making the AmigaOS kernel one of the fastest ever devised. On the other hand, that lack of memory protection also meant that the microkernel architecture gave no added stabilityâ¦
[...]
Vielleicht ist das eine Möglichkeit, das letzte aus der Hardware herauszuholen?
Svenska
-
Für die Serveranwender sicher ja, weil die ja nur kontrollierte Sachen laufen lassen, aber für Heimanwender oder sowas total mies, jeder Virus kann alles matsche machen und kennst ja den DAU...
-
Interessante Einstellung ;-) Aber ich würde doch eher sagen, dass auf einem Server ein Betriebsystem laufen sollte das stabil, zuverlässig und SICHER ist, weil es möglichst lange durchlaufen soll und ja allen möglichen Angriffen ausgesetzt ist. Da wäre ein OS ohne Memory Protection ja der blanke Hohn. Kann man auch gleich einen DOS oder Win95 Server aufsetzen :lol: . Den meisten Heimanwendern ist das glaub ich egal, wie gut ihr System gesichert ist, man braucht ja nur mal zu schauen wie viele den ganzen Tag als Admin arbeiten oder sich nicht um Firewalls,Systemupdates und ähnliches kümmern. Wo ein ungeschützes Betriebssystem wirklich Sinn macht sind einfache Spieleplattformen, damit die Performance auch ausgereizt wird. Da kann kein Virus oder Wurm stören, weil dass System eh von schreibgeschützten Medien geladen wird.
-
Es geht ja nicht nur darum Viren zu verhindern, sondern viel mehr die Programme gegen andere und den Kernel abzuschotten.
Weil läuft eiin Programm nit rund ist das ganze System betroffen.
Daher ist ein OS ohne Memory Protection blödmist.
-
Wieso bei Servern? Da kommt ja normal garnix rein, um ausgeführt zu werden! Folglich kann auch kein Speicherzugriff veranstaltet werden! Ein Apache-Server schickt einem nur die INet-Seiten, der startet doch nix, und wie soll sich ein Programm vom INet aus selber starten?
-
Ich sag nur Buffer Overflow. So startet sich ein Programm selber. Und dann ist ohne Speicherschutz direkt alles verloren. Mit Speicherschutz erstmal nur das, was das Programm tun könnte (was bei guten System SEHR viel weniger sein sollte).
Lösung -> Eine Technik nehmen die Buffer Overflow Angriffe gar nicht erst ermöglicht.
-
Na doll, werbe du halt für deine VMs ;)
Wie soll man bei einem Webserver ein Buffer Overflow erzeugen? Man bekommt doch nurn Request, verarbeitet den und schickt zurück...
-
Wie soll man bei einem Webserver ein Buffer Overflow erzeugen? Man bekommt doch nurn Request, verarbeitet den und schickt zurück...
indem der request oder ein teil davon ganz einfach zu lang ist? ;)
-
Ich sag nur Buffer Overflow. So startet sich ein Programm selber. Und dann ist ohne Speicherschutz direkt alles verloren. Mit Speicherschutz erstmal nur das, was das Programm tun könnte (was bei guten System SEHR viel weniger sein sollte).
Lösung -> Eine Technik nehmen die Buffer Overflow Angriffe gar nicht erst ermöglicht.
dieses göttliche gibt es mit dem amd64 :-)
MfG
DDR-RAM
-
Ja die No-Execute Option (NX) ist schon ein sehr nettes Feature der neuen AMD64. Nur das Betriebssystem muss es auch unterstützen. Es ist ja nicht wie in der Werbung angepriesen per se ein Virenschutz in der Hardware. Klingt immer so als ob der Prozessor Viren erkennt und killt ;-)
-
Jop, NX-Bits sind auch eine Möglichkeit. Und bedenke das man ja bei dynamischen Webseiten auch noch mehr probieren könnte - ausser es sind JSP's oder php-skripte.
C/C++ - CGI Skripte wären auch eine mögliche Gefährdung! ;)
-
Zum Thema BOF bei Servern, es gibt ja die lieben netten DOS-Attacken. Wenn die Anfragen zu schnell kommen, als dass sie der Server verarbeiten kann, kackt er irgendwann ab. Nur hat das mit Memory Protection direkt erstmal nix zu tun^^
Per se macht es nix wenn man ständig als Admin eingeloggt ist (zumindest bei Windows is das fast wurscht) wenn man sich nicht völlig DAU verhält, ich bin permanent als Admin angemeldet und habe keinerlei Probleme, abgesehen davon darf man als nicht-Admin unter Windows ja gar nix und da hätte ich ein Problem^^
Man hat auch schon vor dem amd64 die Möglichkeit gegen Buffer overflows zu agieren, nur etwas umständlicher mit dem BOUND Befehl.
-
BOUND-Befehl? Verstehe nicht so ganz was der macht, irgendwas mit arraygrenzen checken? Ich raff den Befehl nicht ganz, kann mir den mal wer erklären, vielleicht mit Beispiel :D
Man könnte sich auch schützten, indem man nicht segmentierung "ausschaltet", sondern mit günstigen limits und bases fürs cs-segment.
Aber segmentierung ist fürn Ar***.
MfG
DDR-RAM
-
Was BOUND bei AMD64 macht, weiss ich nicht. Beim 286er checkt er
einfach die Arraygrenzen, ob diese halt zwischen zwei Registerwerten
liegen und löst sonst eine Exception aus.
Wenn ein Apache bspw. einfach nur die ersten xy Zeichen akzeptiert und
wenn mehr kommt, halt die Anfrage killt, ist auch kein Buffer Overflow
möglich :) Aber wie gesagt, dass läuft dann wieder auf PHP, Perl, CGI und
so raus. Da ist es etwas komplizierter, das Design dagegen zu sichern :)
Und der Amiga war ja hauptsächlich eine Spielekonsole. Aber wenn der
Speicher zermatscht wurde, gab es eine Meldung "Press Left Mouse
Button to continue" [continue = reset ^^].
Also hat schon gemerkt, dass da was faulig war :)
Wenn man Buffer Overflows im Design verhindern könnte (bzw. mit Hilfe
des Prozessors), dann ist ein solcher Ansatz auf Servern sicherlich von
Vorteil. Schliesslich geht es da ja um Leistung und Sicherheit - letztere ist
dann mehr oder weniger gegeben.
Auf der Seite stand auch noch, dass Microkernel langsamer sind als
Monolithische Kernel, jedenfalls im Allgemeinen (ein schrottiges Design
macht jeden Geschwindigkeitsverlust wett - hab mal was von nem
Vergleich Basic <=> Asm gelesen... optimiert Basic war schneller als
unoptimiert Asm)
Also fuer gewisse Zwecke mag ein solcher Memoryprotectionfreier Ansatz
auch vorteilhaft sein...
Svenska
-
hm, der BOUND-Befehl, ist das nicht so, man übergibt nen index und nen pointer auf zwei dwords bzw. zwei words
und dann wird geprüft, ob der index dazwischen liegt, wenn nicht, gibs bound exceeded exception oder so.
Aber wozu das ganze?
Das ist ja kein Schutz vom System her, sondern vom Anwendungsprogrammier bzw. vom Compiler
man kann doch auch einfach so den index auf gültigkeit prüfen und muss nicht erst ne exception generieren oder gleicher overflow frei Programmieren. :D
Also SICHERHEIT sollte heutzutage ziehmlich groß geschrieben werden. ;-)
-
Zum Thema BOF bei Servern, es gibt ja die lieben netten DOS-Attacken. Wenn die Anfragen zu schnell kommen, als dass sie der Server verarbeiten kann, kackt er irgendwann ab. Nur hat das mit Memory Protection direkt erstmal nix zu tun^^
Liegt daran das DoS-Attacken erstmal nichts mit Buffer Overflows zu tun haben, ausser ich finde einen Puffer der z.B. bei zu vielen IP-Verbindungen überlaufen könnte. Aber in den meistens Fällen werden Buffer Overflows durch einzelne, spezielle Datenpakete ausgelöst.
-
Dos heisst erstmal Denial of Service also Dienstverweigerung, und den kann man schliesslich auf vielen wegen generieren. Wenn ein BOF erzeugt wird, wird der Dienst sicherlich auch verweigert;) Bei DoS wird der Server ja einfach mit Anfragen bombardiert->irgendwann geht dem Server der Speicher aus->Buffer Overflow
Aber mit Security ist das sowieso ne komplizierte Sache. Man kann ja soooooo viel kaputt machen wenn man nur will^^
-
Jo, aber (D)DoS geht meistens über Server vollmüllen mit der mehr Bandbreite als der selber hat. Und wenn der Speicher voll ist, hast du evtl. nen DoS geschafft, aber noch keinen Buffer Overflow in dem Sinne das du probieren könntest Code einzuschleusen. Dazu musst du Puffer suchen über deren Grenzen hinaus geschrieben werden könnte. Die Funktion gets ist so ein Beispiel für den Anfang - gets auf nen Array auf den Stack angewendet und du kannst über den Array hinaus die Rücksprungaddresse oder andere Variablen abändern. Das exakt ist ein Buffer Overflow Angriff - wenn die Kiste stattdessen abschmiert, nun gut, dann ist der Dienst auch weg, stimmt schon. ;)
-
Wie der DoS letztlich erreicht wird ist doch Wurscht:P
-
Bei nem DoS schon, aber der ist ja noch richtig harmlos im Vergleich zum Buffer Overflow - damit könnte man System ja nicht nur vorrübergehend lahm legen, sonder infizieren, das macht direkt noch viel mehr Spass! ;)
-
*g* Dann müsste man den Server eben so coden, dass er nur ein Paket nimmt, das verarbeitet, beantwortet und erst danach weiter arbeitet.
-
Buffer Overflow heisst direkt übersetzt Puffer Überlauf, nix mit infizieren^^ Jedesmal wenn in einem Puffer ausserhalb der vorgesehenen Grenzen schreibt spricht man von Buffer Overflow. Deswegen ist so gesehen ein Buffer Overflow das Mittel des DoS;)
-
Jo, das tolle ist nur, das es dabei um Puffer auf dem Stack geht,
da er nach unten wächst, wird beim buffer overflow evtl. die Rücksprung adresse überschrieben.
puffer 0
...
puffer n-1
rücksprung eip
wenn der angreifer einen solchen puffer überlauf findet, legt er seinen pösen, pösen code im puffer ab und überschreibt dazu noch die Rücksprungadresse. mit dem Anfang des Puffers,
beim rücksprung aus der Funktion wird dann der Code im puffer ausgeführt!
beim amd64 kann das verhindert werden, indem man für den stack das nx-bit setzt.
Abschmieren tut der Prozess/Thread dann trotzdem, aber der Code wird nicht ausgeführt.
Bei heap overflows wird meistens nur der Heap corrupted und das Programm macht auch Latte, aber das Code auf dem Heap ausgeführt wird, ist sehr unwahrscheinlich, man bräuchte ja erstmal wieder einen buffer overflow, um den Control Flow dahin zulenken.
Wie gesagt, möglichst nicht soweit kommen lassen, immer sauber Programmiernen ;-)
MfG
DDR-RAM
-
Was du meinst heisst aber Stack Overflow nicht Buffer Overflow:P
-
Ehm, nein, sogar im Studium hiess das auch Buffer Overflow - abgesehen das die ganzen Buffer Overflow die man evtl. auf heise.de findet zum Code einschleusen immer solche Fehler sind.
-
Dann sind meine Begriffsdefinitionen mal wieder Spezifischer und genauer als die der anderen juhu.
Aber nicht alles was man im Studium lernt muss zweifelsfrei ja auch richtig und sinnvoll sein^^
-
stack overflow ist etwas ganz anderes ;-)
Ein stack overflow ist wenn man versucht über das ende des Stacks hinaus zuschreiben, also mehr als überhaupt virtuell reserviert wurde.
MfG
DDR-RAM
-
Dann ist bei eurem Buffer Overflow aber das Wort Overflow irgendwie fehl am Platz
-
wieso, der Puffer liegt auf dem Stack, sonst ist er keine große Gefahr, für code ein schleusungen.
Er ist z.B. 2048 Bytes groß.
Warte mal, lieber bsp ^^
void ZeigeMalNenBOV(char* pStr)
{
char einPuffer[2048];
MacheEtwas(strcpy(einPuffer, pStr));
}
asm-code ca:
ZeigeMalNenBOV:
mov eax, [esp + 4]
sub esp, 2048 ; bzw. alloca/_chkstck
mov edx, esp
push eax ; 2.arg zuerst?
push edx
call strcpy
push eax
call MacheEtwas
add esp, 2060
ret ; wenn buffer überlauf, dann steht hier irgendein wert, aber nicht der richtige ^^
Wenn pStr jetzt länger ist als 2047 Zeichen (+1 '\0'), dann wird die rücksprungadresse überschrieben, da der Puffer überläufen wird!
MfG
DDR-RAM
-
Nein, weil dein Puffer, den du halt auf dem Stack allokiert hast, overflowed wird *g*. Mit dynamischem Speicher lässt sich "weniger" anfangen was exploits angeht, aber nen statisches Array auf dem Stack ist so schön simpler ^^
EDIT: Da war einer schneller als ich! :P
-
Wer nen Puffer unbedingt Im Stack anlegen muss ist selbst Schuld wenns abschmiert. Aber ich brauche doch gar keinen Puffer um die Rücksprungadresse zu zerhauen.
funktion:
push irgendwas
ret
Da stimmts auch nicht mehr. Selber Effekt aber nix mit Puffer
-
Und nix mit Datenpacket von aussen. Wenn du nun ein Packet einliest und den Wert auf den Stack pusht und ret machst - nun, das ist dann scheinbar der Sinn der Funktion. Die ist dann etwas dämlich, aber da fehlt immer noch der Angriff.
-
Wer nen Puffer unbedingt Im Stack anlegen muss ist selbst Schuld wenns abschmiert.
Lokale Variablen und demnach auch lokale Puffer werden meistens auf dem Stack abgelegt. Das ist halt so!
-
Wer nen Puffer unbedingt Im Stack anlegen muss ist selbst Schuld wenns abschmiert.
Klar ist der Programmierer der Anwendung Schuld, wenn er nicht überprüft, ob der Puffer überlaufen wird, aber es kam/kommt halt nicht so selten vor.
Und wenn der Puffer nicht auf dem Stack liegt, kommt es sehr häufig trotzdem zum Programm absturz, bzw. zu undefinierten Verhalten.
Wenn der Puffer auf dem Heap liegt, dann wird der heap corrupted beim overflow.
Wenn der Puffer statisch ist, (also in der bss-section), dann werden andere Daten überschieben.
MfG
DDR-RAM
-
Bei dem Heap gibts ja die Möglichkeit von BOUND, nur C nutzt die zu gunsten der Geschwindigkeit nicht. Delphi nutzt BOUND z.b.
-
bound ist doch absolut fürn arsch, wenn man nicht sicher ist, ob es der index stimmt, dann überprüft man ihn einfach, das geht auch ohne Bound, nur schneller.
Und wenn man sicher ist, das der Index stimmt, dann ist der BOUND-Befehl sehr fehl am Platze!
MfG
DDR-RAM
-
Um Bound zu benutzen musst du auch wissen wie lang der Puffer ist, und an nem simplem Pointer, der am besten noch aus nem long wert initialisiert wurde, kannst du dies in der Regel nicht ablesen. Da muss man schon einiges intern tun damit das klappt.
-
Es ist nur in C so, das Arrays NUR aus einem Pointer bestehen.
Delphi legt die Grenzen ab, damit kann BOUND verwendet werden. Da muss keine Zusätzliche Arbeit gemacht werden. Wenn man long [128] weisst man halt, dass der Array 512 Byte gross ist. Bei dynamischer Verwaltung steht das in den Headern drin. Ich sage ja auch nicht, dass BOUND die beste Möglichkeit ist, aber es ist eben eine.
-
Wir sind ja hier auch bei Lowlevel und nicht in einem Delphi-Forum :D
Ne, aber mal ohne hass,
ich bin nicht so der Fan von Pascal-artigen Sprachen.
Modula-2 hatte ich in Informatik in der Schule.
Ich kann mit umgehen, aber mögen tue ich es nicht.
Und wie gesagt, das kann man sich ja nachbauen, wenn man es denn möchte. C/C++ lassen dem Programmierer halt mehr Spielraum, irgendwas kaputt zu machen, aber wenn man es kann, dann macht man nichts kaputt.
MfG
DDR-RAM
-
Hi,
die einfachste Methode ist doch Code,Daten und Stack zu trennen!
Also 3 Deskriptoren pro App in unterschiedlichen Bereichen. So hat man
(fast) keine Möglichkeit mehr Code einzuschleusen.
*BSD macht das doch so, soweit ich weiß.
Und da soll nochmal einer sagen Segmentierung sei scheiße :)
Gruß GhostCoder
-
ja, das schrieb ich schonmal so ähnlich, gucksu seite 1 ;-)
Aber mit Segmentierung, wird das Ganze komplexer, außerdem hat man dann wieder near und far pointer *iieeehh*
Dadurch wird alles unübersichtlicher und auch langsamer.
MfG
DDR-RAM
-
Hiho,
ups, überlesen :)
Also komplexer wird es wohl kaum, du musst ja nur wissen, wie groß der Code ist, dann .data+.bss ist die Größe vom Data Segment und den Stack ja variabel.
Nachdem du den ELF Header eingelesen hast, wäre das Segment Setup drei Zeilen "komplex" :)
Near und Far sind ja egal, dazu sind ja die Default Prefixes da... Eigentlich musst du überhaupt nichts ändern.
Ob ich jetzt
mov eax,[esp-4]
oder
mov eax,[ss:esp-4]
schreibe ist ja egal. Gut, EBP könnte Probleme bereiten, hab aber keine Lust nachzugucken jetzt :)
Gruß GhostCoder
-
Also, ein Programm, das für flat segmente compiliert wurde, kann nicht mit non-flat segmenten arbeiten, das geht nicht.
Es nimmt ja an, das cs-base = ds-base = es-base = ss-base = 0 und
das cs-limit = ds-limit = es-limit = ss-limit = FFFF FFFF gilt.
Wahrscheinlich würde es noch laufen, wenn die base nicht 0 ist, aber alle segment-bases gleich. aber wenn die segment-bases unterschiedlich sind, wird es nicht mehr funktionieren, da eine Struktur die aufm stack liegt, nen 48-bit pointer benötigt
Beispiel:
C-Code
void foo(int* p)
{
*p = 4;
}
int bar()
{
int x;
foo(&x);
return x;
}
asm-code
foo:
mov eax, [esp+4] ; implizit ss
mov dword ptr [eax], 4 ; implizit ds
ret
bar:
sub esp, 4
push esp
call foo
mov eax, [esp + 4] ; implizit ss
add esp, 4
ret
(so ungefähr)
Der Knackpunkt ist, das für esp nen anderer default-selektor nimmt, als eax. Es müssten die selektoren mit übergeben werden.
foo:
mov ecx, [esp+8]
mov eax, [esp+4]
mov gs, cx
mov dword ptr gs:[eax], 4
ret
bar:
sub esp, 4
mov edx, esp
push ss
push edx
call foo
mov eax, [esp + 4]
add esp, 8
ret
edit:
außerdem bräuchte man wahrscheinlich noch ldt's, falls man auch sehr viele prozesse unterstützen möchte und das ist ein erheblicher mehraufwand.
und amd64 unterstützt auch nur noch flat-segmentierung (außer bei fs und gs, wegen thread-local von win)
MfG
DDR-RAM
-
und amd64 unterstützt auch nur noch flat-segmentierung (außer bei fs und gs, wegen thread-local von win)
Find ich eigentlich schade, Segmentierung hat echt seine Vorteile. Sicherheit, wie gesagt, aber auch im Microkernel gibt dir das extreme Geschwindigkeitsvorteile, weil du ja keine Pages mehr rumschieben musst, sondern einfach nur base+offset addierst, und kopierst.
Gruß GhostCoder