Diskussion:Pufferüberlauf

Erste Anmerkungen

Ich habe gerade Assembler aus der Liste der besonders gefährlichen Programmiersprachen gelöscht, weil Assemblersprache einem im Gegensatz zu C/C++ volle Kontrolle über die CPU, also auch Aufruf- und Übergabekonventionen, Überlaufflags usw., an die ich in C nicht drankomme, gibt, sodaß ein Programmierer, der weiß, was er tut, damit weniger falsch machen kann als mit C/C++. Mh 20:09, 22. Jun 2004 (CEST)

Das halte ich so für Blödsinn. Wer weiß, was er tut hat demnach mit gar keiner Programmiersprache (Sicherheits-)Probleme. Der Sicherheitsvorteil höherer Sprachen (als C und C++) liegt doch darin, dass diese den Zugriff auf solche Details gar nicht erst ermöglichen. Die Gefahr Fehler zu machen ist doch bei Assembler noch wesentlich höher als bei C. --Cyclonus 23:36, 17. Jul 2005 (CEST)

Ich gebe Mh da recht, denn die gefährlichsten C/C++ Programmierer sind die, die von wesentlich weiter abstrahierenden Sprache(n) auf C/C++ umgeschult wurden (eg. Cobol, Ada, Pascal, Oberon), aber wie so oft, nur halbherzig. Wer aber von Assembler oder Fortran (also nicht Fortran95, sondern Fortran) mehr versteht, als nur, das es cool ist, der weiß auch um die Effekte von Pointern, kennt negative Indizes und weiß vor allem, was man wo wie machen kann. Allerdings kann man mit Assembler in den falschen Händen noch viel mehr falsch machen, als in C oder C++ - vor allem, wenn einem dank "managed C++" vom Visual Studio .net eine trügerische Sicherheit vorgegaukelt wird. -- Jens Rehsack, 13.12.06, 18:52 CET

Benennung

Gäbe es grundsätzliche Argumente, die gegen die Verschiebung zur deutschen Bezeichnung Pufferüberlauf sprächen? Stern 20:53, 22. Jun 2004 (CEST)

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)

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)

Unter Script-Kiddies vielleicht nicht. Richtige Programmierer sprechen schon noch oft ihre Muttersprache. --213.221.250.85 18:18, 7. Dez. 2010 (CET)

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)

Von mir aus gerne, solange weitergeleitet wird... Mh 20:19, 17. Jul 2004 (CEST)

Ist erledigt. Man müsste im Text nochmal die Buffer Overflows durch Pufferüberläufe ersetzen. Stern 20:23, 17. Jul 2004 (CEST)

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

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)

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)

Was in dem Artikel noch fehlt

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

Die "Zufallszahlbarriere" wird meines Wissens in Anlehnung an die Kanarienvogel, die Bergarbeiter mit in die Minenschächte nahmen, um durch deren Ableben auf gefährliche Gase hingewiesen zu werden, auch "Canary" genannt. --Anonymous

Fehler im Artikel?

im artikel steht, das der stack bei aufruf von gets so aussieht:

Rücksprungadresse
1000. Zeichen
...
3. Zeichen
2. Zeichen
1. Zeichen	$\leftarrow$Stackpointer

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)

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)

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)

Heap-Überlauf Beispiel

Habe soeben noch eine weitere Lösung zur Vermeidung eines Überlaufs hinzugefügt. Ist die Lösung mit strlen() überhaupt korrekt? IMHO gibt's da ebenfalls ein Problem, wenn die Nullterminierung im Eingangsstring fehlt. --Kasper4711 13:56, 16. Nov 2005 (CET)

Natürlich gibt es dann ein Problem. Nämlich dass strlen() theoretisch niemals fertig wird, irgendwann einen Absturz verursacht oder malloc() NULL zurückliefert. Eventuell sollte man alle Beispiele entfernen, schließlich ist Wikipedia nicht der Ort für Tutorials und auch keine gutgemeinten Ratschläge. Dass jemand aufgrund dieses Artikels seinen Code ändert halte ich für unwahrscheinlich, zumindest ist es dann sicher schon Hopfen und Malz verloren. Im Übrigen verursacht jede Variante einen Absturz, wenn s nicht auf ein gültiges Speicherobjekt zeigt oder dieser nicht als lesbar (z.B. write-only, execute-only) gemappt ist. Generell gilt, wenn die Interface-Spezifikation einen String verlangt, dann muss man auch einen String übergeben, d.h. dies durch den umgebenden Code sicherstellen. Wer "strlen(NULL)" oder "strlen(malloc(100))" schreibt, dem ist mit C nicht zu helfen. Bezüglich deiner Variante: Sowas wie "#define BUFSIZE 128" ist alles andere als ratsam, den String einfach so abzuschnippeln ist auch nicht wirklich sinnvoll und den Puffer mit Nullen aufzufüllen, das macht strncpy() doch schon. Du willst doch nur den String garantiert terminieren, dafür reicht "buf[BUFSIZE - 1] = 0;". Von den ganzen Low-Level-Varianten ist letztlich nur strlcpy() empfehlenswert. Letztlich gehörte diese Frickelei aber, glaube ich, nicht in eine Enzyklopädie und im echten Leben sollte man gefälliste eine vernünftige String-Bibliothek benutzen. --Cyclonus 08:20, 4. Dez 2005 (CET)

strlen(NULL) dürfte sogar noch "gut" gehen... Bzgl. strncpy und Nullterminierung hast Du natürlich Recht. Ich persönlich finde nix Anstössiges am #define BUFSIZE, ist IMHO gängige C-Praxis. Im echten Leben gibt's nicht immer eine "vernünftige" String-Bibliothek, und wenn, dann implementiert diese ja gerade die sicheren Operationen, um die es hier geht. Und strlcpy ist halt nicht überall vorhanden. Dennoch habe auch ich nichts gegen eine Entfernung der Beispiele einzuwenden. Andere Meinungen? --Kasper4711 10:37, 6. Dez 2005 (CET)

Das Beispiel ist bzgl Buffer-overflows (nicht raceconditions) sicher. Deshalb sollte evtl der Kommentar, das zweite Beispiel sei nicht sicher, entfernt werden. --Felix 21:00, 7. Dez 2011 (ohne Benutzername signierter Beitrag von 178.201.42.109 (Diskussion) )

Heap Overflow

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)

Ich bin eher für Auslagern. Stern 13:17, 7. Mär 2006 (CET)

Frage

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)

Nein, das geht nicht, jeder Prozess hat einen gewissen Speicherbereich, auf den er zugreifen darf. Soweit ich weiß, sitzt die Überprüfung dafür in der CPU, genauer in der Memory Management Unit. -84.58.131.126 02:03, 13. Jan. 2009 (CET)

Was hat es mit einem Pufferüberlauf zu tun, wenn man man einen Zeiger an irgendeine "lustige" Adresse zeigen lassen könnte? Für einen Pufferüberlauf muss schon ein Puffer überlaufen. Irgendwie logisch, oder? :D --213.221.250.85 18:22, 7. Dez. 2010 (CET)

Sicherheit in C++

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)

Stack Overflow?

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)

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)

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)

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)

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)

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)

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)

STACK OVERFLOW AT LINE ... Diese Fehlermeldung verschwand nach einem up-date von JAVA. -- HENE1950 16:10, 3. Feb. 2010 (CET)

Gegenmaßnahmen

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)) Im Artikel Ring (CPU) wird über NX-Flags von Speicherseiten berichtet, die die Ausführung von Code nach einem Pufferüberlauf verhindern. Dies wäre m. E. ein ganz wesentlicher Schutz für der Anwender. (nicht signierter Beitrag von 80.146.243.19 (Diskussion) 16:28, 20. Okt. 2010 (CEST))

Drei verschiedene Themen Heap/Stack/Buffer-Overflow

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)

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)

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)

Unbelegter teilweise falscher und irreführender Abschnitt

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

Defekter Weblink

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte.

Der folgende Weblink wurde von einem Bot („GiftBot“) als nicht erreichbar erkannt.
Ausführliche Erläuterungen und Hilfe zur korrekten Behebung dieses Fehlers finden sich auf Wikipedia:Defekte Weblinks. Ist ein von einem Bot als defekt gemeldeter externer Link doch erreichbar, dann bitte berichten – wie auch sonstige Probleme.

• http://www.trl.ibm.com/projects/security/ssp/
  • Vielleicht ist eine archivierte Version geeignet: archive.orghttp://giftbot.dwl.invalid/http://www.trl.ibm.com/projects/security/ssp/

– GiftBot (Diskussion) 20:44, 26. Nov. 2015 (CET)