Thema: Zum Thema Mikrokernel

[joachim_neu]

*g* Dann müsste man den Server eben so coden, dass er nur ein Paket nimmt, das verarbeitet, beantwortet und erst danach weiter arbeitet.

[Roshl]

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;)

[DDR-RAM]

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

[Roshl]

Was du meinst heisst aber Stack Overflow nicht Buffer Overflow:P

[Legend]

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.

[Roshl]

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

[DDR-RAM]

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

[Roshl]

Dann ist bei eurem Buffer Overflow aber das Wort Overflow irgendwie fehl am Platz

[DDR-RAM]

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

Code: [Auswählen]


void ZeigeMalNenBOV(char* pStr)
{
char einPuffer[2048];

MacheEtwas(strcpy(einPuffer, pStr));
}

asm-code ca:

Code: [Auswählen]


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

[Legend]

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!

[Roshl]

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

[Legend]

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.

[n3Ro]

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!

[DDR-RAM]

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

[Roshl]

Bei dem Heap gibts ja die Möglichkeit von BOUND, nur C nutzt die zu gunsten der Geschwindigkeit nicht. Delphi nutzt BOUND z.b.

[DDR-RAM]

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

[Legend]

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.

[Roshl]

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.

[DDR-RAM]

Wir sind ja hier auch bei Lowlevel und nicht in einem Delphi-Forum
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

[GhostCoder]

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