Stack Overflow Buffer Overflow

TyRoXx

Ja, gets kennt die Länge von 'var' nicht. Das gleiche mit Längenprüfung:

fgets(var, sizeof(var), stdin);

Ah ok danke.

Was passiert, wenn man über einen Buffer hinausschreibt, der auf einem Stack liegt?

Bufferoverflow

blub* 0

TyRoXx schrieb:

void stack_overflow(int i)
{
	return stack_overflow(i); //bei jedem Aufruf kommt ein int auf den Stack dazu
}

Du musst das int nichtmal reinpacken.
Bei jedem Funktionsaufruf wird genug auf den Stack geschoben, der läuft auch so über. Braucht halt ein paar Aufrufe mehr.

hustbaer

Stack vs. Buffer schrieb:

Was passiert, wenn man über einen Buffer hinausschreibt, der auf einem Stack liegt?

Wenn du über einen Puffer hinausschreibst (zu grosser positiver Index/Offset), überschreibst du die Daten die am Stack (logisch gesehen) vor dem Puffer liegen, da der Stack üblicherweise rückwärts wächst.

Daher ist es ja auch möglich die Rücksprungadresse zu überschreiben, wenn man einen Unchecked Buffer in einem Programm gefunden hat.

Bei einem Stack-Overflow werden dagegen meist keine Bereiche überschrieben wo andere Daten stehen sollten, sondern es wird einfach zuviel Stack verbraucht.

hustbaer schrieb:

Bei einem Stack-Overflow werden dagegen meist keine Bereiche überschrieben wo andere Daten stehen sollten, sondern es wird einfach zuviel Stack verbraucht.

quark, bei nem stack over- oder underflow rauscht der stackpointer über die 0 hinweg. bei 'nem 'push' z.b. würden dabei daten am anderen ende des stackspeichers überschrieben.

hustbaer

;fricky schrieb:

hustbaer schrieb:

Bei einem Stack-Overflow werden dagegen meist keine Bereiche überschrieben wo andere Daten stehen sollten, sondern es wird einfach zuviel Stack verbraucht.

quark, bei nem stack over- oder underflow rauscht der stackpointer über die 0 hinweg. bei 'nem 'push' z.b. würden dabei daten am anderen ende des stackspeichers überschrieben.

hör bitte auf blöd rumzutrollen

hustbaer schrieb:

;fricky schrieb:

hustbaer schrieb:

Bei einem Stack-Overflow werden dagegen meist keine Bereiche überschrieben wo andere Daten stehen sollten, sondern es wird einfach zuviel Stack verbraucht.

quark, bei nem stack over- oder underflow rauscht der stackpointer über die 0 hinweg. bei 'nem 'push' z.b. würden dabei daten am anderen ende des stackspeichers überschrieben.

hör bitte auf blöd rumzutrollen

man seid ihr dumm

hustbaer schrieb:

hör bitte auf blöd rumzutrollen

ich bin bei deinem geschreibsel schon sehr rücksichtsvoll, indem ich meistens nix dazu sage, aber diesmal hast du nahezu 100%igen quatsch von dir gegeben, so dass ich einfach nicht anders konnte.

mgewünschte schrieb:

man seid ihr dumm

wie sieht denn deine sichtweise von stack-overflows aus?

;fricky schrieb:

mgewünschte schrieb:

man seid ihr dumm

wie sieht denn deine sichtweise von stack-overflows aus?

Ihr benehmt euch wie 13 Jährige und seid beide doch schon über 30.

mgewünschte schrieb:

Ihr benehmt euch wie 13 Jährige und seid beide doch schon über 30.

na und? wir sind nun mal geistig jung geblieben. ich bin in der tat über 30. wie alt husti ist, weiss ich nicht. schätze aber, er ist nicht älter als 25 oder jenseits der 50.

hustbaer

;fricky schrieb:

hustbaer schrieb:

hör bitte auf blöd rumzutrollen

ich bin bei deinem geschreibsel schon sehr rücksichtsvoll, indem ich meistens nix dazu sage, aber diesmal hast du nahezu 100%igen quatsch von dir gegeben, so dass ich einfach nicht anders konnte.

und an meinen angeblichen quatsch schreibst du eine erklärung, die in der steinzeit der computertechnik mal wahr war.
toll.
heute ist der stack nichtmehr bei 0 aus, sondern irgendwo, fricky.
der stack-pointer ist üblicherweise ein ganz normales (adress-)register, mit dem der gesamte speicher des systems adressiert werden kann. sogar ein popeliger ARM oder 68000er macht das so, und erst recht jeder PC.

und einen stack-overflow gibt es daher auch lange bevor der stack-pointer den wert 0 erreicht hat. dazu verwendet man dann guard-pages, um abzusichern, dass so ein fehler nicht still passiert. uswusf.

aber ignorier ruhig weiter die realität.

hustbaer schrieb:

heute ist der stack nichtmehr bei 0 aus, sondern irgendwo

ein stackpointer beginnt normalerweise schon bei 0. wo nun physikalisch der speicher des stacks beginnt, ist eine andere sache.

hustbaer schrieb:

der stack-pointer ist üblicherweise ein ganz normales (adress-)register, mit dem der gesamte speicher des systems adressiert werden kann. sogar ein popeliger ARM oder 68000er macht das so, und erst recht jeder PC.
und einen stack-overflow gibt es daher auch lange bevor der stack-pointer den wert 0 erreicht hat. dazu verwendet man dann guard-pages, um abzusichern, dass so ein fehler nicht still passiert.

und popelige PCs haben auch noch stack segment register und können stacks automatisch umschalten usw. oder manche prozessoren haben spezielle register, die ober und untergrenze eines stacks festlegen, bei deren überschreitung eine exception ausgelöst wird. und dann gibts prozessoren, die überhaupt kein stack-konzept kennen und wo man stacks in software machen muss usw. da gibts alles mögliche, nur nichts davon passt irgendwie richtig zu deinem wirren satz:

Bei einem Stack-Overflow werden dagegen meist keine Bereiche überschrieben wo andere Daten stehen sollten, sondern es wird einfach zuviel Stack verbraucht.

was heisst denn z.b.: 'es wird zuviel stack verbraucht'?

erik.vikinger

Hallo,

ein stackpointer beginnt normalerweise schon bei 0.

Nein, auch im virtuellen (linearen) Speicher liegt der Stack nicht bei 0, noch an irgendeiner anderen vordefinierten Stelle, sondern wird vom OS, mehr oder minder, frei in den virtuellen Process-Adress-Raum gelegt, schon für Multithreading muss es ja möglich das jeder Thread seinen Stack an einer anderen Stelle im gemeinsamen virtuellen Process-Adress-Raum bekommt. Der Stack könnte z.B. bei 0x7DFFFF00 losgehen und bis 0x7D001000 runter wachsen dürfen. Die 4k-Page an 0x7D000000 währe dann eine "guard-page". Wenn dort zugegriffen wird entspricht das einem Stack-Overflow und der Process wird vom OS gekillt. Alle anderen Pages dazwischen werden vom OS kommentarlos mit echtem Speicher gemappt falls dort jemand zugreift, der Thread benötigt eben diesen Stack und fertig. Die Page an 0x7DFFF000 wird sofort mit echten Speicher versehen damit der Thread loslaufen kann.

und popelige PCs haben auch noch stack segment register

Die Segment-Register werden aber heutzutage (leider) nicht mehr benutzt. Stattdessen legt man alles vom Process in einen flachen/linearen Adress-Raum. Damit sind die tollen Schutzmöglichkeiten die Segmentierung bieten kann ausgehebelt und alles geht über das Paging das dann auch den Speicherschutz bieten muss. So machen das alle mir bekannten Betriebssysteme auf allen mir bekannten Plattformen.

manche prozessoren haben spezielle register, die ober und untergrenze eines stacks festlegen, bei deren überschreitung eine exception ausgelöst wird

Das ist ein nettes Zusatzfeature ändert aber nichts an der grundsätzlichen Funktionsweise.

und dann gibts prozessoren, die überhaupt kein stack-konzept kennen und wo man stacks in software machen muss

z.B. ARM, und? Trotzdem funktioniert das alles mit Hilfe des Paging ganz genau so wie bei allen anderen Plattformen auch.

was heisst denn z.b.: 'es wird zuviel stack verbraucht'?

Das ist dann ein Stackoverflow.

Grüße
Erik