DE60304005T2

DE60304005T2 - Änderung von Ladeadressen von ausführbaren Programmodulen

Info

Publication number: DE60304005T2
Application number: DE60304005T
Authority: DE
Inventors: William E. Stevenson Ranch Sobel; Bruce Los Angeles McCorkendale
Original assignee: Symantec Corp
Current assignee: Gen Digital Inc
Priority date: 2002-05-06
Filing date: 2003-05-06
Publication date: 2006-11-16
Anticipated expiration: 2023-05-07
Also published as: EP1361496A3; DE60304005D1; US20040177263A1; US7155741B2; EP1361496A2; EP1361496B1

Description

Hintergrund der Erfindung
Technisches Gebiet
Die Erfindung betrifft allgemein Computersicherheit. Genauer gesagt, betrifft sie ein Verfahren zum Verhindern von Pufferüberlauf-Angriffen bei digitalen Computern.
Hintergrundbildende Technik
Innerhalb des kurzen Werdegangs von Computern wurden Systemverwalter von sich selbst vervielfältigenden Programmen wie Viren, Würmern und Trojanischen Pferden geplagt, die dazu konzipiert sind, Hostcomputersysteme außer Gang zu setzen und sich selbst auf angeschlossene Systeme auszubreiten.
In den letzten Jahren haben zwei Entwicklungen die durch diese bösartigen Programme verursachte Bedrohung verstärkt. Erstens hat die zunehmende Abhängigkeit von Computern betreffend das Ausführen von für einen Auftrag kritischen Geschäftsaufgaben die wirtschaftlichen Kosten in Zusammenhang mit Abschaltzeiten des Systems erhöht. Zweitens hat es die erhöhte wechselseitige Verbindung zwischen Computern ermöglicht, dass sich Viren und Würmer innerhalb von Stunden auf eine große Anzahl von Systemen ausbreiten.
Viren und Würmer verwenden manchmal Pufferüberlauf-Angriffe zum Erzielen der Kontrolle über ein Computersystem. Zu diesem Verfahren gehört das Reagieren auf eine Datenanforderung mit einem größeren Datenstring als die Anforderung gemäß der Konzeption aufnehmen kann. Der größere Datenstring spült in Spei cherabschnitte herein, die dazu konfiguriert wurden, andere Werte aufzunehmen, wie Rücksprungsadressen des ausgeführten Codes. Wenn der Code seine Ausführung beendet, liest die fragliche Anwendung, anstatt dass sie den Speicher an der vorigen Rücksprungadresse liest, den Speicher an der durch das Virus eingeführten Rücksprungadresse. Die neue Rücksprungadresse kann entweder der Ort des neu eingeführten Viruscodes sein, oder der eines üblichen, vom System ausführbaren Codemoduls, das selbst einen Aufruf zum Ort ausführt, an dem sich der Viruscode befindet.
Um Systemressourcen aufrechtzuerhalten, werden bestimmte allgemein verwendete Segmente ausführbaren Codes, die als "Module ausführbaren Codes" bekannt sind, bei bestimmten Anwendungsprozessen an festen Orten im logischen Speicher geladen. Diese Module ausführbaren Codes sind für die Erzeuger von Viren und Würmern von Nutzen, da sie dazu verwendet werden können, bösartigen Code auszuführen, und die Ladeadressen der Module sind häufig öffentlich bekannt oder leicht ermittelbar. Es wird ein Verfahren benötigt, das verhindert, dass Viren und andere bösartige Agenten diese Module ausführbaren Codes nutzen.
US-A-5949973 offenbart ein Verfahren zum Verhindern des Außerkraftsetzens eines Stacks, das dadurch die Möglichkeit blockiert, dass die Kontrolle durch Außerkraftsetzen des Stacks weitergegeben wird, dass der gesamte Stack an einen zufälligen Speicherort umgelegt wird und der alte Stackbereich gelöscht wird.
WO 01/37095 offenbart ein Verfahren zur sicheren Funktionsausführung durch Abfangen von Systemaufrufen, um ihre Gültigkeit dadurch zu bestimmten, dass ursprüngliche Aufrufadressen mit einem Bereich gültiger Prozessadressen verglichen werden und der Prozess beendet wird, wenn sich irgendein Aufruf als ungültig ergibt.
Erscheinungsformen der Erfindung sind in den beigefügten unabhängigen Ansprüchen dargelegt.
Eine Ausführungsform verhindert dadurch, dass erzwungen wird, dass Module ausführbaren Codes an abwechselnden Speicherorten geladen werden, die Nutzung derselben, um Pufferüberlauf-Angriffe zu ermöglichen. Erfolgreiche Pufferüberlauf-Angriffe müssen häufig Module (280) ausführbaren Codes an festen Or ten im logischen Speicher (285) aufrufen. Bestimmte Module ausführbaren Codes können dadurch eine besonders hohe Gefahr dahingehend bilden, dass sie Pufferüberlauf-Angriffe ermöglichen, da sie von mehreren Anwendungsprozessen verwendet werden und da sie an bekannten Speicheradressen liegen. Die Ausführungsform verhindert Pufferüberlauf-Angriffe durch Ändern des Bereichs im Speicher, in den "stark bedrohte" Module ausführbaren Codes geladen werden, um dadurch dafür zu sorgen, dass die Angriffe fehlschlagen, da die angreifenden Agenten nicht auf die Anweisungen im ausführbaren Code der Module zugreifen können.
Die Ausführungsform verwendet eine Überwachungsschicht (210) zum selektiven Ändern der Ladeorte von Modulen (280) ausführbaren Codes. Eine Überwachungsschicht (210) kann so konfiguriert werden, dass sie sich zwischen dem Betriebssystem (220) und einem Anwendungsprozess (205) befindet und alle Kommunikationsvorgänge zwischen dem Anwendungsprozess (205) und dem Betriebssystem (220) abfängt. Die Überwachungsschicht (210) verwaltet ferner alle vom Betriebssystem (220) ausgeführten Versuche, ausführbaren Code zu laden, wenn ein neuer Anwendungsprozess erstmals gestartet wird. Wenn ein Anwendungsprozess (205) oder das Betriebssystem (220) versucht, ein Modul (280) ausführbaren Codes in den Speicher (285) zu laden, wendet die Überwachungsschicht (210) vorbestimmte Kriterien an, um zu ermitteln, ob das Modul (280) ausführbaren Codes ein hoch gefährdetes Modul ist. Wenn ermittelt wird, dass das Modul (280) ausführbaren Codes ein hoch gefährdetes Modul ist, reserviert die Überwachungsschicht (210) Speichersektionen zwischen dem ursprünglichen Ladeort (295) und einem alternativen Ladeort (290), um so das Modul (280) zwangsweise am alternativen Ladeort (290) zu laden.
Alternativ kann die Überwachungsschicht (210) so konfiguriert werden, dass sie sich zwischen dem Betriebssystem (220) und einem Dateisystem (235) befindet, um Kommunikationsvorgänge zwischen diesem und dem Betriebssystem (220) abzufangen. Wenn ein Anwendungsprozess (205) oder das Betriebssystem (220) versucht, ein Modul zu laden, ermittelt die Überwachungsschicht (210), ob das Modul (280) ausführbaren Codes ein hoch gefährdetes Modul ist. Wenn das Modul (280) ausführbaren Codes ein hoch gefährdetes Modul ist, editiert die Überwachungsschicht (210) die Sektion des Moduls (280), die seinen bevorzugten Ladeort enthält, wobei sie den bevorzugten Ladeort durch einen alternativen Ladeort ersetzt. Dann lädt das Betriebssystem (220) das Modul (280) an den alternativen Ladeort (290).
Kurze Beschreibung der Zeichnungen
Diese und andere, detailliertere und speziellere Aufgaben und Merkmale der Erfindung werden in der folgenden Beschreibung unter Bezugnahme auf die beigefügten Zeichnungen vollständiger offenbart.
1A ist ein Blockdiagramm auf hoher Ebene zum Veranschaulichen einer Computerbetriebsumgebung, in der eine Ausführungsform der Erfindung arbeiten kann.
1B ist ein Blockdiagramm, auf hoher Ebene, eines Computersystems 100 zur Verwendung als Webserver 155 gemäß einer Ausführungsform der Erfindung.
2A ist ein Blockdiagramm zum Veranschaulichen der Wechselwirkung zwischen einem Betriebssystem 220 einer Überwachungsschicht 210 eines Anwendungsprozess 205, eines Dateisystems 235, einer Datenspeichereinheit 108 und einer Logikspeicherstruktur 285 gemäß einer Ausführungsform der Erfindung.
Die 2B ist ein Blockdiagramm zum Veranschaulichen der Wechselwirkung zwischen einem Betriebssystem 220, einer Überwachungsschicht 210, einem Dateisystem 235, einer Datenspeichereinheit 108, einer Logikspeicherstruktur 285 und einem Anwendungsprozess 205 gemäß einer zweiten Ausführungsform der Erfindung.
3A ist ein Blockdiagramm zum detaillierten Veranschaulichen der Logikspeicherstruktur 285 eines Anwendungsprozesses 205, der auf einem Webserver 255 läuft, gemäß einer Ausführungsform der Erfindung.
3B ist ein Diagramm, das eine detailliertere Ansicht des Decks 340 für einen Anwendungsprozess 205 gemäß einer Ausführungsform der Erfindung zeigt.
4 ist ein Blockdiagramm zum Veranschaulichen eines Komponentenüberblicks für eine Überwachungsschicht 210 gemäß einer Ausführungsform der Erfindung.
5 ist ein Flussdiagramm zum Veranschaulichen eines Verfahrens zum Verhindern von Pufferüberlauf-Angriffen durch Reservieren eines üblichen Speicherorts gemäß einer Ausführungsform der Erfindung.
6 ist ein Flussdiagramm zum Veranschaulichen eines Verfahrens zum Verhindern von Pufferüberlauf-Angriffen durch Ändern des bevorzugten Ladeorts eines Moduls ausführbaren Codes gemäß einer zweiten Ausführungsform der Erfindung.
Detaillierte Beschreibung der bevorzugten Ausführungsformen
Die hier offenbarten Ausführungsformen verhindern Pufferüberlauf-Angriffe, wie sie durch angreifende Agenten ausgelöst werden. So wie hier verwendet, bezeichnen die Begriffe "angreifender Agent" und "bösartiger Code" jedes Programm, Modul oder jeden Codeteil, der ohne Kenntnis des berechtigten Benutzers und/oder entgegen den Wünschen desselben in ein System geladen wird. Der Begriff "angreifender Agent" beinhaltet Viren, Programme für Trojanische Pferde, Würmer und andere derartige hinterhältige Software. Ein angreifender Agent kann über die Fähigkeit verfügen, sich selbst zu vervielfältigen und andere Computersysteme zu beeinträchtigen. Jedoch kann einem angreifenden Agenten die Fähigkeit fehlen, sich selbst zu vervielfältigen.
Die unten erörterten Ausführungsformen beschreiben einen Pufferüberlauf-Angriff, der über einen HTTP-Socket durch ein Virus ausgelöst wird. Jedoch ist die Erfindung bei jeder Art von Pufferüberlauf-Angriff anwendbar, die durch irgendeinen angreifenden Agenten ausgelöst wird.
Die 1A ist ein Blockdiagramm auf hoher Ebene zum Veranschaulichen einer Computerbetriebsumgebung, in der eine Ausführungsform der Erfindung arbeiten kann. Ein als Webserver fungierender Computer 155 ist mit einem lokalen Netzwerk 170 verbunden, das zusätzliche im Netzwerk verbundene Systeme 160, 165 enthält. Das lokale Netzwerk 170 kann ein Ethernet-Netzwerk, ein Token-Ring-Netzwerk oder irgendeine andere Form eines lokalen Netzwerks sein. Außerdem sind die Systeme 155, 160, 165 mit dem Internet 150 verbunden. Diese Verbindung kann über ein Modem, eine Digital Subscriber Line (DSL) oder irgendeine andere Verbindungsart erfolgen. Mit dem Internet 150 ist auch ein Fernsystem 175 verbunden, das über das TCP/IP-Protokoll mit dem Webserver 155 kommunizieren kann.
Die 1B ist ein Blockdiagramm auf hoher Ebene, eines Computersystems 100 zur Verwendung als Webserver 155 oder Netzwerkcomputer 160, 165. Es ist min destens ein Prozessor 102, der mit einem Bus 104 verbunden ist, dargestellt. Mit dem Bus 104 sind auch ein Speicher 106, eine Speichereinheit 108, eine Tastatur 110, ein Grafikadapter 112, eine Zeigevorrichtung 114 und ein Netzwerkadapter 116 verbunden. Mit dem Grafikadapter 112 ist ein Display 118 verbunden.
Der Prozessor 102 kann jeder beliebige Spezial- oder Universalprozessor sein, wie eine zentrale Verarbeitungseinheit (CPU), die mit Intel x86 oder POWERPC kompatibel ist. Die Speichereinheit 108 kann eine beliebige Vorrichtung sein, die große Datenmengen aufnehmen kann, wie eine Festplatte, ein Kompakt-Disk-Festwertspeicher (CD-ROM), eine DVD oder irgendeine andere Form einer festen oder austauschbaren Speichereinheit.
Der Speicher 106 enthält vom Prozessor 102 verwendete Anweisungen und Daten. Die Zeigevorrichtung 114 kann eine Maus, ein berührungsempfindliches Display oder irgendein anderer Typ einer Zeigevorrichtung sein, und sie wird in Kombination mit der Tastatur 110 dazu verwendet, Daten in das Computersystem 100 einzugeben. Die Typen von Hardware und Software innerhalb des Computersystems 100 können variieren.
Die 2A ist ein Blockdiagramm zum Veranschaulichen der Wechselwirkung zwischen einem Betriebssystem 220, einer Überwachungsschicht 210, einem Anwendungsprozess 205, einem Dateisystem 235, einer Datenspeichereinheit 108 und einer Logikspeicherstruktur 285 gemäß einer Ausführungsform der Erfindung. Das Betriebssystem 220 läuft auf einem Webserver 155 und im Netzwerk verbundenen Systemen 160, 165, und es kann ein beliebiges einer Anzahl von Multitask-Betriebssystemen sein, wie Windows, Linux oder Solaris. Das Betriebssystem 220 verwaltet mehrere Anwendungsprozesse, und es erzeugt für jeden Anwendungsprozess 205 eine Logikspeicherstruktur 285. Die Logikspeicherstruktur 285 wird später an Hand der 3A detaillierter erörtert.
Der Anwendungsprozess 205 kann eine beliebige auf dem Webserver 155 laufende Anwendung sein, wie ein Texteditor, ein Informationsserver oder ein Musikabspielprogramm. Die Überwachungsschicht 210 befindet sich zwischen dem Betriebssystem 220 und dem Anwendungsprozess 205. Das Dateisystem 235 ist so konfiguriert, dass es die Wechselwirkung mit dem Datenspeicher 108 steuert. Wenn das Dateisystem 235 eine Ladeanforderung für ein Modul 280 ausführbaren Codes empfängt, bestimmt es den physikalischen Ort desselben im Datenspeicher 108, und es sendet eine Anforderung an den Datenspeicher 108, um Daten vom physikalischen Ort zu entnehmen, der das angeforderte Modul enthält. Zu Beispielen dieser Module ausführbaren Codes gehören Sektionen von Dateien mit den Erweiterungen DLL, EXE oder COM, sowie jedes beliebige andere Dateiformat, das ausführbaren Code enthält.
Wenn der Anwendungsprozess 205 versucht, ein Modul 280 in den logischen Speicher 285 zu laden, fängt die Überwachungsschicht 210 die Ladeanforderung ab. Außerdem fängt die Überwachungsschicht 210 alle Versuche durch das Betriebssystem 220 ab, Module ausführbaren Codes zu laden, wenn ein neuer Anwendungsprozess erstmals gestartet wird. Bei einer Ausführungsform erfolgt dieses Abfangen für alle Anwendungsprozesse. Bei einer alternativen Ausführungsform erfolgt dieses Abfangen nur für vorbestimmte Anwendungsprozesse. Wenn ermittelt wird, dass das Modul (280) hoch gefährdet ist, und wenn es über einen bevorzugten Ladeort verfügt, ermittelt die Überwachungsschicht 210 den bevorzugten Ladeort des Moduls 280. Dann reserviert die Überwachungsschicht 210 einen Speicherblock, der den bevorzugten Ladeort 295 enthält. Die Ladeanforderung wird an das Betriebssystem 220 weitergeleitet, das eine Ladeanforderung an das Dateisystem 235 sendet, die das Modul 280 ausführbaren Codes aus dem Datenspeicher 108 entnimmt. Das Dateisystem 235 liefert das Modul 280 ausführbaren Codes an das Betriebssystem 220 zurück, das, wenn es den bevorzugten Ladeort 295 belegt findet, dasselbe am alternativen Ladeort 290 lädt.
Die Überwachungsschicht 210 kann so konfiguriert sein, dass sie sich selbst an das Betriebssystem 220 bindet, um Kommunikationsvorgänge zwischen diesem und dem Anwendungsprozess 205 zu verwalten, und um ferner alle neuen Ladeversuche durch das Betriebssystem 220 zu überwachen. Bei dieser Ausführungsform wirkt die Anwendungsprozess als transparente Schnittstelle, die sich dem Betriebssystem 220 selbst als Anwendungsprozess 205 zeigt, und die sich diesem selbst als Betriebssystem 220 zeigt. Die Überwachungsschicht 210 kann vorteilhaft vom Betriebssystem bereitgestellte "hooks" nutzen, die es mittleren Programmschichten ermöglichen, Nahtlosschnittstellen mit dem Betriebssystem 220 zu bilden und Kommunikationsvorgänge zwischen diesem und Anwendungsprozessen zu überwachen. Bei einer Ausführungsform erfolgt der Hooking-Betrieb des Betriebssystems 220 mittels des von Symantec Corporation, Cupertino, Kalifornien erhältlichen Softwareprodukts SYMEVENT.
Alternativ können, wenn die Überwachungsschicht 210 installiert ist, Teile des Betriebssystems 220 zum Umleiten von Kommunikationsvorgängen zwischen dem Anwendungsprozess 205 und dem Betriebssystem 220 über die Überwachungsschicht 210 einem Patchvorgang unterzogen werden.
Die 2B ist ein Blockdiagramm zum Veranschaulichen der Wechselwirkung zwischen einem Betriebssystem 220, einer Überwachungsschicht 210, einem Dateisystem 235, einer Datenspeichereinheit 108, einer Logikspeicherstruktur 285 und einem Anwendungsprozess 205 gemäß einer zweiten Ausführungsform der Erfindung. Bei der vorliegenden Ausführungsform wird, wenn ein Anwendungsprozess 205 versucht, ein Modul 280 ausführbaren Codes in den logischen Speicher 285 zu laden, seine Anforderung an das Betriebssystem 220 weitergeleitet, das eine entsprechende Anforderung an das Dateisystem 235 sendet. Alternativ kann das Betriebssystem 220 versuchen, das Modul 280 ausführbaren Codes direkt zu laden, wenn ein neuer Anwendungsprozess erstmals geladen wird. Die Überwachungsschicht 210 fängt die Ladeanforderung ab, und wenn sie für ein hoch gefährdetes Modul ist, versieht sie dieselbe mit einem Tag und liefert sie an das Dateisystem 235. Das Dateisystem 235 entnimmt das Modul 280 ausführbaren Codes aus dem Datenspeicher 108, und es versucht, es an das Betriebssystem 210 zu senden. Die Überwachungsschicht 210 fängt den Kommunikationsvorgang ab, und sie führt eine Prüfung aus, um zu erkennen, ob das Modul 280 ausführbaren Codes einer mit Tag versehenen Modulanforderung entspricht. Wenn dies der Fall ist, modifiziert die Überwachungsschicht 210 den bevorzugten Ladeort 295 für das Modul 280 ausführbaren Codes, und sie liefert es an das Betriebssystem 220, das es am alternativen Ladeort 290 lädt.
Wie bei Ausführungsformen, bei denen sich die Überwachungsschicht 210 selbst an das Betriebssystem 220 bindet, um Kommunikationsvorgänge zwischen den Betriebssystem 220 und einem Anwendungsprozess 205 zu überwachen, kann sie in ähnlicher Weise so konfiguriert werden, dass sie sich transparent zwischen dem Dateisystem 235 und dem Betriebssystem 220 befindet. Diese Konfiguration kann durch Hooking erzielt werden. Alternativ kann, wenn die Überwachungsschicht 210 installiert wird, dieselbe so konfiguriert werden, dass Teile des Betriebssystems 220, die mit dem Dateisystem 235 kommunizieren, so umgeschrieben werden, dass alle Kommunikationsvorgänge zwischen dem Betriebssystem 220 und dem Dateisystem 235 über die Überwachungsschicht 210 umgeleitet werden.
Die 3A ist ein Blockdiagramm zum detaillierteren Veranschaulichen der Logikspeicherstruktur 285 eines auf einem Webserver 155 laufenden Anwendungsprozesses gemäß einer Ausführungsform der Erfindung. Multitasking-Betriebssysteme erzeugen für jeden Prozess separate Logikspeicherstrukturen 285, um zu gewährleisten, dass nicht mehrere Anwendungen versuchen, auf dieselbe Speichersektion zuzugreifen. Diese Logikspeicherstrukturen 285 werden in eine Anzahl von Speicherseiten unterteilt, von denen jede in einem logischen Speicher über eine charakteristische Adresse verfügt.
Anwendungsprozesse speichern ausführbaren Code und Daten in den Logikspeicherstrukturen, und das Betriebssystem 220 bildet Logikspeicheradressen an Orten im physikalischen Speicher 106 oder Datenspeicher 108 ab.
Diese Logikspeicherstruktur 285 verfügt über einen Bereich von Adressen 370 für Speicherseiten zum Speichern des Betriebssystemskernels, wobei es sich um denjenigen ausführbaren Code handelt, der Anweisungen zum Ausführen von Betriebssystembezogenen Tasks enthält. Auf den Bereich der den Kernel speichernden Adressen 370 kann ein einzelner Anwendungsprozess nicht zugreifen. Größtenteils verursacht jeder Versuch, in den für den Kernel spezifizierten Bereich 370 zu speichern, einen Fehler, und es wird der Betrieb des den Schreibvorgang suchenden Prozesses gestoppt.
Außerdem verfügt die Speicherstruktur 285 über einen Bereich von Speicheradressen 275, der für ausführbaren Code spezifiziert ist, der mit dem Ausführen von Anwendungsprozesstasks in Zusammenhang steht. Wenn beispielsweise der fragliche Anwendungsprozess eine Textverarbeitungsanwendung ist, könnte dieser Abschnitt Anweisungen zum Formatieren von Text enthalten. Wenn der Anwendungsprozess erstmals ausgeführt wird, wird der für diesen Prozess spezifische ausführbare Code in diesen Abschnitt 375 geladen. Wenn Module ausführbaren Codes im für ausführbaren Code spezifizierten Abschnitt gespeichert sind, würden sich auch der bevorzugte Ladeort 295 und der alternative Ladeort 298 eines hoch gefährdeten Moduls ausführbaren Codes in ähnlicher Weise in diesem Abschnitt 375 befinden.
Ferner beinhaltet die Speicherstruktur 285 einen Bereich von Speicheradressen, die für diesen Anwendungsprozess spezifische Daten konzipiert sind. Genauer gesagt, enthält sie Platz 380 für einen Stack, wobei es sich um den Speicherraum handelt, der Daten mit Größen zugeordnet ist, die vorab bekannt sind. Die Speicherstruktur 285 beinhaltet auch Raum 385 für einen Heap, wobei es sich um Speicherraum handelt, der Daten mit Größen und einer Organisation zugeordnet ist, die erst dann bekannt werden, wenn der Anwendungsprozess 205 läuft.
Durch Aufrechterhalten einer separaten Logikspeicherstruktur für jeden Anwendungsprozess 205 gewährleistet das Betriebssystem 220, dass die mehreren Anwendungsprozesse nicht versuchen, auf denselben Abschnitt physikalischen Speichers zuzugreifen. Jedoch ist dieser Prozess des Abbildens mehrerer Logikspeicherstrukturen auf Stellen im physikalischen Speicher 106 und Datenspeicher 108 sehr Ressourcen-intensiv. Demgemäß speichert das Betriebssystem 220 bestimmte üblicherweise verwendete Module für alle Anwendungsprozesse an einem festen Ort im logischen Speicher 285, und es bildet diesen Ort auf einen festen Punkt im physikalischen Speicher ab. Beispielsweise kann das allgemein verwendete Modul stat.dll so vorkonfiguriert werden, dass es immer an der logischen Speicheradresse 85000 geladen wird, und das Betriebssystem 220 würde den stat.dll enthaltenden physikalischen Speicherort für jeden Anwendungsprozess 205 an die logische Speicheradresse 85000 laden, um so seine Verwaltungsbelastung zu verringern.
Die 3B ist ein Blockdiagramm, das eine detailliertere Ansicht des Stacks 340 für den Anwendungsprozess 205 gemäß einer Ausführungsform der Erfindung zeigt. Der Stack 340 verfügt über eine Ansammlung verschiedener Datenbereiche 355, 360, 365. Obwohl nur drei Datenbereiche dargestellt sind, kann ein Stack über jede beliebige praxisgerechte Anzahl derartiger Bereiche verfügen. Diese Datenorte werden dazu verwendet, verschiedene Datenwerte für den Anwendungsprozess 205 zu speichern. Wie oben erörtert, wird der Stack 340 erzeugt, um Daten mit einer Größe und Eigenschaften zu speichern, die bereits bekannt sind. So verfügen die Datenbereiche 355, 360, 365 häufig über feste Speicherumfänge. Der Stack 340 verfügt ferner über einen Datenbereich 345, der für eine Rücksprungadresse konzipiert ist. Ausführbarer Code schließt typischerweise mit einem Aufruf auf eine Rücksprungadresse.
Der Anwendungsprozess 205 arbeitet durch Verschieben einer Rücksprungadresse auf einen Stack und anschließendes Verschieben zusätzlicher Werte auf denselben. Beispielsweise verschiebt eine erste Routine, die Daten bekannter Größe von einer spezifizierten Eingabe aufnimmt, ihre Rücksprungadresse auf den Stack, und dann ruft sie eine zweite Routine auf, die dazu vorgesehen ist, die Eingabe zu akzeptieren und abzuspeichern. Die zweite Routine ruft, nachdem sie die Eingabe abgespeichert hat, die ursprünglich eingesetzte Rücksprungadresse auf, und als letzten Ausführungspunkt gibt sie die Steuerung an die erste Routine zurück.
Viren verwenden Pufferüberlauf-Angriffe, um die Kontrolle über ein Computersystem zu erlangen, auf dem ein Prozess mit einem Stack ausgeführt wird, und zwar durch Liefern eines Datenstrings 335 in einen der Datenbereiche 355, 360, 365, der größer ist, als der Umfang, für den der Bereich konzipiert ist, um andere Bereiche, einschließlich der Rücksprungadresse 345, zu überschreiben. Beispielsweise kann der Webserver 155 dazu konzipiert sein, GET-Anforderungen von Fernsystemen zu empfangen und die Köpfe, die maximal 30 Bytes beinhalten, im Datenbereich 355 zu speichern. Ein sich bereits im Fernsystem 175 befindendes Virus, das versucht, sich selbst auf den Webserver 155 auszubreiten, kann eine GET-Anforderung mit einem Kopf mit einer Länge von 55 Bytes unterbreiten, wodurch die Datenbereiche 355, 360, 365 überlaufen und ein Überschwappen in den Bereich 345 der Rücksprungadresse erfolgt.
Da die Größen der Datenbereiche für die Stacks vieler Anwendungen gut bekannt sind, kann ein Virus so konfiguriert werden, dass es einen String mit einer solchen Länge unterbreitet, dass die vorige Rücksprungadresse durch eine solche gemäß der Wahl des Designers des Virus ersetzt wird. Ferner werden die Datenbereiche des Stacks 355, 360, 365 nun mit Viruscode gefüllt.
Demgemäß liest die Routine, die die HTTP-GET-Anforderungen empfängt, wenn sie einen Aufruf an den Rücksprungadressbereich 345 des Stacks 340 macht, anstatt eine Rücksprungadresse zu lesen, die die Adresse einer anderen gutartigen Routine liest, eine Rücksprungadresse, die auf einen ausführbaren Viruscode zeigt. Typischerweise zeigt diese neue Rücksprungadresse auf einen anderen Ort 355 im Stack 340, der mit ausführbarem Viruscode umgeschrieben wurde, was durch den Pufferüberlauf erfolgt.
Jedoch ist es bei einigen Betriebssystemen nicht möglich, die Speicheradresse des neu eingeführten Viruscodes zu bestimmen, da der Stack über keinen festen Ort im logischen Speicher 285 verfügt. Statt dessen wird der Ort im Stack durch ein Register in der CPU spezifiziert. Demgemäß konfigurieren Virusdesigner, die versuchen, solche Systeme anzugreifen, die Viren in solcher Weise, dass ein Aufruf auf üblicherweise verwendete Module ausführbaren Codes, mit gut bekannten Adressen, erfolgt, die so konfiguriert sind, dass sie den Stack oder einen anderen Datenbereich aufrufen, der für bösartigen Code anfällig ist.
Beispielsweise unterbreitet das oben erörterte Virus eine HTTP-GET-Anforderung, und sie fügt ausführbaren Viruscode in die Datenbereiche 355, 360 und 365 sowie eine neue Rücksprungadresse im Rücksprungadressbereich 345 ein. Die neue Rücksprungadresse ist die gut bekannte Adresse eines Eintrittspunkts für ein üblicherweise verwendetes Modul 280 ausführbaren Codes. Die Anweisungen im Modul 280 ausführbaren Codes beinhalten einen Aufruf auf den Stack 340. Der Stack 340 kann über einen festen Ort oder einen variablen Ort, der durch ein Datenregister verfolgt wird, verfügen. An dieser Stelle beginnt das Betriebssystem den Viruscode auszuführen, der sich im anfänglichen Datenbereich des Stacks 355 befindet.
Wenn jedoch das üblicherweise verwendete Modul 280 ausführbaren Codes an einen anderen Ort verschoben wird, zeigt die modifizierte Rücksprungadresse auf einen alternativen Ort, wodurch ein Fehler erzeugt wird, jedoch die Ausführung des Virus umgangen wird.
Die 4 veranschaulicht einen Komponentenüberblick für eine Überwachungsschicht 210 gemäß einer Ausführungsform der Erfindung. Die in der 4 dargestellten Module sind vorzugsweise in der Speichereinheit 108 abgespeichert, und sie werden in den Systemspeicher 106 geladen. Jedoch können die die Überwachungsschicht 210 bildenden Module auch in Firmware, einer Programmlogik oder jeder beliebigen Hardware oder Schaltungsanordnung gespeichert sein, die dazu verwendet wird, für das Funktionsvermögen dieser Module zu sorgen. Die Überwachungsschicht verfügt über ein Bedrohungsmodul 406, das so konfiguriert ist, dass es ermittelt, ob ein Modul 280 ausführbaren Codes ein hoch gefährdetes Modul ist, und dass es hoch gefährdete Module als solche spezifiziert. Die Überwachungsschicht 210 verfügt ferner über ein Auswahlmodul 408. Das Auswahlmodul 408 ist so konfiguriert, dass den alternativen Ladeort eines hoch gefährdeten Moduls 280 bestimmt. Die Bestimmung des neuen Ladeorts kann zufällig oder gemäß vorbestimmten Kriterien ausgeführt werden. Das Auswahlmodul 408 leitet die neue Speicheradresse entweder an das Speicher-Reservierungsmodul 402 oder das Rekonfigurierungsmodul 404 weiter.
Bei Ausführungsformen, bei denen die Überwachungsschicht 210 so konfiguriert ist, dass sie sich zwischen einem Anwendungsprozess 205 und dem Betriebssystem 220 befindet, ist das Speicher-Reservierungsmodul 402 so konfiguriert, dass es einen Abschnitt des Speichers mit dem bevorzugten Ladeort 295 des Moduls 280 ausführbaren Codes reserviert. Wenn das Speicher-Reservierungsmodul 402 einen alternativen Ladeort vom Auswahlmodul 408 empfängt, wird es so konfiguriert, dass es Speicherraum zwischen dem bevorzugten Ladeort 295 und dem alternativen Ladeort 290 reserviert, um das Betriebssystem 220 dazu zu zwingen, das Modul 280 ausführbaren Codes am alternativen Ladeort 290 zu laden.
Alternativ kann das Reservierungsmodul 402, anstatt dass es kontinuierliche Blöcke reserviert, kleinere Speicherabschnitte reservieren, um zu gewährleisten, dass sich keine "offenen" Räume im Speicher befinden, die ausreichend groß wären, um das Modul 280 ausführbaren Codes zu laden, um so das Betriebssystem 220 dazu zu zwingen, dasselbe im nächst verfügbaren nicht reservierten Bereich zu laden, der dann der alternative Ladeort 290 ist. Demgemäß kann, wenn ein Modul ausführbaren Codes mit einer Größe von 20000 Bytes normalerweise im Bereich von der Speicheradresse 250000 bis zur Speicheradresse 270000 liegen würde, und das Auswahlmodul 408 ermittelt hat, dass es im Bereich von 290000 bis 310000 abgespeichert werden sollte, das Speicher-Reservierungsmodul 408 kleine Speicherbereiche bei 252000, 272000 und 289999 reservieren. Das Betriebssystem 220 würde nach dem ersten ununterbrochenen Bereich von 20000 Bytes schauen und das Modul ausführbaren Codes an der Speicheradresse 290000 laden.
Die Überwachungsschicht 210 verfügt ferner über ein Speicher-Rekonfigurationsmodul 404. Bei denjenigen Ausführungsformen, bei denen sich die Überwachungsschicht 210 zwischen dem Dateisystem 235 und dem Betriebssystem 220 befindet, ist das Speicher-Rekonfigurationsmodul 404 so konfiguriert, dass es die bevorzugten Ladeorte von Modulen ausführbaren Codes ändert. Das Speicher-Rekonfigurationsmodul 404 führt diese Funktion dadurch aus, dass es eine herausgehende Modulanforderung, wie sie an das Dateisystem 235 geschickt wird, mit einem Tag versieht. Wenn das mit Tag versehene Modul durch das Dateisystem 235 zurückgeliefert wird, ändert das Speicher-Rekonfigurationsmodul 404 den im Kopf des Moduls 280 ausführbaren Codes liegenden bevorzugten Ladeort. Wenn das Betriebssystem 220 das Modul 280 ausführbaren Codes empfängt, lädt es dasselbe am alternativen Ladeort 290.
Die 5 ist ein Flussdiagramm zum Veranschaulichen eines Verfahrens zum Verhindern von Pufferüberlauf-Angriffen durch Reservieren eines Speicherorts entsprechend einer Ausführungsform. Das Verfahren beginnt dann, wenn ein Anwendungsprozess 205 oder das Betriebssystem 220 versucht, ein Modul 280 ausführbaren Codes zu laden, 505. Die Anforderung wird durch die Überwachungsschicht 210 abgefangen, 510. Das Bedrohungsmodul 406 ermittelt, 515, ob die Anforderung einem hoch gefährdeten Modul 280 ausführbaren Codes entspricht. Bei einer ersten Ausführungsform ist das hoch gefährdete Modul ein allgemein verwendetes Modul, das ausführbaren Code mit einem Sprung auf einen Datenbereich enthält. Bei einer zweiten Ausführungsform werden alle von mehreren Anwendungsprozessen verwendeten Module als hoch gefährdet bestimmt. Bei einer dritten Ausführungsform werden alle Module, die ausführbaren Code enthalten, als hoch gefährdet bestimmt.
Wenn das Modul 280 ausführbaren Codes als solches bestimmt wird, das nicht hoch gefährdet ist, wird die Ladeanforderung weitergeleitet, und das Modul 280 ausführbaren Codes wird geladen, 530. Wenn das Modul 280 ausführbaren Codes als hoch gefährdetes Modul bestimmt wird, bestimmt das Auswahlmodul 408 einen alternativen Ladeort für dasselbe. Die neue Adresse kann zufällig erzeugt werden oder gemäß vorbestimmten Faktoren ausgewählt werden. Dann reserviert das Speicher-Reservierungsmodul 402, 520, Orte im Speicher zwischen dem bevorzugten Ladeort 295 und dem alternativen Ladeort 290. Dann wird die Anforderung an das Betriebssystem 220 weitergeleitet, 525, das, wenn es herausfindet, dass der bevorzugte Ladeort 295 belegt ist, das Modul 280 ausführbaren Codes am alternativen Ladeort 290 lädt, 530.
Die 6 ist ein Flussdiagramm zum Veranschaulichen eines Verfahrens zum Verhindern von Pufferüberlauf-Angriffen durch Ändern des bevorzugten Ladeorts 295 für ein Modul 280 ausführbaren Codes gemäß einer zweiten Ausführungsform der Erfindung. Bei dieser Ausführungsform befindet sich die Überwachungsschicht 210 zwischen dem Betriebssystem 220 und dem Dateisystem 235. Das Verfahren beginnt damit, dass das Betriebssystem 220 oder ein Anwendungsprozess 205 eine Ladeanforderung auslöst. Das Betriebssystem 220 verarbeitet die Ladeanforderung und liefert sie an das Dateisystem 235, 610. Die Überwachungsschicht 210 fängt diese Anforderung ab. Das Bedrohungsmodul 406 bestimmt, 615, ob die Anforderung einem hoch gefährdeten Modul 280 ausführbaren Codes entspricht.
Wenn das Modul 280 ausführbaren Codes nicht als hoch gefährdet bestimmt wird, wird die Anforderung ohne Änderung an das Dateisystem 235 weitergeleitet. Wenn das Modul 280 ausführbaren Codes als hoch gefährdet bestimmt wird, wird die Anforderung mit einem Tag versehen, 620, da sie einem hoch gefährdeten Modul zugeordnet ist. Dann wird die Anforderung an das Dateisystem 235 weitergeleitet, das das Modul 280 aus dem Datenspeicher entnimmt, 625. Wenn das Dateisystem 235 versucht, das Modul 280 ausführbaren Codes an das Betriebssystem 220 weiterzuleiten, 628, fängt die Überwachungsschicht 210 das Modul 280 ab. Das Modul 280 wird auf eine zugeordnete Anforderung mit Tag geprüft, 630. Wenn die Ladeanforderung mit einem Tag versehen ist, bestimmt das Auswahlmodul 408 einen alternativen Ladeort für das Modul 280 ausführbaren Codes, und es liefert den alternativen Ladeort an das Rekonfigurationsmodul 404 weiter. Wenn die Ladeanforderung nicht mit Tag versehen ist, wird das Modul 280 ausführbaren Codes ohne Änderung weitergeleitet. Die neue Adresse kann zufällig erzeugt oder gemäß vorbestimmten Faktoren ausgewählt werden. Das Rekonfigurationsmodul 404 schreibt den Abschnitt des Moduls 280, der zum selbst bevorzugten Ladeort gehört, um, 635, und es leitet das Modul 280 an das Betriebssystem 220 weiter, 640. Das Betriebssystem 220 scannt das Modul 280 ausführbaren Codes nach seinem bevorzugten Ladeort ab, und es speichert es am alternativen Ladeort 290 ab.
Die obige Beschreibung ist enthalten, um den Betrieb der bevorzugten Ausführungsformen zu veranschaulichen, und sie soll den Schutzumfang der Erfindung nicht beschränken. Der Schutzumfang der Erfindung ist nur durch die folgenden Ansprüche beschränkt. Aus der obigen Erörterung sind für den Fachmann viele Variationen erkennbar, die jedoch durch den Schutzumfang der Erfindung umfasst sind.
Die Erfindung kann durch ein auf einem Computer arbeitendes Computerprogramm implementiert werden. Gemäß einer Erscheinungsform der Erfindung ist demgemäß ein Speichermedium geschaffen, das durch einen Prozessor implementierbare Anweisungen speichert, die dazu dienen, einen Prozessor so zu steuern, dass er das oben beschriebene Verfahren ausführt.
Ferner kann das Computerprogramm in elektrischer Form z. B. durch Herunterladen des Codes über ein Netzwerk wie das Internet erhalten werden. Demgemäß ist gemäß einer anderen Erscheinungsform der Erfindung ein elektrisches Signal geschaffen, das durch einen Prozessor implementierbare Anweisungen führt, die dazu dienen, einen Prozessor so zu steuern, dass er das oben beschriebene Verfahren ausführt.

Claims

Verfahren zum Verhindern eines Pufferüberlauf-Angriffs in einem Computersystem (100), mit folgenden Schritten: Erfassen (510) eines Versuchs, ein Modul (280), das einen bevorzugten Ladeort (295) aufweist und ausführbaren Code enthält, in einen Speicher (285) des Computersystems zu laden, gekennzeichnet durch Bestimmen (515), ob das Modul eines ist, das besonders anfällig auf einen Pufferüberlauf-Angriff ist, und in Reaktion auf die Bestimmung, daß das Modul ein besonders anfälliges Modul ist, Veranlassen (520, 525, 530), daß das Modul an einen anderen Speicherort (290) als den bevorzugten Ladeort geladen wird.
Verfahren nach Anspruch 1, wobei der Schritt zum Veranlassen, daß das Modul an einen anderen Ort als den bevorzugten Ladeort geladen wird, einen Unterschritt zum Reservieren (520) eines Speicherbereichs umfaßt, der einen Abschnitt des bevorzugten Ladeorts enthält.
Verfahren nach Anspruch 1, wobei der Schritt zum Veranlassen, daß das Modul an einen anderen Ort als den bevorzugten Ladeort geladen wird, folgende Unterschritte umfaßt: Abfangen (510) eines Versuchs, das Modul von einem Datenspeicher her zu laden, und Ersetzen des bevorzugten Ladeorts des Moduls durch einen alternativen bevorzugten Ladeort, so daß das Modul an den alternativen bevorzugten Ladeort geladen wird.
Verfahren nach Anspruch 1, wobei der Schritt zum Bestimmen, ob das Modul ein besonders anfälliges Modul ist, einen Unterschritt zum Bestimmen, ob das Modul von mehreren Anwendungsprozessen verwendet wird, umfaßt.
Verfahren nach Anspruch 1, wobei der Schritt zum Bestimmen, ob das Modul ein besonders anfälliges Modul ist, einen Unterschritt zum Bestimmen umfaßt, ob das Modul ausführbaren Code mit Anweisungen zum Aufrufen eines Speicherbereichs enthält, der gegenüber bösartigem Code anfällig ist.
Verfahren nach Anspruch 5, wobei der Speicherbereich ein Stack (380) ist.
Verfahren nach Anspruch 1, wobei alle Module, die ausführbaren Code enthalten, als besonders anfällige Module bestimmt werden.
System zum Verhindern von Pufferüberlauf-Angriffen in einem Computersystem, aufweisend: ein Bedrohungsmodul (406) zum Lesen einer Ladeanforderung, die ein zugehöriges Modul (280) mit ausführbarem Code aufweist, dadurch gekennzeichnet, daß das Bedrohungsmodul außerdem eingerichtet ist zu bestimmen, ob das zugehörige Modul mit ausführbarem Code ein auf einen Pufferüberlauf-Angriff besonders anfälliges Modul ist, und ein in Verbindung mit dem Bedrohungsmodul stehendes Auswahlmodul (408) zum Bestimmen eines alternativen Ladeorts für das Modul mit ausführbarem Code in Reaktion auf eine Bestimmung durch das Bedrohungsmodul, daß das Modul mit ausführbarem Code ein besonders anfälliges Modul ist.
System nach Anspruch 8 mit einem in Verbindung mit dem Auswahlmodul stehenden Speicher-Reservierungsmodul (402), um vom Auswahlmodul einen alternativen Ladeort zu empfangen und durch Reservieren eines Abschnitts des bevorzugten Ladeorts des Moduls mit ausführbarem Code zu veranlassen, daß das Modul mit ausführbarem Code an den alternativen Ladeort geladen wird.
System nach Anspruch 8, mit einem in Verbindung mit dem Auswahlmodul stehenden Speicher-Rekonfigurationsmodul (404), um einen bevorzugten Ladeort des zugehörigen Moduls mit ausführbarem Code durch den vom Auswahlmodul bestimmten alternativen Ladeort zu ersetzen.
System nach Anspruch 8, wobei das Bedrohungsmodul eingerichtet ist zu bestimmen, daß das zugehörige Modul mit ausführbarem Code ein besonders anfälliges Modul ist, wenn es von mehreren Anwendungsprozessen verwendet wird.
System nach Anspruch 8, wobei das Bedrohungsmodul eingerichtet ist zu bestimmen, daß das zugehörige Modul mit ausführbarem Code ein besonders anfälliges Modul ist, wenn es ausführbaren Code mit Anweisungen zum Lesen eines Speicherabschnitts enthält, der gegen bösartigen Code anfällig ist.
System nach Anspruch 12, wobei der Speicherabschnitt ein Stack (380) ist.
System nach Anspruch 8, wobei alle Module mit ausführbarem Code als besonders anfällige Module bestimmt werden.
Computerprogrammprodukt, aufweisend: ein computerlesbares Medium, das computerausführbare Anweisungen speichert, um bei Ausführung einen Prozessor zum Ausführen aller Schritte eines Verfahrens nach einem der Ansprüche 1 bis 7 zu steuern.
Elektrisches Signal, das auf einem Prozessor implementierbare Anweisungen trägt, um einen Prozessor zum Ausführen des Verfahrens nach einem der Ansprüche 1 bis 7 zu steuern.