Diskussion:Pufferüberlauf

message: Gäbe es grundsätzliche Argumente, die gegen die Verschiebung zur deutschen Bezeichnung Pufferüberlauf sprächen? Stern 20:53, 22. Jun 2004 (CEST)
replies: text: hmm - der google-score (sic) ist ca. 40,000 zu ca. 10,000 für buffer overflow. aber prinzipiell dagegen wäre ich nicht. grüße, Hoch auf einem Baum 05:28, 23. Jun 2004 (CEST)
replies: text: der google-score für "buffer overflow" ist 1,390,000 - nicht nur das spricht für eine Rückkehr zum Titel "Buffer Overflow" - ich höre den Begriff Pufferüberlauf so gut wie nie, ich glaube, er ist allgemein nicht besonders gebräuchlich. Drhankey 19:29, 2. Aug 2005 (CEST)
replies: text: Unter Script-Kiddies vielleicht nicht. Richtige Programmierer sprechen schon noch oft ihre Muttersprache. --213.221.250.85 18:18, 7. Dez. 2010 (CET)

text: mE spricht auch nichts dagegen, solange der Begriff Buffer Overflow im Artikel nicht vollständig getilgt wird (was hier aber wohl nicht zur Debatte steht). lg --Hubi 08:43, 23. Jun 2004 (CEST)

text: Von mir aus gerne, solange weitergeleitet wird... Mh 20:19, 17. Jul 2004 (CEST)
replies: text: Ist erledigt. Man müsste im Text nochmal die Buffer Overflows durch Pufferüberläufe ersetzen. Stern 20:23, 17. Jul 2004 (CEST)

text: Meiner Meinung nach ist Puffer Überlauf nicht gebräuchlich, ich arbeite seit Jahren im IT Security Bereich und habe heute den Begriff das erste Mal gehört, wenn tatsächlich jemand nach Pufferüberlauf sucht sollte er hierher verwiesen werden, aber der Artikel sollte Buffer Overflow heißen. Nicht jedes Wort sollte eingedeutscht und übersetzt werden, es macht hier einfach keinen Sinn -anonym - 10. APR 2010 (nicht signierter Beitrag von 91.113.93.112 (Diskussion | Beiträge) 15:05, 10. Apr. 2010 (CEST)
replies: text:  Blos weil man im IT-Bereich immer wieder Anglizismen verwendet, ist es nicht nötig, diese schlechte Angewohnheit hier zu übernehmen. Pufferüberlauf ist das korrekte deutsche Wort dafür. --PaterMcFly Diskussion Beiträge 19:20, 10. Apr. 2010 (CEST)
replies: text: So ist es. Bei uns in der Firma ist "Puffer" (und damit auch "Pufferüberlauf") außerdem wesentlich gebräuchlicher als "Buffer". Ich denke nicht, dass die Anzahl von Google-Treffern eine Rolle spielt. Und wenn überhaupt, müßte man die Suche auf deutschsprachige Seiten einschränken. Dass ein Brite oder Amerikaner nicht "Puffer" sagt, finde ich irgendwo logisch. :) Wenn man nur deutsche Seiten sucht steht es aktuell 54900 zu 51200 FÜR "Pufferüberlauf". Ha! --213.221.250.85 18:18, 7. Dez. 2010 (CET)
thread_title:  Benennung 

message: *Overflows mit hilfe von umgebungsvariablen (wenn der Buffer zu klein ist)
: Vielleicht solltest Du dann etwas dazu schreiben, da man sonst bestenfalls raten kann, was Du damit meinst. --Cyclonus 23:36, 17. Jul 2005 (CEST)
thread_title:  Was in dem Artikel noch fehlt 

message: im artikel steht, das der stack bei aufruf von gets so aussieht:
Rücksprungadresse	
1000. Zeichen    	
...              	
3. Zeichen       	
2. Zeichen       	
1. Zeichen       	\leftarrowStackpointer
aber gets nimmt als parameter nicht line[] selber sonden den zeiger darauf an. (steht ja auch in dem kommentar  /* gets erhält Zeiger, keine Überprüfung */) also steht imho hinter der rücksprungadresse nur der zeiger. so kann auch kein pufferüberlauf entstehen. wenn ich das falsch sehe bitte ich um aufklärung.
: Ja, das ist so falsch. Allerdings liegt line[] natürlich auch auf dem Stack, da es sich um eine lokale Variable handelt. Allerdings müsste sie nach der Beschreibung oberhalb der Rücksprungadresse liegen. Wächst der Stack nach oben ist es fast richtig, nur fehlt dann der Zeiger zwischen line[] und der Rücksprungadresse. --Cyclonus 23:14, 17. Jul 2005 (CEST)
replies: text:  Mit Rücksprungadresse ist hier (wahrscheinlich) nicht die Adresse zur Rückkehr aus gets() sondern der aus input_line() gemeint. Die Position des Stackpointers ist dann allerdings verwirrend, da der auf lokale Variablen oder den Parameter von gets() zeigen sollte. --Cyclonus 23:23, 17. Jul 2005 (CEST)
replies: text:  Gemeint ist wohl der Stack vor dem Aufruf von gets() und nach dem Rücksprung. Hab's klarer formuliert.--Gunther 11:22, 15. Sep 2006 (CEST)
thread_title:  Fehler im Artikel? 

message: In diesem Artikel und Heap Overflow waren momentan quasi die gleichen Texte. Ich habe aus Heap Overflow wieder einen Redirect gemacht. Meinetwegen kann man den Artikel auch wieder auslagern, aber zwei mal der gleiche Inhalt kann nur schief gehen ;-) --Boris23 18:48, 20. Dez 2005 (CET)
replies: text: Ich bin eher für Auslagern. Stern 13:17, 7. Mär 2006 (CET)
thread_title:  [[Heap Overflow]] 

message: Ich meine man kann sowas wie ein Buffer Overflow auch erzeugen in dem man einen Pointer auf einem vom Betriebssystem genutzten Adressraum Bzw, Adresse zeigen lässt (Bei windows). Ist das richtig? Ist das auch ein Bufferoverflow oder was anderes? مبتدئ 17:45, 3. Apr. 2007 (CEST)
thread_title:  Frage 

message: Im Artikel wird die Sicherheit in C++ ja ziemlich niedergeschmettert:
"Daneben stellt der (im Falle von C++) komplexe Sprachumfang und die Standardbibliothek sehr viele fehleranfällige Konstrukte zur Verfügung, zu denen es in vielen Fällen kaum eine Alternative gibt."
"Im Fall von C und C++ enthält die Standardbibliothek eine Anzahl von gefährlichen Funktionen, die zum Teil gar keine sichere Verwendung zulassen und zu denen zum Teil keine Alternativen bestehen."
Bei C sehe ich es ja ein, aber wenn man modernes C++ programmiert (also keinen blanken Zeiger, C-Arrays oder Ähnliches), wo sind denn da die fehleranfälligen Konstrukte? Klar, der C-Teil von C++, aber wenn's nur das ist, sollte man das doch klarstellen, oder nicht?
So, hab's ein bisschen geändert und es hat anscheinend auch die Sichtung überstanden :-) Geändert hab ich den mittleren Teil der Sektion "Programmiersprachen", für Näheres siehe http://de.wikipedia.org/w/index.php?title=Puffer%C3%BCberlauf&diff=55252202&oldid=54652267 -84.58.131.126 01:59, 13. Jan. 2009 (CET)
thread_title:  Sicherheit in C++ 

message: Die Seite hat etwas Schieflage. Im Gegensatz zur Heap-Verwaltung gehört der "Stack Overflow" m.E. zunächst zur Hardware, erst dann zu Programmiertechniken (auch wenn C nicht ohne Pointer auskommt). 
"Stack Overflow" (besser eigentlich "Stack Underflow" oder "Underrun") hat vor C zunächst etwas mit Hardware zu tun. Es ist ein Grundproblem bei der Arbeit in Assembler. Der Stack Pointer wird beim Einstieg (RCALL irgendwas) in ein Unterprogramm (in Hardware) erniedrigt (er läuft im RAM von oben nach unten), beim Ausstieg mit RET oder RETI wird er wieder erhöht. Das geht vollautomatisch, i.a. ohne daß der Programmierer darauf Einfluß nimmt.
Im Bereich der Winzlinge der Embedded Controller (z.B. ATMEL ATtiny, Microchip PIC12 etc.) programmiert man auch in Zukunft in Assembler. Man spart sich Probleme, die ein Compiler verursacht und ist code-effizienter. Der Stack solcher Prozessoren wird meist in Hardware verwaltet. Und genau hier passieren die dümmsten Fehler, da noch immer ein Programmierstil mit relativen Sprüngen (RJMP) gelehrt wird, der Stack Overflows geradezu provoziert. 
Ein Problem entsteht immer dann, wenn man mit RJMP aus einem Unterprogramm herausspringt, aber nie wieder dorthin zurückkehrt. Der Stack füllt sich jedesmal ein Stück, wenn dieser Fehler auftritt. Irgendwann sind dann die paar Byte RAM voll: Stack Overflow und Absturz.
Nur wenn man sich an eine sauber gekapselte Unterprogramm-Struktur hält, wird man solche Fehler, die gemeinerweise oft erst nach einigen Stunden auftreten, meistern. 
:;RCALL beispiel   ; Aufruf eines Unterprogramms
::...
:;beispiel:  ; Beginn des Unterprogramms
::...
:;RET   ; Ende des Unterprogramms
Es gibt sogar eine Eselsbrücke: Wenn im Programm nur ein einziges RJMP vorhanden ist - nämlich in der mainloop, dann ist Stack-Overflow ausgeschlossen. 
(Die Mainloop sieht bei den Winzlingen oft so aus:
:;mainloop:	   ; hier verweilen und auf Interrupts warten
::WDR	   ; Watchdog Reset verhindern, wenn alles OK
:;RJMP mainloop
)
Mit PUSH und POP sichert man übrigens das Statusregister (ATMEL: SREG) zu Beginn einer Interrupt-Behandlung. Auch wichtig für saubere Arbeit. Einziges Problem in Assembler: Alle Register sind "static". Um den Überblick zu behalten, benutzt man besser nicht die tatsächlichen Registernamen, sondern eigene Kreationen (Beispiel .DEF meinreg = r19).
-- Heinzelmann 13:03, 1. Apr. 2009 (CEST)
replies: text: Was du hier beschreibst, ist auch ein Stack-Überlauf. Rein von der wörtlichen Bedeutung des Namens ist es eigentlich auch die richtigere Bedeutung – leider ist es aber so, dass auch die Angriffsart denselben Namen bekam. Gut, bei ihr wird auch ein Stack überschrieben, aber er läuft nicht über im klassischen Sinne. --Uncle Pain 15:58, 1. Apr. 2009 (CEST)
replies: text:  Die Bezeichnung Stack-Überlauf wird im Artikel gar nicht verwendet. Es geht um Heap-Überläufe (also das Überschreiten von Heap-Speicherbereichen) und andere Puffer-Überläufe (die mit lokalen Variablen auch auf dem Stack passieren können). Ein Stacküberlauf ist, wie du richtig erwähnt hast, etwas anderes. Der häufigste Fall dafür ist übrigens ein ganz trivialer, der auch in Hochsprachen auftritt: Nicht terminierende Rekursion. -- PaterMcFly Diskussion Beiträge 16:48, 1. Apr. 2009 (CEST)
replies: text:  Huch, mir fiel gar nicht auf, dass der Begriff im Artikel gar nicht vorkommt :) Damit verstehe ich Heinzelmanns Einwand noch weniger. Wobei ich sagen muss, wenn man bei den Pufferüberlauf-Angriffen u. A. vom Heap-Überlauf spricht, wäre es auch konsequent, den Pufferüberlauf auf dem Stack auch als Stack-Überlauf zu bezeichnen. In meinen Augen ist Überlauf aber generell irgendwie das falsche Wort; Überschreibung oder Grenzüberschreitung fände ich passender. --Uncle Pain 10:50, 2. Apr. 2009 (CEST)
replies: text:  Ja, eigentlich schon. Wobei der Artikel ja "Pufferüberlauf" heisst, und dieser Begriff ist IMHO ja schon korrekt. Falsch oder zumindest unpräzise sind die Begriffe "Stack-Überlauf" und "Heap-Überlauf", wobei ich mir gar nicht so sicher bin, ob das hier beschriebene Phänomen tatsächlich so bezeichnet wird. Als Heap-Überlauf würde ich nämlich viel mehr einfach ein triviales "Kein Speicher mehr" bezeichnen. Man müsste belege für diese Begriffe in dem hier erwähnten Zusammenhang finden. -- PaterMcFly Diskussion Beiträge 16:41, 2. Apr. 2009 (CEST)
replies: text:  Die englische WP hat das irgendwie ulkig gelöst, die unterschieden zwischen „stack overflow“ als Stacküberlauf im eigentliche Sinne und „stack buffer overflow“ als die Überschreibung/Überschreitung. Nicht nachahmenswert, wenn ihr mich fragt. --Uncle Pain 17:37, 2. Apr. 2009 (CEST)
replies: text:  Ich wurde hierher von Stack overflow weitergeleitet und meine Reaktion darauf war WTF??? Ein Stack overflow ist primär die Ausschöpfung des Stacks durch zu viele lokale Variablen oder, häufiger, zu tiefgehende Rekursion - offengestanden ist mir der Begriff noch nie in anderem Sinne untergekommen bis zu diesem redirect. Auch ein Heap overflow ist primär die Ausschöpfung des zur Verfügung stehenden Speichers. Ich halte dafür, dass das sogar die einzige korrekte Verwendung des Ausdrucks ist (also auch ein Fehler in der englischen wikipedia). Beides ist wohl zu unterscheiden von einem Pufferüberlauf (der, mit unterschiedlichen Konsequenzen, sowohl im Stack als auch im Heap auftreten kann). Auch wenn die Lösung der englischen WP nicht optimal sein mag, ein redirect von Stack overflow zu Pufferüberlauf ist eklatant falsch. --92.76.248.112 01:55, 25. Nov. 2009 (CET)
thread_title:  Stack Overflow? 

message: Es gibt auch Gegenmaßnahmen auf Hardwareebene. Siehe SRAS (http://palms.ee.princeton.edu/PALMSopen/lee03enlisting.pdf) wäre nett wenn Diese und Andere auch hinzugefügt werden könnten. (nicht signierter Beitrag von 92.117.236.50 (Diskussion | Beiträge) 10:54, 20. Feb. 2010 (CET)
thread_title:  Gegenmaßnahmen 

message: Ich habe den Artikel durchgelesen und dann die Diskussion überflogen - wie immer gibt es dort ein hin und her. Liebe Leute,entschuldigung das ich das so brachial sage: Heap overflow, Buffer-overflow und Stack-overflow sind drei vollkommen verschiedene Themen und gehören folglich in drei verschiedene Artikel. Das gemeinsame an ihnen ist nur, dass es schlimm ist, wenn der Overflow auftritt. 
Kurzdarstellung:
* Buffer-Overflow entspricht am ehesten dem, was der Artikel beschreibt, man kann das also so stehenlassen. Pufferüberlauf als deutscher Begriff ist m.E. auch OK
* Heap-Overflow ist das Ausgehen des Speichers im Heap. Überlaufen bezieht sich nicht auf das direkte Überschreiben des Speichers, sondern die Anforderungen an den Speicher sind zu groß, der Speicher geht aus. Man muss sich nicht an der wörtlichen Bedeutung festhalten. Dort gibt es das Problem der Fragmentierung. Da das Theme im Artikel Dynamischer Speicher erläutert ist, meine ich, dass man ggf. nur einen kleinen Artikel für Heap-Overflow braucht, der dann im wesentlichen auf den Dynamischer Speicher-Artikel verweist.
* Stack-Overflow (bitte nicht verwirrend und erbsenzählend von underflow reden) ist ein ganz anderes und wichtiges Problem: Stackbedarf einer Anwendung. Diese ist schwer abschätzbar, kann dann doch anders als erwartet ausfallen (abhängig von Anwenderprorammierung) und stellt daher oft ein Problem dar. Reichlich Stack bereitstellen ist erstmal immer richtig, löst aber die Probleme nicht.
Die Gefährlichkeit des Buffer-Overflow ist m.E. in Abhängigkeit von Programmiersprachen und -stilen gut dargestellt, kleine Verbesserungen kann es da geben. Übrigens: Ein Bufferoverflow in einem Speicherbereich, der im Heap liegt, ist dann nicht ein Heap-Overflow sondern etwas viel schlimmeres: Die gesamte Heap-Verwaltung wird lahmgelegt. Es ist aber ein schnöder programmschusseliger Buffer-Overflow.   
--HartmutS 08:31, 9. Apr. 2010 (CEST)
replies: text: Ja, volle Zustimmung, ich habe lang keine IT-Themen mehr angesehen, weil ich von der Qualität nicht gerade begeistert bin, aber dass Stack Overflow hierher einfach redirected, ist schon erbärmlich. Im übrigen finde ich den dt. Begriff "Pufferüberlauf" schlecht, "buffer overrun" beschreibt zudem besser was passiert im Vergleich zu "buffer overflow". Damit wäre dann auch klar, dass die Overflows eigentlich ein "out of xxx space" sind und der "buffer overrun" etwas anderes, nämlich ein unerkanntes über den eigentlich Speicherbereich hinausgehendes schreiben.--Cactus26 (Diskussion) 17:30, 20. Jun. 2013 (CEST)
replies: text:  Ja, ebenfalls vollste Zustimmung! Mit einem Buffer Overrun einer lokalen Variable zerschreibe ich mir den Stack, aber ein Stack Overflow ist was völlig anderes. --Carl B aus W (Diskussion) 14:19, 20. Mai 2017 (CEST)
thread_title:  Drei verschiedene Themen Heap/Stack/Buffer-Overflow 

message: Der folgende Abschnitt:
"Mit dem Protected Mode, der beim 80286 eingeführt wurde, lässt sich durch die Segmentierung des linearen Speichers der Programm-, Daten- und Stapelspeicher physikalisch voneinander trennen. Der Zugriffsschutz erfolgt über die Speicherverwaltungseinheit der CPU. Das Betriebssystem muss nur sicherstellen, dass gleichzeitig nicht mehr Speicher zur Verfügung gestellt wird, als der lineare Adressraum groß ist. Als einziges weitverbreitetes Betriebssystem nutzte OS/2 die Speichersegmentierung."
ist irreführend in dem er suggeriert OS/2 sei das einzige Betriebssystem mit Speicherschutz. Dies ist nicht korrekt da alle modernen Betriebssysteme einen Speicherschutz verwenden. Heute wird zusätzlich zur Seitenweise-Speicherverwaltung in der Regel auch die NX-Funktion (No eXecute, NX-Bit) welche das ausführen von Daten verhinder verwendet. Dies erzeugt zwar keine physische Trennung in Daten und Programmspeicher, sorgt aber richtig angewendet dafür das Speicherbereiche für Daten nicht ausgeführt werden können.
Falsch ist der Abschnitt in der Hinsicht, dass auch durch eine Segmentierung keine physikalische Trennung des Speichers entsteht.
Was der Satz "Das Betriebssystem muss nur sicherstellen, dass gleichzeitig nicht mehr Speicher zur Verfügung gestellt wird, als der lineare Adressraum groß ist." dabei mit dem Pufferüberlauf oder der Segmentierung zu tun haben soll ist mir leider völlig schleierhaft. (nicht signierter Beitrag von 2A02:908:F448:1960:DD3E:2798:9BA6:3231 (Diskussion | Beiträge) 22:10, 2. Mai 2014 (CEST)
thread_title:  Unbelegter teilweise falscher und irreführender Abschnitt 

message: – GiftBot (Diskussion) 20:44, 26. Nov. 2015 (CET)
thread_title:  {{Anker|deadurl_2015-10}} Defekter Weblink