Pufferüberschwemmung

In der Computersicherheit und Programmierung ist eine Pufferüberschwemmung oder überfluteter Puffer, eine Anomalie, wo ein Programm, während es Daten einem Puffer schreibt, die Grenze des Puffers überflutet und angrenzendes Gedächtnis überschreibt. Das ist ein spezieller Fall der Übertretung der Speichersicherheit.

Pufferüberschwemmungen können durch Eingänge ausgelöst werden, die entworfen werden, um Code durchzuführen, oder die Weise zu verändern, wie das Programm funktioniert. Das kann auf unregelmäßiges Programm-Verhalten, einschließlich Speicherzugriffsfehler, falscher Ergebnisse, eines Unfalls oder eines Bruchs der Systemsicherheit hinauslaufen. So sind sie die Basis von vieler Softwareverwundbarkeit und können böswillig ausgenutzt werden.

Mit Pufferüberschwemmungen allgemein vereinigte Programmiersprachen schließen C und C ++ ein, die keinen eingebauten Schutz gegen das Zugreifen oder Überschreiben von Daten in jedem Teil des Gedächtnisses zur Verfügung stellen und nicht automatisch überprüfen, dass Daten, die einer Reihe (der eingebaute Puffertyp) geschrieben sind, innerhalb der Grenzen dieser Reihe sind. Grenze-Überprüfung kann Pufferüberschwemmungen verhindern.

Technische Beschreibung

Eine Pufferüberschwemmung kommt vor, wenn Daten, die einem Puffer wegen der ungenügenden Grenze-Überprüfung geschrieben sind, Datenwerte in Speicheradressen neben dem zugeteilten Puffer verderben. Meistens kommt das vor, wenn es Reihen von Charakteren von einem Puffer bis einen anderen kopiert.

Grundlegendes Beispiel

Im folgenden Beispiel hat ein Programm zwei Datensachen definiert, die im Gedächtnis angrenzend sind: ein 8 Bytes langer Schnur-Puffer, A, und eine ganze Zwei-Byte-Zahl, B. Am Anfang enthält A nichts als Nullbytes, und B enthält die Nummer 1979. Charaktere sind ein Byte breit.

Jetzt versucht das Programm, die ungültig begrenzte Schnur in Ein Puffer zu versorgen. Indem es gescheitert wird, die Länge der Schnur zu überprüfen, überschreibt es den Wert von B:

Obwohl der Programmierer nicht vorgehabt hat, B überhaupt zu ändern, ist der Wert von B jetzt durch eine von einem Teil der Charakter-Schnur gebildete Zahl ersetzt worden. In diesem Beispiel, auf einem großen-endian System, das ASCII, "e" gefolgt von einem Nullbyte verwendet, würde die Nummer 25856 werden. Wenn B der einzige weitere variable durch das Programm definierte Datenartikel war, eine noch längere Schnur schreibend, die vorbei am Ende von B gegangen ist, konnte einen Fehler wie eine Segmentationsschuld verursachen, den Prozess begrenzend.

Ausnutzung

Die Techniken, um eine Pufferüberschwemmungsverwundbarkeit auszunutzen, ändern sich pro Architektur, Betriebssystem und Speichergebiet. Zum Beispiel ist die Ausnutzung auf dem Haufen (verwendet für das dynamisch zugeteilte Gedächtnis), von der Ausnutzung auf dem Anruf-Stapel sehr verschieden.

Stapel-basierte Ausnutzung

Ein technisch aufgelegter Benutzer kann Stapel-basierte Pufferüberschwemmungen ausnutzen, um das Programm zu ihrem Vorteil auf eine von mehreren Weisen zu manipulieren:

  • Durch das Überschreiben einer lokalen Variable, die in der Nähe vom Puffer im Gedächtnis auf dem Stapel ist, um das Verhalten des Programms zu ändern, das dem Angreifer nützen kann.
  • Durch das Überschreiben der Rücksprungadresse in einem Stapel-Rahmen. Sobald die Funktion zurückkehrt, wird Ausführung an der Rücksprungadresse, wie angegeben, durch den Angreifer, gewöhnlich ein Benutzereingang gefüllter Puffer die Tätigkeit wieder aufnehmen.
  • Durch das Überschreiben eines Funktionszeigestocks oder Ausnahme-Dressierers, der nachher hingerichtet wird.

Mit einer Methode genannt "trampolining", wenn die Adresse der benutzergelieferten Daten unbekannt ist, aber die Position wird in einem Register versorgt, dann kann die Rücksprungadresse mit der Adresse eines opcode überschrieben werden, der Ausführung veranlassen wird, dem Benutzer zu springen, hat Daten geliefert. Wenn die Position in einem Register R versorgt wird, dann wird ein Sprung zur Position, die den opcode für einen Sprung R, Anruf-R oder ähnliche Instruktion enthält, Ausführung gelieferter Daten des Benutzers verursachen. Die Positionen von passendem opcodes oder Bytes im Gedächtnis, können in DLLs oder dem rechtskräftigen selbst gefunden werden. Jedoch kann die Adresse des opcode normalerweise keine ungültigen Charaktere enthalten, und die Positionen dieser opcodes können sich zwischen Anwendungen und Versionen des Betriebssystems ändern. Das Metasploit-Projekt ist eine solche Datenbank von passendem opcodes, obwohl nur diejenigen, die in Windows Betriebssystem gefunden sind, verzeichnet werden.

Stapel-basierte Pufferüberschwemmungen sollen mit Stapel-Überschwemmungen nicht verwirrt sein.

Bemerken Sie auch, dass diese Verwundbarkeit gewöhnlich durch den Gebrauch eines fuzzer entdeckt wird.

Haufen-basierte Ausnutzung

Eine Pufferüberschwemmung, die im Haufen-Datengebiet vorkommt, wird eine Haufen-Überschwemmung genannt und ist auf eine verschiedene Weise zu dieser von Stapel-basierten Überschwemmungen abbaufähig. Das Gedächtnis auf dem Haufen wird durch die Anwendung an der Durchlaufzeit dynamisch zugeteilt und enthält normalerweise Programm-Daten. Ausnutzung wird durch das Verderben davon Daten auf spezifische Weisen durchgeführt, die Anwendung zu veranlassen, innere Strukturen wie verbundene Listenzeigestöcke zu überschreiben. Die kanonische Haufen-Überschwemmungstechnik überschreibt dynamische Speicherzuteilungsverbindung (wie malloc meta Daten) und verwendet den resultierenden Zeigestock-Austausch, um einen Programm-Funktionszeigestock zu überschreiben.

Der GDI des Microsofts + ist die Verwundbarkeit im Berühren von JPEGs ein Beispiel der Gefahr, die eine Haufen-Überschwemmung präsentieren kann.

Barrieren für die Ausnutzung

Die Manipulation des Puffers, der vorkommt, bevor es gelesen oder durchgeführt wird, kann zum Misserfolg eines Ausnutzungsversuchs führen. Diese Manipulationen können die Drohung der Ausnutzung lindern, aber können es unmöglich nicht machen. Manipulationen konnten Konvertierung zu Großbuchstaben oder unterer Umschaltung, Eliminierung von metacharacters einschließen und aus nichtalphanumerischen Schnuren durchscheinend. Jedoch bestehen Techniken, um diese Filter und Manipulationen zu umgehen; alphanumerischer Code, polymorpher Code, Code und Return-To-Libc-Angriffe selbstmodifizierend. Dieselben Methoden können verwendet werden, um Entdeckung durch Eindringen-Entdeckungssysteme zu vermeiden. In einigen Fällen einschließlich, wo Code in unicode umgewandelt wird, ist die Drohung der Verwundbarkeit durch den disclosers als nur Leugnung des Dienstes falsch dargestellt worden, wenn tatsächlich die entfernte Ausführung des willkürlichen Codes möglich ist.

Nützlichkeit der Ausnutzung

In wirklichen Großtaten gibt es eine Vielfalt von Herausforderungen, die für Großtaten überwunden werden müssen, um zuverlässig zu funktionieren. Diese Faktoren schließen ungültige Bytes in Adressen, Veränderlichkeit in der Position von shellcode, Unterschieden zwischen Umgebungen und verschiedenen Gegenmaßnahmen in der Operation ein.

NOP Schlitten-Technik

Ein NOP-Schlitten ist die älteste und am weitesten bekannte Technik, für eine Stapel-Pufferüberschwemmung erfolgreich auszunutzen. Es behebt das Problem, die genaue Adresse des Puffers durch die wirksame Erhöhung der Größe des Zielgebiets zu finden. Um das zu tun, werden viel größere Abteilungen des Stapels mit keiner-op Maschineninstruktion verdorben. Am Ende der Angreifer-gelieferten Daten, nach keinen-op Instruktionen, einer Instruktion, einen Verhältnissprung zur Spitze des Puffers durchzuführen, wo der shellcode gelegen wird. Diese Sammlung dessen wird nicht den "NOP-Schlitten" genannt, weil, wenn die Rücksprungadresse mit einer Adresse innerhalb keines-op Gebiets des Puffers überschrieben wird, es unten nicht "gleiten" wird, bis es zum wirklichen böswilligen Code durch den Sprung am Ende umadressiert wird. Diese Technik verlangt, dass der Angreifer errät, wo auf dem Stapel der NOP-Schlitten statt des verhältnismäßig kleinen shellcode ist.

Wegen der Beliebtheit dieser Technik werden viele Verkäufer von Eindringen-Verhinderungssystemen nach diesem Muster keiner-op Maschineninstruktionen in einem Versuch suchen, shellcode im Gebrauch zu entdecken. Es ist wichtig zu bemerken, dass ein NOP-Schlitten nur traditionell keine-op Maschineninstruktionen nicht notwendigerweise enthält; jede Instruktion, die den Maschinenstaat zu einem Punkt nicht verdirbt, wohin der shellcode nicht laufen wird, kann im Platz der Hardware geholfen nein verwendet werden. Infolgedessen ist es übliche Praxis für Großtat-Schriftsteller geworden, um keinen-op Schlitten mit zufällig gewählten Instruktionen zusammenzusetzen, die keine echte Wirkung auf die shellcode Ausführung haben werden.

Während diese Methode außerordentlich die Chancen verbessert, dass ein Angriff erfolgreich sein wird, ist es nicht ohne Probleme. Großtaten mit dieser Technik müssen sich noch auf einen Betrag des Glücks verlassen, dass sie Ausgleiche auf dem Stapel erraten werden, die innerhalb des NOP-Schlitten-Gebiets sind. Eine falsche Annahme wird gewöhnlich auf den Zielprogramm-Unfall hinauslaufen und konnte den Systemverwalter zu den Tätigkeiten des Angreifers alarmieren. Ein anderes Problem besteht darin, dass der NOP-Schlitten einen viel größeren Betrag des Gedächtnisses verlangt, in dem man einen NOP-Schlitten groß genug hält, um von jedem Nutzen zu sein. Das kann ein Problem sein, wenn die zugeteilte Größe des betroffenen Puffers zu klein ist und die aktuelle Tiefe des Stapels seicht ist (d. h. es nicht viel Raum vom Ende des aktuellen Stapel-Rahmens zum Anfang des Stapels gibt). Trotz seiner Probleme ist der NOP-Schlitten häufig die einzige Methode, die für eine gegebene Plattform, Umgebung oder Situation arbeiten wird; als solcher ist es noch eine wichtige Technik.

Der Sprung zur Adresse in einer Register-Technik versorgt

Der "Sprung um", Technik einzuschreiben, berücksichtigt zuverlässige Ausnutzung von Stapel-Pufferüberschwemmungen ohne das Bedürfnis nach dem Extrazimmer für einen NOP-Schlitten und ohne Stapel-Ausgleiche erraten zu müssen. Die Strategie ist, den Rückzeigestock mit etwas zu überschreiben, was das Programm veranlassen wird, zu einem bekannten Zeigestock zu springen, der innerhalb eines Registers versorgt ist, das zum kontrollierten Puffer und so dem shellcode hinweist. Zum Beispiel, wenn Register A einen Zeigestock zum Anfang eines Puffers dann Sprung oder Anruf enthält, der dieses Register nimmt, weil ein operand verwendet werden kann, um Kontrolle des Flusses der Ausführung zu gewinnen.

In der Praxis kann ein Programm nicht Instruktionen absichtlich enthalten, zu einem besonderen Register zu springen. Die traditionelle Lösung ist, ein unbeabsichtigtes Beispiel eines passenden opcode an einer festen Position irgendwo innerhalb des Programm-Gedächtnisses zu finden. In der Zahl links können Sie ein Beispiel solch eines unbeabsichtigten Beispiels der i386 Instruktion sehen. Der opcode für diese Instruktion ist. Diese Zwei-Byte-Folge kann an einem Ein-Byte-Ausgleich vom Anfang der Instruktion an der Adresse gefunden werden. Wenn ein Angreifer die Programm-Rücksprungadresse mit dieser Adresse überschreibt, wird das Programm zuerst dazu springen, den opcode als die Instruktion interpretieren, und wird dann zur Spitze des Stapels springen und den Code des Angreifers durchführen.

Wenn diese Technik die Strenge der Verwundbarkeitszunahmen beträchtlich möglich ist. Das ist, weil Ausnutzung zuverlässig genug arbeiten wird, um einen Angriff mit einer virtuellen Garantie des Erfolgs zu automatisieren, wenn es geführt wird. Deshalb ist das die Technik, die meistens in Internetwürmern verwendet ist, die Stapel-Pufferüberschwemmungsverwundbarkeit ausnutzen.

Diese Methode erlaubt auch shellcode, nach der überschriebenen Rücksprungadresse auf der Windows-Plattform gelegt zu werden. Da executables größtenteils an der Adresse basieren und x86 ein bisschen Endian Architektur ist, muss das letzte Byte der Rücksprungadresse eine Null sein, die die Pufferkopie begrenzt und nichts darüber hinaus geschrieben wird. Das beschränkt die Größe des shellcode zur Größe des Puffers, der allzu einschränkend sein kann. DLLs werden im hohen Gedächtnis (oben) gelegen und so haben Sie Adressen, die keine ungültigen Bytes enthalten, so kann diese Methode ungültige Bytes (oder andere zurückgewiesene Charaktere) von der überschriebenen Rücksprungadresse entfernen. Verwendet auf diese Weise wird die Methode häufig "DLL Trampolining" genannt.

Schutzgegenmaßnahmen

Verschiedene Techniken sind verwendet worden, um Pufferüberschwemmungen mit verschiedenen Umtauschen zu entdecken oder zu verhindern. Die zuverlässigste Weise, Pufferüberschwemmungen zu vermeiden oder zu verhindern, soll automatischen Schutz an der Sprachebene verwenden. Diese Sorte des Schutzes kann jedoch auf den Vermächtnis-Code nicht angewandt, und häufig, Geschäft technisch werden, oder kulturelle Einschränkungen verlangen nach einer verwundbaren Sprache. Die folgenden Abteilungen beschreiben die Wahlen und verfügbaren Durchführungen.

Wahl der Programmiersprache

Die Wahl der Programmiersprache kann eine tiefe Wirkung auf das Ereignis von Pufferüberschwemmungen haben., unter den populärsten Sprachen sind C und seine Ableitung, C ++ mit einem riesengroßen Körper der Software, die auf diesen Sprachen worden ist schreibt. C und C ++ stellen keinen eingebauten Schutz gegen das Zugreifen oder Überschreiben von Daten in jedem Teil des Gedächtnisses zur Verfügung; mehr spezifisch überprüfen sie nicht, dass einem Puffer geschriebene Daten innerhalb der Grenzen dieses Puffers sind. Jedoch der Standard C ++ stellen Bibliotheken viele Wege zur Verfügung, sicher Daten und Techniken zu puffern, um zu vermeiden, dass Pufferüberschwemmungen auch für C bestehen.

Viele andere Programmiersprachen stellen Laufzeitüberprüfung und in einigen Fällen sogar Übersetzungszeit zur Verfügung überprüfend, der eine Warnung senden oder eine Ausnahme erheben könnte, wenn C oder C ++ Daten überschreiben und fortsetzen würden, weitere Instruktionen durchzuführen, bis falsche Ergebnisse erhalten werden, der könnte oder das Programm nicht veranlassen könnte abzustürzen. Beispiele solcher Sprachen schließen Ada, Eiffel, Lispeln, Modula-2, Plausch, OCaml und solche C-Ableitungen wie Zyklon und D ein. Java und.NET Fachwerk bytecode Umgebungen verlangen auch Grenze-Überprüfung auf der ganzen Reihe. Fast jede interpretierte Sprache wird gegen Pufferüberschwemmungen schützen, einer bestimmten Fehlerbedingung Zeichen gebend. Häufig, wo eine Sprache genug Typ-Auskunft gibt, um Grenzen zu tun, die überprüfen, dass eine Auswahl zur Verfügung gestellt wird, um es zu ermöglichen oder unbrauchbar zu machen. Statische Codeanalyse kann viele dynamisch gebunden und Typ-Kontrollen entfernen, aber schlechte Durchführungen und ungeschickte Fälle können Leistung bedeutsam vermindern. Softwareingenieure müssen die Umtausche der Sicherheit gegen Leistungskosten sorgfältig denken, wenn sie der Sprache und Bearbeiter entscheiden, der untergeht, um zu verwenden.

Gebrauch von sicheren Bibliotheken

Das Problem von Pufferüberschwemmungen ist im C und C ++ Sprachen üblich, weil sie niedrige Stufe Vertretungsdetails von Puffern als Behälter für Datentypen ausstellen. Pufferüberschwemmungen müssen so durch das Aufrechterhalten eines hohen Grads der Genauigkeit im Code vermieden werden, der Puffermanagement durchführt. Es ist auch lange empfohlen worden, Standardbibliotheksfunktionen zu vermeiden, die nicht Grenzen überprüft, solcher als sind, und. Der Wurm von Morris hat einen Anruf in fingerd ausgenutzt.

Gut geschriebene und geprüfte abstrakte Datentyp-Bibliotheken, die zentralisieren und automatisch Puffermanagement einschließlich der Grenze-Überprüfung durchführen, können das Ereignis und den Einfluss von Pufferüberschwemmungen reduzieren. Die zwei Hauptbaustein-Datentypen auf diesen Sprachen, auf denen Pufferüberschwemmungen allgemein vorkommen, sind Schnuren und Reihe; so können Bibliotheken, die Pufferüberschwemmungen in diesen Datentypen verhindern, die große Mehrheit des notwendigen Einschlusses zur Verfügung stellen. Und doch, Misserfolg, diese sicheren Bibliotheken zu verwenden, kann richtig auf Pufferüberschwemmungen und andere Verwundbarkeit hinauslaufen; und natürlich ist jeder Programmfehler in der Bibliothek selbst eine potenzielle Verwundbarkeit. "Sichere" Bibliotheksdurchführungen schließen "Die Bessere Schnur-Bibliothek", Vstr und Erwin ein. Die C Bibliothek des Betriebssystems von OpenBSD stellt den strlcpy und die Strlcat-Funktionen zur Verfügung, aber diese werden mehr beschränkt als volle sichere Bibliotheksdurchführungen.

Im September 2007 wurde Technischer Bericht 24731, der vom C Standardkomitee bereit ist, veröffentlicht; es gibt eine Reihe von Funktionen an, die auf dem Standard C die Schnur der Bibliothek und Eingabe/Ausgabe-Funktionen mit zusätzlichen Puffergröße-Rahmen basieren. Jedoch ist die Wirkung dieser Funktionen zum Zweck, Pufferüberschwemmungen zu reduzieren, diskutierbar; es verlangt Programmierer-Eingreifen auf pro Funktionsanruf-Basis, die zum Eingreifen gleichwertig ist, das die analoge ältere Standardbibliotheksfunktionspufferüberschwemmung sicher machen konnte.

Pufferüberschwemmungsschutz

Pufferüberschwemmungsschutz wird verwendet, um die allgemeinsten Pufferüberschwemmungen durch die Überprüfung zu entdecken, dass der Stapel nicht verändert worden ist, wenn eine Funktion zurückkehrt. Wenn es verändert worden ist, geht das Programm mit einer Segmentationsschuld ab. Drei solche Systeme sind Libsafe, und StackGuard und ProPolice gcc Flecke.

Die Datenausführungsverhinderungsweise des Microsofts schützt ausführlich den Zeigestock dem SEH Ausnahme-Dressierer davon, überschrieben zu werden.

Stärkerer Stapel-Schutz ist durch das Aufspalten des Stapels in zwei möglich: ein für Daten und ein für den Funktionsumsatz. Dieser Spalt ist in Hervor Sprache da, obwohl es nicht eine Sicherheitsbasierte Designentscheidung war. Trotzdem ist das nicht eine vollständige Lösung, Überschwemmungen, als empfindliche Daten anders zu puffern, als die Rücksprungadresse noch überschrieben werden kann.

Zeigestock-Schutz

Puffer überflutet Arbeit durch die Manipulierung von Zeigestöcken (einschließlich versorgter Adressen). PointGuard wurde als eine Bearbeiter-Erweiterung vorgeschlagen, um Angreifer davon abzuhalten, im Stande zu sein, Zeigestöcke und Adressen zuverlässig zu manipulieren. Die Annäherungsarbeiten, indem sie den Bearbeiter gehabt wird, fügen Code hinzu, um Zeigestöcke vorher automatisch Zu XOR-verschlüsseln, und nachdem sie verwendet werden. Weil der Angreifer (theoretisch) das nicht weiß, welcher Wert verwendet wird, um den Zeigestock zu verschlüsseln zu/decodieren, kann er nicht voraussagen, was es darauf anspitzen wird, wenn er es mit einem neuen Wert überschreibt. PointGuard wurde nie befreit, aber Microsoft hat eine ähnliche Annäherung durchgeführt, die in Windows XP SP2 und Windows Server 2003 SP1 beginnt. Anstatt Zeigestock-Schutz als eine automatische Eigenschaft durchzuführen, hat Microsoft eine API-Routine hinzugefügt, die nach Belieben des Programmierers genannt werden kann. Das berücksichtigt bessere Leistung (weil sie die ganze Zeit nicht verwendet wird), aber legt die Last auf dem Programmierer, um zu wissen, wenn es notwendig ist.

Weil XOR geradlinig ist, kann ein Angreifer im Stande sein, einen verschlüsselten Zeigestock zu manipulieren, indem er nur die niedrigeren Bytes einer Adresse überschreibt. Das kann einem Angriff erlauben erfolgreich zu sein, wenn der Angreifer im Stande ist, die Großtat mehrmals zu versuchen, und/oder im Stande ist, einen Angriff zu vollenden, indem er einen Zeigestock veranlasst, zu einer von mehreren Positionen (wie eine Position innerhalb eines NOP Schlittens) hinzuweisen. Microsoft hat hinzugefügt, dass eine zufällige Folge zu ihrem Verschlüsselungsschema, diese Schwäche an den teilweisen zu richten, überschreibt.

Rechtskräftiger Raumschutz

Rechtskräftiger Raumschutz ist eine Annäherung an den Pufferüberschwemmungsschutz, der Ausführung des Codes auf dem Stapel oder dem Haufen verhindert. Ein Angreifer kann Pufferüberschwemmungen verwenden, um willkürlichen Code ins Gedächtnis eines Programms einzufügen, aber mit dem rechtskräftigen Raumschutz wird jeder Versuch, diesen Code durchzuführen, eine Ausnahme verursachen.

Einige Zentraleinheiten unterstützen eine Eigenschaft genannt NX ("Nicht führen" durch), oder XD ("führen Arbeitsunfähig" durch) Bit, das in Verbindung mit der Software, verwendet werden kann, um Seiten von Daten (wie diejenigen zu kennzeichnen, die den Stapel und den Haufen enthalten) als lesbar und schreibbar, aber nicht rechtskräftig.

Ein Unix Betriebssysteme (z.B. OpenBSD, Mac OS X) Schiff mit dem rechtskräftigen Raumschutz (z.B. W^X). Einige fakultative Pakete schließen ein:

  • PaX
  • Exec Schild
  • Openwall

Neuere Varianten von Windows von Microsoft unterstützen auch rechtskräftigen Raumschutz, genannt Datenausführungsverhinderung. Eigentumserweiterungen schließen ein:

  • BufferShield
  • StackDefender

Rechtskräftiger Raumschutz schützt gegen Return-To-Libc-Angriffe oder jeden anderen Angriff nicht allgemein, der sich auf die Ausführung des Angreifer-Codes nicht verlässt. Jedoch, auf 64-Bit-Systemen mit ASLR, wie beschrieben, unten, macht rechtskräftiger Raumschutz es viel schwieriger, solche Angriffe durchzuführen.

Adressraum-Lay-Out randomization

Adressraum-Lay-Out randomization (ASLR) ist eine Computersicherheitseigenschaft, die das Ordnen der Positionen von Schlüsseldatengebieten, gewöhnlich einschließlich der Basis des rechtskräftigen und Position von Bibliotheken, Haufen und Stapel zufällig in einem Adressraum eines Prozesses einschließt.

Randomization der virtuellen Speicheradressen, an denen Funktionen und Variablen gefunden werden können, kann Ausnutzung einer Pufferüberschwemmung schwieriger, aber nicht unmöglich machen. Es zwingt auch den Angreifer, den Ausnutzungsversuch zum individuellen System zu schneidern, das die Versuche von Internetwürmern vereitelt. Eine ähnliche, aber weniger wirksame Methode ist, Prozesse und Bibliotheken im virtuellen Adressraum wiederzustützen.

Tiefe Paket-Inspektion

Der Gebrauch der tiefen Paket-Inspektion (DPI), kann am Netzumfang, sehr grundlegende entfernte Versuche entdecken, Pufferüberschwemmungen durch den Gebrauch von Angriffsunterschriften und Heuristik auszunutzen. Diese sind im Stande, Pakete zu blockieren, die die Unterschrift eines bekannten Angriffs haben, oder wenn eine lange Reihe von Instruktionen ohne Operationen (bekannt als ein Nop-Schlitten) entdeckt wird, wurden diese einmal verwendet, wenn die Position der Nutzlast der Großtat ein bisschen variabel ist.

Paket-Abtastung ist nicht eine wirksame Methode, da sie nur bekannte Angriffe verhindern kann und es viele Weisen gibt, wie ein 'Nop-Schlitten' verschlüsselt werden kann. Von Angreifern verwendeter Shellcode kann alphanumerisch, metamorph gemacht werden, oder selbstmodifizierend, um Entdeckung durch heuristische Paket-Scanner und Eindringen-Entdeckungssysteme auszuweichen.

Geschichte

Pufferüberschwemmungen wurden verstanden und teilweise öffentlich schon in 1972 dokumentiert, als die Computersicherheitstechnologieplanungsstudie die Technik angelegt hat: "Der Code, der diese Funktion durchführt, überprüft die Quelle und Bestimmungsort-Adressen richtig nicht, Teilen des Monitors erlaubend, vom Benutzer überzogen zu werden. Das kann verwendet werden, um Code in den Monitor einzuspritzen, der dem Benutzer erlauben wird, Kontrolle der Maschine zu greifen." (Seite 61) Heute, der Monitor würde den Kern genannt werden.

Die frühste dokumentierte feindliche Ausnutzung einer Pufferüberschwemmung war 1988. Es war eine von mehreren vom Wurm von Morris verwendeten Großtaten, um sich über das Internet fortzupflanzen. Das ausgenutzte Programm war ein Dienst auf Unix genannt Finger. Später, 1995, hat Thomas Lopatic unabhängig die Pufferüberschwemmung wieder entdeckt und hat seine Ergebnisse auf der Sicherheitsadressenliste von Bugtraq veröffentlicht. Ein Jahr später, 1996, Elias Levy (auch bekannt als Aleph Ein) veröffentlicht in der Zeitschrift Phrack das Papier "Das Zersplittern des Stapels zum Spaß und Gewinn", eine schrittweise Einführung in die Ausnutzung Stapel-basierter Pufferüberschwemmungsverwundbarkeit.

Seitdem haben mindestens zwei Hauptinternetwürmer Pufferüberschwemmungen ausgenutzt, um eine Vielzahl von Systemen in Verlegenheit zu bringen. 2001 hat der Wurm des Code Red eine Pufferüberschwemmung in Internet Information Services (IIS) des Microsofts 5.0 ausgenutzt, und 2003 hat der SQL Gefängnis-Wurm das Maschinenlaufen Microsoft SQL Server 2000 in Verlegenheit gebracht.

2003, Pufferüberschwemmungsgegenwart in lizenzierten Spielen von Xbox sind ausgenutzt worden, um Software ohne Lizenz einschließlich Spiele des selbst gebrauten Biers zu erlauben, auf der Konsole ohne das Bedürfnis nach Hardware-Modifizierungen, bekannt als modchips zu laufen. Die PS2 Unabhängigkeitsgroßtat hat auch eine Pufferüberschwemmung verwendet, um dasselbe für PlayStation 2 zu erreichen. Die Zwielicht-Kerbe hat dasselbe mit Wii, mit einer Pufferüberschwemmung darin vollbracht.

Siehe auch

  • Milliarde Lachen
  • Computerunsicherheit
  • Computersicherheit
  • Ende der Datei
  • Format-Schnur greift an
  • Haufen-Überschwemmung
  • Schwirren des Todes
  • Hafen, scannend
  • Return-to-libc greifen an
  • Sicherheit hat Betriebssysteme eingestellt
  • Das Selbständern des Codes
  • Shellcode
  • Stapel-Puffer überflutet

Referenzen

Links


Gekochtes Leder / Programmfehler
Impressum & Datenschutz