DE69802834T2

DE69802834T2 - Verbesserung der sicherheit für nicht-vertrauten ausführbaren code

Info

Publication number: DE69802834T2
Application number: DE69802834T
Authority: DE
Inventors: Sudeep Bharati; Barry Bond
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 1997-08-28
Filing date: 1998-08-25
Publication date: 2002-09-12
Anticipated expiration: 2018-08-26
Also published as: EP1021753A1; JP2001514411A; WO1999010795A1; JP3572016B2; JP4528517B2; US6275938B1; DE69802834D1; JP2004118866A; EP1021753B1

Description

Gebiet der Erfindung

Die vorliegende Erfindung betrifft elektronische Datenverarbeitung und insbesondere das Vermeiden einer Systembeschädigung aus der Ausführung von Programmen, die nicht vertrauenswürdigen Code enthalten.

Hintergrund der Erfindung

Fortschritte bei Internet-Browsern erschaffen dynamische und interaktive Seiten im World Wide Web. Jedoch schaffen die Fortschritte auch erhöhte Computersystem-Sicherheitsgefahren, die davon herrühren können, lediglich eine Web-Seite zu betrachten. Internet-Browser laden automatisch Programme oder anderen ausführbaren Code, die in die Web-Seite eingebettet sind, herunter und führen sie aus. Die Fähigkeit, Programme von einem entfernten Computer herunterzuladen und auszuführen, setzt den Wirtscomputer verschiedenen Sicherheitsrisiken aus. Feindliche Programme können zum Beispiel ein Computersystem oder Daten auf dem Computersystem modifizieren, Benutzerdaten, wie Paßwörter und Bankkontoinformationen stehlen, oder Systembetriebsmittel für den Benutzer unbrauchbar machen. Als Ergebnis sind Sicherheitsfragen bei der Entwicklung von Internet-Anwendungen entscheidend.
Eine Herangehensweise des Stands der Technik liefert Sicherheit für einen besondere Form von ausführbaren Code, der als Java-Applets bekannt ist. Das Quellprogramm des ausführbaren Codes wird geschrieben und zu plattformunabhängigen Byte- Code konvertiert heruntergeladen. Der plattformunabhängige in Token umgewandelte Byte-Code läuft auf einer virtuellen Maschine, die strenge Grenzen darauf anwendet, was der ausführbare Code tun kann. Der ausführbare Code in der Herangehensweise des Stands der Technik hat nur einen sehr begrenzten Zugriff auf das Betriebssystem. Wenn die Java-Sprache mächtiger wird, muß sie folglich viele Funktionen duplizieren, die das Betriebssystem schon ausführt.
Ein Artikel aus eSafe technologies mit dem Datum 28. April 1997 mit dem Titel "New Anti-Vandal Software Provides 'Next Generation' PC Protection," beschreibt ein Produkt, das einen Sandbox-Speicher einsetzt, der außerhalb des Speichers liegende Zugriffe von einem nicht vertrauenswürdigen Anwendungsprogramm beschränkt. Die europäische Patentanmeldung 0667572 A1, eingereicht am 24. Januar 1995, beschreibt ein System zur Verhinderung eines unberechtigten Gebrauchs von Betriebsmitteln durch Modifizieren einer Kopfdatei von Anwendungsprogrammen, um Verknüpfungen mit einem Betriebssystemkern durch Verknüpfungen mit einem Abfangprogramm zu ersetzen, das den Lizensierungsstatus eines Anwendungsprogramms bestimmt, wenn es aufgerufen wird, jedoch bevor es ausgeführt werden kann.
ActiveX-Controls sind eine Form ausführbaren Codes, die die eingeschränkten Fähigkeiten von Java vermeiden. ActiveX ist ein Ergebnis zweier Technologien von Microsoft Corp., die als OLE (Objektverküpfung und -Einbettung) und COM (Komponentenobjektmodell) bezeichnet werden. ActiveX unterstützt Merkmale, die es ihm ermöglichen, das Internet auszunutzen. Zum Beispiel kann eine ActiveX-Control automatisch herunter geladen und durch einen Web-Browser ausgeführt werden.
Da ActiveX-Controls in Maschinencode geschrieben sind, haben sie vollen Zugriff auf das Betriebssystem und den Arbeitsspeicher, in dem die Controls laufen. Dieser Zugriff ist mächtig, wenn die Control in einer eng gesteuerten Umgebung, wie einer Erweiterung einer eigenständigen Anwendung läuft. Jedoch schafft der volle Zugriff auf das Betriebssystem ernste Sicherheitsprobleme, wenn ActiveX-Controls von unbekannten oder nicht vertrauenswürdigen Quellen im Internet durch eine an Anwendung, wie dem Web-Browser Internet Explorer heruntergeladen werden. ActiveX-Controls sind dazu bestimmt, auf alle Dienste des Betriebssystems zuzugreifen. Eine feindliche ActiveX- Control könnte nach Informationen auf der Festplatte des Wirtssystems suchen, einen Virus implantieren oder das Wirtssystem beschädigen. Das Problem mit dem unbeschränkten Zugriff von ActiveX auf das Betriebssystem ist es, daß der unbeschränkte Zugriff das Wirtssystem in die Gefahr von Sicherheitslücken bringt.
Folglich gibt es einen Bedarf nach einer Form ausführbaren Codes mit der Fähigkeit, auf die Leistung des Wirtsbetriebssystem zuzugreifen, jedoch ohne die Sicherheit des Wirtsystems aufs Spiel zu setzen.

Zusammenfassung der Erfindung

Die vorliegende Erfindung implementiert ein Sicherheitsverfahren für nicht vertrauenswürdigen ausführbaren Code, der in direkt ausführbaren Maschinencode geschrieben ist. Der ausführbare Code wird in einen vorher zugewiesenen Speicherbereich, oder Sandbox geladen, von dem Verweise auf den außerhalb liegenden Speicher beschränkt sind. Prüfungen ("Schnüffel-Code"), die zum ausführbaren Code hinzugefügt werden, verstärken diese Beschränkungen während der Ausführung. Herkömmliche Anwendungsprogramm-Schnittstellen- (API)-Aufrufe im nicht vertrauenswürdigen Code werden durch Übersetzungscode-Module ("Thunks") ersetzt, die es dem ausführbaren Code gestatten, auf das Wirtsbetriebssystem zuzugreifen, während Lücken der Sicherheit des Wirtsystems verhindert werden. Statische Verknüpfungen in der Steuerung oder dem Applet werden durch Aufrufe an Thunk- Module ersetzt. Wenn ein API-Aufruf während der Ausführung gemacht wird, wird die Kontrolle an den Thunk übertragen, der feststellt, ob der API-Aufruf einer ist, von dem zugelassen werden sollte, auf dem Betriebssystem ausgeführt zu werden oder nicht.
Ein Aspekt der Erfindung ist ein Verfahren zur Ausführung eines nicht vertrauenswürdigen Programms, wie im unabhängigen Anspruch 1 definiert, und ein entsprechender Emulator, wie im Anspruch 17 definiert.

Kurze Beschreibung der Zeichnungen

Fig. 1 ist eine Systemansicht einer exemplarischen Computerumgebung, in der die vorliegende Erfindung implementiert werden kann.
Fig. 2 ist ein Blockdiagramm einer Ausführungsumgebung, die die vorliegende Erfindung enthält.
Fig. 3 ist ein Ablaufplan, der die Hauptschritte der Erfindung beschreibt.
Fig. 4 ist ein vereinfachtes Blockdiagramm eines Sandbox-Bereichs im Speicher.

Detaillierte Beschreibung der Erfindung

In der folgenden detaillierten Beschreibung der Ausführungsformen wird auf die beigefügten Zeichnungen bezug genommen, die einen Teil hiervon bilden, und in denen illustrativ spezifische Ausführungsformen gezeigt werden, in denen die Erfindung praktiziert werden kann. Diese Ausführungsformen werden ausreichend detailliert beschrieben, um es Fachleuten zu ermöglichen, die Erfindung zu praktizieren, und es ist zu verstehen, daß andere Ausführungsformen genutzt werden können und daß strukturelle, logische und elektrische Änderungen vorgenommen werden können, ohne den Geist und Rahmen der vorliegenden Erfindungen zu verlassen. Die folgende detaillierte Beschreibung ist daher nicht in einem einschränkenden Sinne aufzufassen, und der Rahmen der vorliegenden Erfindungen wird nur durch die beigefügten Ansprüche definiert. Die Numerierung der Figuren wird so vorgenommen, daß identische Komponenten, die in mehreren Figuren erscheinen, durch dieselben Bezugsziffern identifiziert werden.
Fig. 1 und die folgende Erläuterung sind dazu bestimmt. eine kurze, allgemeine Beschreibung einer geeigneten Computerumgebung zu liefern, in der die Erfindung implementiert werden kann. Obwohl es nicht erforderlich ist, wird die Erfindung im allgemeinen Kontext computerausführbarer Befehle beschrieben, wie Programmodulen, die durch einen Personal-Computer ausgeführt werden. Im allgemeinen umfassen Programmodule Routinen, Programme, Objekte, Komponenten, Datenstrukturen usw., die bestimmte Aufgaben ausführen oder bestimmte abstrakte Datentypen implementieren. Überdies werden Fachleute erkennen, daß die Erfindung mit anderen Computersystem-Konfigurationen praktiziert werden kann, einschließlich Taschengeräten, Multiprozessorsystemen, mirkroprozessorbasierende oder programmierbare Konsumelektronik, Netzwerk-PCs, Minicomputern, Großrechnern und dergleichen. Die Erfindung kann auch in verteilten Computerumgebungen praktiziert werden, wo Aufgaben durch entfernte Verarbeitungsvorrichtungen ausgeführt werden, die durch ein Kommunikationsnetz verbunden sind. In einer verteilten Computerumgebung können Programmodule sowohl in lokalen als auch entfernten Speichervorrichtungen lokalisiert sein.
Fig. 1 stellt eine kurze, allgemeine Beschreibung einer geeigneten Computerumgebung bereit, in der die Erfindung implementiert werden kann. Die Erfindung wird im folgenden im allgemeinen Kontext computerausführbarer Befehle beschrieben, wie Programmodulen, die durch einen Personal-Computer (PC) ausgeführt werden; jedoch sind andere Umgebungen möglich. Programmodule umfassen Routinen, Programme, Objekte, Komponenten, Datenstrukturen, usw., die bestimmte Aufgaben ausführen oder bestimmte abstrakte Datentypen implementieren. Fachleute werden erkennen, daß die Erfindung mit anderen Computersystem-Konfigurationen praktiziert werden kann, einschließlich Taschengeräten, Multiprozessorsystemen, mirkroprozessorbasierende oder programmierbare Konsumelektronik, Netzwerk-PCs, Minicomputern, Großrechnern und dergleichen. Die Erfindung kann auch in verteilten Computerumgebungen praktiziert werden, wo Aufgaben durch entfernte Verarbeitungsvorrichtungen ausgeführt werden, die durch ein Kommunikationsnetz verbunden sind. In einer verteilten Computerumgebung können Programmodule sowohl in lokalen als auch entfernten Speichervorrichtungen lokalisiert sein.
Fig. 1 zeigt ein exemplarisches System zur Implementierung der Erfindung. Es setzt eine universelle Computervorrichtung in der Form eines herkömmlichen Personalcomputers 20 ein, der eine Verarbeitungseinheit 21, einen Systemspeicher 22, und einen Systembus 23 aufweist, der den Systemspeicher und andere Systemkomponenten mit der Verarbeitungseinheit 21 koppelt. Der Systembus 23 kann irgendeiner verschiedener Typen sein, einschließlich einem Speicherbus oder Speicherkontroller, einem Peripheriebus und einem lokalen Bus, und kann irgendeine einer Vielfalt von Busstrukturen verwenden. Der Systemspeicher 22 weist einen Festwertspeicher (ROM) 24 und einen Direktzugriffsspeicher (RAM) 25 auf. Ein Basis Eingabe-/Ausgabesystem (BIOS) 26, das im ROM 24 gespeichert ist, enthält die Basisroutinen, die Informationen zwischen Komponenten des Personalcomputers 20 übertragen. Das BIOS 24 enthält auch Startroutinen für das System. Der Personal-Computer 20 weist ferner ein Festplattenlaufwerk 27 zum Schreiben auf und Lesen von einer (nicht gezeigten) Festplatte, ein Magnetplattenlaufwerk 28 zum Schreiben auf und Lesen von einer entfernbaren Magnetplatte 29, und optisches Plattenlaufwerk 30 zum Schreiben auf und Lesen von einer entfernbaren optischen Platte 31, wie einer CD-ROM oder anderen optischen Medium auf. Das Festplattenlaufwerk 27, das Magnetplattenlaufwerk 28 und das optische Plattenlaufwerk 30 sind mit dem Systembus 23 jeweils durch eine Festplatten-Laufwerk-Schnittstelle 32, eine Magnetplattenlaufwerk-Schnittstelle 33 und eine Schnittstelle für eine optisches Plattenlaufwerk 34 verbunden. Die Laufwerke und ihre zugehörigen computerlesbaren Medien stellen eine nichtflüchtige Speicherung computerlesbarer Befehle, Datenstrukturen, Programmodulen und anderen Daten für den Personal-Computer 20 bereit. Obwohl die hierin exemplarisch beschriebene Umgebung eine Festplatte, eine entfernbare Magnetplatte 29 und eine entfernbare optische Platte 31 einsetzt, werden Fachleute erkennen, daß andere Arten von computerlesbaren Medien, die Daten speichern können, auf die durch einen Computer zugegriffen werden kann, ebenfalls in der exemplarischen Betriebsumgebung verwendet werden können. Solche Medien können Magnetkassetten, Flash-Speicherkarten, DVDs, Bernoulli-Kassetten, RAMs, ROMs und dergleichen umfassen.
Programmodule können auf der Festplatte, der Magnetplatte 29, der optischen Platte 31, dem ROM 24 und RAM 25 gespeichert sein. Programmodule können das Betriebssystem 35, ein oder mehrere Anwendungsprogramme 36, andere Programmodule 37 und Programmdaten 38 umfassen. Ein Benutzer kann Kommandos und Informationen in den Personal-Computer 20 durch Eingabevorrichtungen wie einer Tastatur 40 und einer Zeigervorrichtung 42 eingeben. Andere (nicht gezeigte) Eingabevorrichtungen können ein Mikrophon, einen Joystick, ein Gamepad, eine Satellitenschüssel, einen Scanner oder dergleichen umfassen. Diese und andere Eingabevorrichtungen sind häufig mit der Verarbeitungseinheit 21 durch einen seriellen Schnittstellenport 46 verbunden, der mit dem Systembus 23 gekoppelt ist; sie können jedoch durch andere Schnittstellen verbunden sind, die in Fig. 1 nicht gezeigt werden, wie einen Parallelport, einen Gameport oder eine universellen seriellen Bus (USB). Ein Monitor 47 oder andere Anzeigevorrichtung ist ebenfalls mit einem Systembus 23 über eine Schnittstelle, wie einen Videoadapter 48 verbunden. Zusätzlich zum Monitor weisen Personal-Computer typischerweise andere (nicht gezeigte) periphere Ausgabevorrichtungen, wie Lautsprecher und Drucker auf.
Personal-Computer 20 können in einer Netzwerkumgebung arbeiten, wobei logische Verbindungen zu einem oder mehreren entfernten Computern wie einem entfernten Computer 49 verwendet werden. Der entfernte Computer 49 kann ein anderer Personal- Computer, ein Server, ein Router, ein Netzwerk-PC, eine gleichrangige Vorrichtung oder ein anderer gemeinsamer Netzwerkknoten sein. Er weist typischerweise viele oder alle der Komponenten auf, die oben in Verbindung mit dem Personal-Computer 20 beschrieben werden; jedoch wird in Fig. 1 nur einer Speichervorrichtung 50 dargestellt. Die in Fig. 1 dargestellten logischen Verbindungen umfassen ein lokales Netz (LAN) 51 und ein weiträumiges Netz (WAN) 52. Solche Netzwerkumgebungen sind in Büros, unternehmensweiten Computernetzen, Intranets und dem Internet üblich.
Wenn er in einer LAN-Netzwerkumgebung plaziert ist, ist der PC 20 mit dem lokalen Netz 51 durch eine Netzschnittstelle oder einen Adapter 53 verbunden. Wenn er in einer WAN-Netzwerkumgebung, wie dem Internet verwendet wird, weist der PC 20 typischerweise ein Modem 54 oder andere Einrichtungen zum Herstellen von Verbindungen über das Netz 52 auf. Das Modem 54 kann sich innerhalb oder außerhalb des PC 20 befinden, und ist mit dem Systembus 23 über einen seriellen Schnittstellenport 46 verbuden. In einer Netzwerkumgebung können Programmodule, die so dargestellt sind, daß sie sich innerhalb 20 befinden oder Abschnitte derselben in einer entfernten Speichervorrichtung 50 gespeichert sein. Natürlich sind die gezeigten Netzverbindungen illustrativ, und es können andere Einrichtungen zur Herstellung einer Kommunikationsverbindung zwischen den Computern eingesetzt werden.
In der vorliegenden Erfindung lädt ein herkömmlicher Web- Browser, der auf einem Personal-Computer 20 als ein Anwendungsprogramm 36 läuft, automatisch ein Applet vom entfernten Computer 49 herunter. Ein "Applet" ist ein kurzes Programm, üblicherweise zur Ausführung einer einzigen Funktion, das dazu bestimmt ist, aus einer anderen Anwendung heraus ausgeführt zu werden. Applets werden häufig von entfernten Computern heruntergeladen, wenn sie benötigt werden, und können manchmal vom lokalen Computer gelöscht werden, nachdem sie durch die primäre Anwendung ausgeführt worden sind.
Fig. 2 zeigt eine im wesentlichen herkömmliche Ausführungsumgebung, die Einrichtungen zum Ausführen von Applets unter der Erfindung aufweist. Der Ausdruck "Applet" ist in der Technik nicht präzise definiert. Dieser Ausdruck bezeichnet im allgemeinen ein kleines Programm zur Ausführung einer einzelnen Funktion oder eines beschränkten Bereiches von Funktionen; jedoch begrenzt der Ausdruck nicht von sich aus die Größe des Programms oder seinen Bereich von Funktionen. Applets werden häufig von einer Online-Quelle wie eine WWW-Seite für einen bestimmten Zweck heruntergeladen; in der Tat kann ein Applet heruntergeladen, unmittelbar ausgeführt und dann nach der Ausführung gelöscht werden. In der bevorzugten unten beschriebenen Ausführungsform kann der Ausdruck "Control" oder "ActiveX-Control" als synonym für ein Applet betrachtet werden. Auf jeden Fall ist die Erfindung selbst nicht auf die Verwendung mit kleinen Programmen, heruntergeladenen Programme oder irgend einer anderen spezifischen Form Programm beschränkt. Die Erfindung ist für jedes Programm nützlich, dem nicht "vertraut" wird -- das heißt, ein Programm unsicheren Ursprungs oder Effekts, das das System beschädigen könnte, wenn ihm vollen Zugriff auf die Systembetriebsmittel gegeben würden.
Ein Betriebssystem 35, wie Windows95 setzt ein Ladermodul 351 zum Laden eines normalen Anwendungsprogramms 36 in den Speicher ein. Das Programm 36 läuft unter der Kontrolle des OS 35, indem es Befehle direkt an die Verarbeitungseinheit 21 sendet, wie durch die Leitung 361 symbolisiert. Das Programm 36 führt Standard-Anwendungsprogramm-Schnittstellen-(API)-Funktionen aus, indem es Blöcke des API-Codes 352-354 aufruft. Jede API enthält Befehle, die direkt durch den Prozessor 21 ausführbar sind, um eine angegebene niedrige Funktion auszuführen, wie eine Dialogbox auf der Anzeige 47, Fig. 1 anzuzeigen. Das OS 35 umfaßt gewöhnlich Tausende einzelne APIs, die üblicherweise als mehrere Dutzend dynamische Verknüpfungsbibliotheken (DLLs) gepackt sind; im Microsoft Windows NT Betriebssystem, sind diese DLLs insgesamt als "Win32" bekannt.
Ein Emulatorprogramm läßt es zu, daß Anwendungsprogramme, die für eine Verarbeitungseinheit 21 geschrieben sind, auf einer anderen Verarbeitungseinheit mit einem anderen Befehlssatz ausgeführt werden. Der besondere, hier eingesetzte Wx86VM- Emulator 39 wurde ursprünglich dazu entwickelt, Programme, die für Intel "x86" Prozessoren (80386, 80486, Pentium, etc.) geschrieben wurden, auf Prozessoren, wie dem Digital Equipment Corp. Alpha und den IBM PowerPC auszuführen. Für den gegenwärtigen Zweck schickt eine etwas modifizierte, Wx86VM genannte Version die meisten Befehle unmodifiziert zum x88-Prozessor 2 1, blockiert oder übersetzt andere jedoch, wie beschrieben wird. Der Wx86VM ahmt Wx86 bei der Ausführung von APIs mittels Übersetzungsmodulen nach, die als "Thunk-Code" (oder nur "Thunks") 391-393 bezeichnet werden, obwohl es hier der Zweck der Thunk-Codes ist, vielmehr Sicherheit als ihren ursprünglichen Zweck bereitzustellen, es zuzulassen, daß API-Aufrufe von einer Plattform API-Code ausführen, der für eine andere Plattform geschrieben ist.
Wenn ein Applet, wie 362 ausgeführt werden soll, ruft ein Wirtsprogramm 36, wie ein Internet-Web-Browser den Emulator 39 auf. Der Emulator setzt sein eigenes Ladermodul 396 ein, um den Applet-Code in einen vorbestimmten Speicherbereich zu laden und einen anderen vorbestimmten Speicherbereich für seinen Gebrauch zuzuweisen. Diese Bereiche werden als die "Sandbox" für dieses Applet bezeichnet. Während der Ausführung des Applets kompiliert der Emulator 39 den Code des Applets in einen kompilierten Zwischenspeicher, der außerhalb der Sandbox liegt. Während des Kompilierungsprozesses fügt der Emulator auch den Speicherschnüffelcode 394 in den Zwischenspeicher ein.
Da das Applet 362 auf derselben Prozessorplattform 21 läuft, für die es geschrieben wurde, muß der Emulator 39 keine einzelnen Befehle übersetzen (symbolisiert durch Leitung 363), um eine ActiveX-Control auszuführen. Jedoch filtert und übersetzt er sie zum Zweck, Sicherheit bereitzustellen. Zum Beispiel verwenden APIs den x86-Unterbrechungs- (INT)-Befehl, um den Kern des Betriebssystems 35 aufzurufen. Ein INT-Befehl in einer Steuerung könnte daher die API-Thunks 391-393 und den Schnüffel-Code 394 umgehen und den Kern direkt aufrufen. Daher blockiert der Emulator 39 diesen Befehl unbedingt; er erzeugt auf der Leitung 364 überhaupt keinen Ausgabe-Code. Andere problematische Befehle, wie Unterprogramm-Aufrufe (CALL) und Rücksprünge (RET), und unbedingte/bedingte Sprünge (JMP/Jxx), auf der Leitung 363 werden auf der Leitung 364 durch Unterprogramm-Aufrufe ersetzt; wenn einer dieser Befehle simuliert wird, muß der Zwischenspeicher des schon kompilierten Codes durchsucht werden, um die innerhalb des Zwischenspeichers liegenden Adresse des Aufrufs oder Sprungs zu bestimmen.
API-Aufrufe vom Applet 362 gehen nicht direkt zum API-Code 352-354 weiter. Vielmehr fängt der Thunk-Code 391-393 sie ab, und entscheidet, was mit ihnen zu geschehen hat. Einige Aufrufe, wie bei 391, können durch den Thunk 391 direkt zur entsprechenden API 352 geschickt werden; diese Aufrufe können keinerlei Zerstörungen am System anrichten, und stellen daher keine Sicherheitsrisiken dar. Andere Thunks, wie 392, können abhängig von bestimmten Eigenschaften dieses besonderen Aufrufs entscheiden, ob sie einen Aufruf zu seinem entsprechenden API 353 schicken oder nicht; oder er kann den Aufruf modifizieren, bevor er ihn der API präsentiert. Einige Thunks, wie 393, verbieten einen Aufruf ihrer API 354 völlig; diese Aufrufe verletzen die Sicherheit des Systems, und können keinem nicht vertrauenswürdigen Applet 362 erlaubt werden.
Fig. 3 stellt die Hauptschritte 400 einer Ausführungsform der Erfindung dar, die es zulassen, daß auf einem Personal-Computer 20 ausgeführte Applets auf alle Betriebssystem-Dienste zugreifen, ohne die Sicherheit des Personal-Computers zu beeinträchtigen.
In den Schritten 410 lädt eine Wirtsanwendung, wie ein Web- Browser das Applet in einen zugewiesenen Speicherbereich. Der zugewiesene Speichebereich wird in dieser Anmeldung als eine Sandbox bezeichnet. Die Sandbox weist sowohl ein Anfangsspeichersegment, um das Applet zu speichern, als auch ein Laufzeit- Speichersegment für eine adressierbare Speicherung während der Ausführung des Applets auf; diese können in irgendeiner herkömmlichen Weise zugewiesen werden. In dieser Ausführungsform ruft das OS 35 den Emulator 39 im Schritt 411 auf. Der Schritt 412 weist ein Feld oder einen Bereich von Adressen im RAM 22,
Fig. 1, zur Speicherung des Codes des Applets 362 zu, und ein anderes Feld für das Applet, um es als einen Lauftzeit-Arbeitsspeicher zu verwenden; diese beiden Felder bilden zusammen die Sandbox, in der das Applet sicher laufen kann, ohne irgendein anderes Applet, Anwendungsprogramm oder andere Einrichtung des Systems zu beeinflussen. Es wird eine WX86-Sandbox für jede Sicherheitsdomäne geben -- das heißt, alle Steuerungen mit denselben Sicherheitseinstellungen spielen in derselben Sandbox. Da Sicherheitseinstellungen einen einheitlichen Ressourcen-Lokalisierer (URL) einer Web-Seite umfassen, weist jede offene Web-Seite mindestens eine Sandbox auf. In der Regel werden alle Steuerungen auf derselben Web-Seite sich in derselben Sandbox befinden. Obwohl ihre üblichen Schnittstellen nicht sicher sind, sind Zwischen-Applet-Aufrufe innerhalbe einer Sandbox akzeptabel.
Die Schritte 420 bereiten ein Applet zur Ausführung vor.
Der Schritt 421 ersetzt die statischen Verknüpfungen des Applets durch Verknüpfungen mit Thunk-Modulen. Das heißt, der Emulator 39 findet alle Aufrufe an APIs 352-354 innerhalb des Codes des Applets 362 und ändert sich in Aufrufe der entsprechenden Thunks 391-393. Eine statische Verknüpfung ist eine Verknüpfung, die während der Ausführung des Applets konstant bleibt. Eine DLL, oder dynamische Verknüpfungsbibliothek, ist eine Bibliothek ausführbarer Funktionen oder Daten, die durch eine Windows-Anwendung verwendet werden kann. Typischerweise stellt eine DLL eine oder mehrere bestimmte Funktionen bereit, und auf eine DLL wird zugegriffen, indem entweder eine statische oder dynamische Verknüpfung mit der DLL erzeugt wird. DLL- Dateien enden in der folgenden Beschreibung mit der Dateikennung .dll. Eine Thunk-DLL ist eine sichere API innerhalb der Sandbox. Die Thunk-DLLs blockieren oder beschränkten viele APIs, die als nicht sicher erachtet werden. Zum Beispiel wird CreateFile nur an bekannten Stellen erlaubt. Entsprechend wird es einem Applet nicht erlaubt, einen weiteren Prozeß zu erzeugen, um Paßwörter aufzuzeichnen. Wie oben beschrieben, übergeben einige Thunks die Steuerung an die entsprechende API. Zum Beispiel bewirken die Win32-APIs mit dem Namen "CreateWindow", "CreateDialog", "Createlcon", "CreateCursor" und ähnliche Funktionen keine anderen Prozesse, und können nicht vertrauenswürdigen Code erlaubt werden. Andererseits muß dafür gesorgt werden, daß bestimmte andere APIs für nicht vertrauenswürdigen Code vollständig nicht verfügbar sind. Zum Beispiel würde das Zulassen von "CreateProcess" es dem nicht vertrauenswürdigen Applet gestatten, ein weiteres Programm außerhalb der Sandbox auszuführen; Operationen, wie "ExitWindowsEx()" werden völlig blockiert, so daß der nicht vertrauenswürdige Code den gegenwärtigen Benutzer nicht abmelden oder den Computer abschalten kann. Ein Thunk, wie 393 blockiert eine API, indem er einen Fehlercode an die Steuerung zurückgibt, wie durch Leitung 395 symbolisiert.
Einige APIs können unter gewissen Umständen oder mit bestimmten Modifikationen zugelassen werden. In diesem Fall führt ein Thunk, wie 392 interne Operationen aus, nach denen er entweder die entsprechende API 353 aufruft oder blockiert, oder modifizierte Parameter an die API übergibt. Zum Beispiel sendet "SendMessage()" normalerweise eine Nachricht an ein Fenster. Der SendMessage-Thunk erlaubt es einer ActiveX-Control, irgendeine Nachricht an Fenster zu senden, die durch jene Steuerung erzeugt worden sind. Jedoch blockiert der Thunk alle Nachrichten, die zum Web-Browser oder einem anderen Anwendungsprogramm gehören. Dies hindert eine Steuerung daran, eine Bresche in die Sicherheit zu schlagen, indem sie eine WM_CHAR-Nachricht sendet, um einen Tastenanschlag zu simulieren, der durch ein Fenster ausgeführt werden soll, das zu einem anderen Programm gehört.
Ein anderes Beispiel beinhaltet Win 32 APIs, wie "GlobalAlloc", "HeapCreate", die normalerweise Speicher an irgendeiner Stelle zuweisen. Die Thunks für diese APIs enthalten den gesamten Code der entsprechenden APIs, der neu kompiliert ist, um insgesamt im Sandbox-Speicher zu laufen, und in der Lage ist, Speicher nur innerhalb der Grenzen der Sandbox zuzuweisen.
Obwohl es hier nicht gezeigt wird, ist es auch möglich, einen Thunk eine andere API aufrufen zu lassen, als er es normalerweise tun würde, oder um unter mehreren APIs abhängig von Parametern des Aufrufs vom Applet auszuwählen.
Schritt 422 kompiliert dann den Code des Applets in Objektcode, der durch den Emulator 39, Fig. 2 ausgeführt werden kann. Die Kompilierung kann mit einem Mal oder teilweise vonstatten gehen, wie der Code benötigt wird; der kompilierte Code wird in einen kompilierter Zwischenspeicher 357, Fig. 4 abgelegt, der außerhalb der Sandbox angeordnet ist. Eine Kompilierung auf diese Art ist gebräuchlich und ist für die Erfindung selbst nicht relevant.
Der Schritt 423 fügt einen Prüfcode in den eigenen Code des Applets ein, um die Verbote gegenüber unzulässigen Speicherverweisen zu verstärken. Dieser Prüfcode, der als "Schnüffel-Code" bezeichnet wird, überprüft alle Speicherlese- und Schreibvorgänge, die durch den Code des Applets vorgenommen werden, und erlaubt oder verbietet deren Auftreten. Indem Applets daran gehindert werden, auf Speicher außerhalb der Sandbox zuzugreifen, wird die Sicherheit des Applets erhöht. Indem der gesamte Speichers dem Applet nur aus dem vorher zugewiesenen Bereich bereitgestellt wird, wird der Schnüffel-Code-Zusatz reduziert und es führt zu einer effizienten Überprüfung des Speicherbereichs. Es werden zusätzliche Optimierungstechniken hinzugefügt, indem der Code auf einem Basisblockniveau kompiliert wird. Wenn zum Beispiel mehrere Speicherverweise durch das Applet vorgenommen werden, die dasselbe Register verwenden, könnte der Compiler vielmehr den gesamten Bereich, der durch dieses Register adressierbar ist, nur einmal überprüfen, als getrennte Aufrufe an den Schnüffel-Code für jeden Zugriff zu erzeugen. Detaillierte Beispiele werden in Verbindung mit Fig. 4 gezeigt. Im Grunde läßt es der Schnüffel-Code zu, daß das Applet nur auf RAM-Adressen innerhalb der zugewiesen Sandbox und innerhalb eines bestimmten anderen Speichers verweist, der das System nicht beschädigen kann. (Obwohl der Emulator 39 keine Speicherverweise außerhalb der Sandbox zuläßt, besitzt er die Fähigkeit, Speicherbereich zur Sandbox hinzuzufügen. Für Zwecke, wie geräteunabhängige Pixelmuster-Bilder, ist der zusätzliche Schnüffel-Codezusatz kleiner als die sonst erforderliche Anstrengung, die Bilder in den anfänglichen Sandbox-Bereich zu kopieren.)
Die Schritte 430 führen das Applet aus. Der Schritt 431 folgt der Befehlsabfolge.
Wenn der gegenwärtige Befehl ein Aufruf an eine API ist, entscheidet die durch den Schritt 421 plazierte Verknüpfung, ob der Aufruf bei Schritt 432 komplett blockiert wird, bei Schritt 433 ausgeführt wird oder bei Schritt 434 weiter verarbeitet wird, und dann entweder blockiert oder zugelassen wird.
Wenn der gegenwärtige Befehl ein Speicherverweisbefehl, wie LOAD oder STORE ist, erlaubt der Schritt 435 dem Schritt 436, den Befehl auszuführen, wenn er auf eine Adresse innerhalb seiner Sandbox verweist. Wenn nicht, stellt der Schritt 437 fest, ob der Verweis sonst erlaubt ist. Wenn dem so ist, führt der Schritt 435 ihn aus; andernfalls blockiert der Schritt 438 den Zugriff und gibt einen Fehler zurück. Der Schnüffel-Code implementiert diese Schritte. Andere X86-Befehle werden durch den Schritt 436 direkt ausgeführt. Nach jedem Befehl kehrt die Kontrolle an Schritt 431 zurück. Der Prozeß 400 geht weiter, bis die Wirtsanwendung ihn beendet.
In einigen Systemen kann die Ausführung einer API durch einen Block, wie 433 eine weitere Sicherheitspreisgabe darstellen. Wenn ein Argument einer API ein Zeiger auf Daten in der Sandbox ist, gibt es eine kurze Zeitspanne zwischen der Zeit, zu der ein Thunk die Inhalte des Speichers als gültig bestätigt, auf den gezeigt wird, und dem tatsächlichen Aufruf der API. In einem Applet mit mehreren Teilprozessen, könnte ein anderer Ausführungsteilprozeß innerhalb des Applets die Inhalte des Speichers ändern, auf den gezeigt wird, und könnte dadurch nicht als gültig bestätigte Daten an die API übertragen. Um einen solchen Angriff zu verhindern, führt der Block 433-1 eine "Detailkopie" der Argumente einer API durch, und Block 433-2 macht Detailkopien von jedem Rückgabewert von der API. Insbesondere wenn der Schritt 433 eine API ausführt, kopiert der Schritt 433-1 zuerst alle Argumente, die an die API übergeben werden, von ihrer Speicherstelle innerhalb der Sandbox zu einer anderen Speicherstelle außerhalb der Sandbox, bevor die API tatsächlich aufgerufen wird. Da das Applet selbst nicht auf diese Kopie zugreifen kann, bestätigt die API nur Daten als gültig, die schon gesichert worden sind. Der Schritt 433 lagert dann alle Rückgabewerte außerhalb der Sandbox ab; nachdem die API die Ausführung vollendet, kopiert der Schritt 433-2 den Rückgabewert innerhalb der Sandbox für die Verwendung durch das Applet. Das Detailkopieren kann selektiv verwendet werden, falls gewünscht.
Fig. 4 ist ein Speicherabbild des Systems RAM 25, das nur die Bereiche zeigt, die für die Erfindung relevant sind. Der vorher zugewiesene Bereich 251 bildet die Sandbox. Er enthält ein Anfangsspeichersegment zur Speicherung eines Applets 362, ein Laufzeitspeichersegment 252 für einen adressierbaren Arbeitsspeicher während der Ausführung des Applets und ein Segment zur Speicherung der Übersetzungscode-Thunks 391-393 (hier nur als Thunk 391 gezeigt). Der Speicher 22 außerhalb der Sandbox 251 enthält die API-DLLs, hier durch 352 dargestellt, und den Kernel32 355. Andere Arbeitsspeicherbereiche werden als 356 dargestellt. Der kompilierter Zwischenspeicher 357 liegt ebenfalls außerhalb der Sandbox 215. Die Speicherstelle von WHKRNL32 352 außerhalb der Sandbox 215 ist besonders wichtig, da es hier ist, wo das Sicherheitsverfahren tatsächlich implementiert ist; wenn er innerhalb der Sandbox liegen würde, könnte ein bösartiges Applet in der Lage sein, die Sicherheit zu beeinträchtigen, indem es ihn modifiziert.
Das folgende Beispiel stellt die Operation der Erfindung dar. Wie vorher erwähnt, nutzt diese Ausführungsform den vorher erwähnten Wx86VM-Emulator, um x86-Win32-Applets oder Steuerungen unmodifiziert auf einer x86-Plattform unter dem Windows95- oder Windows NT-Betriebssystem laufen zu lassen.
Ein Web-Browser wie der Microsoft Internet Explorer lädt eine als foo.ocx bezeichnete ActiveX-Control (Applet) aus dem Internet auf das Festplattenlaufwerk bei c:\temp\foo.ocx herunter. Die Dateikennung .ocx zeigt eine ActiveX-Control an.
Der Internet Explorer sucht dann nach dem Vorhandensein des Wx86VM im System. Wenn die Wx86VM-Komponente verfügbar ist, ruft der Internet Explorer sie auf und stellt alle sicherheitsrelvanten Informationen über die Steuerung bereit und fragt an, die Control zu laden. Wx86VM-Komponenten schauen auf die Sicherheitsinformation, mit der der Internet Explorer sie beliefert hat, und entschieden, ob sie sie in der Wx86VM starten oder sie ein Objekt-Bindeprogramm OLE32 handhabt.
Wenn die Control im Wx86VM-Emulator gestartet werden soll, dann erzeugt Wx86VM einen zugewiesenen Speicherbereich oder eine Sandbox 251 für die ActiveX-Control. Wx86VM lädt die ActiveX-Control foo.ocx, (als 362 in Fig. 4 gezeigt) in die Sandbox.
Der Wx86VM lädt API-Thunk-DLLs (sichere APIs) wie 391 in die Sandbox. Der Wx86VM ist in der Lage, die Namen der DLLs innerhalb des Laders des Betriebssystems zu modifizieren, wie vollständiger in der vorher erwähnten Anmeldung (Inhaltsvermerk 777.016US1) erläutert. Dies gestattet es dem Wx86VM Thunk-Code zwischen das x86-Bild und die Maschinen-API einzusetzen, um mit Unterschieden der Aufrufkonventionen umzugehen. Die Liste der neu abzubildenden Namen ist in einer Registerdatei gespeichert. Zum Beispiel wird kernel32 (355 in Fig. 4) auf wikrnl32 (als Thunk 391 in Fig. 4 gezeigt) neu abgebildet, und user32.dll wird als wiuser32.dll neu abgebildet. Ein API-Thunk besteht aus zwei DLLs: einen DLL mit dem Präfix "wi", die innerhalb der Wx86VM läuft und der folglich nicht vertraut wird, und einer DLL mit dem Präfix "wh", die außerhalb der Wx86VM läuft und der vertraut wird, ein Sicherheitsverfahren zu implementieren.
"Wi"-DLLs weisen dieselben Exporte, wie die Maschinen-DLL auf, für die sie eingesetzt werden. Diese Exporte sind dafür verantwortlich, aus der Sandbox auf die Wx86.dll umzuschalten, die dann den geeigneten Thunk im sicheren Modus aufruft; dies implementiert ferner das Sicherheitsverfahren für jene API. Wenn es keine Sicherheitsbedeutung für eine bestimmte API gibt, dann ruft der Thunk nur die Maschinen-API auf. Dieser Aufruf, der als "BOP" bezeichnet wird, ist typischerweise ein ungültiger x86-Operationscode, der der Wx86.dll signalisiert, daß es notwendig ist, daß eine Modusumschaltung stattfindet. Der BOP- Befehl weist die Form "BOP (DLL #, API #)" auf. Wenn der Wx86VM den BOP an die wirtsseitige Thunk-DLL absetzt, die das Präfix "wh" aufweist, (wie whkrnl32, 352 in Fig. 4), hat diese DLL Zugriff auf den Registersatz und Stapel der Sandbox, so daß die DLL Parameter vom Stapel der Sandbox auf den Maschinenstapel kopieren kann, die Argumente der API für gültig erklären, den Aufruf vornehmen und den Rückgabewert in das EAX-Register der Sandbox bewegen kann.
Wenn zum Beispiel ein x86-Applet oder -Control eine statische Verknüpfung mit kernel32!CreateFile aufweist, löst der Wx86VM die Verknüpfung zu wikrnl32!CreateFile auf. Wenn das Applet CreateFile aufruft, führt wikrnl32!CreateFile einen BOP- Befehl aus, der von der Sandbox auf maschinenspezifisch umschaltet, und Wx861DispatchBop() in Wx86VMI.dll aufruft. Wx86DispatchBop() setzt den Aufruf an whkrnl32!whCreateFile() ab. Diese Funktion ruft den maschinenspezifischen kernel32!CreateFile() auf, kopiert den Rückgabewert in das simulierte EAX-Register, und springt zurückt.
Der Wx86VM lädt auch den Code des Emulators 39, Wx86cpu.dll. Während der Ausführung eines Applets, hält der Emulation an, wenn der Prozessor einen BOP-Befehl antrifft.
Die Ausführung des Applets beginnt mit der Kompilierung des benötigten Codes und indem der Code in den kompilierter Zwischenspeicher gegeben wird. Der kompilierte Code weist Schnüffel-Prüfungen in sich auf, um zu verifizieren, daß die Speicher-Lese- oder Speicher-Schreiboperation eine sichere Operation ist. Wenn der Speicher, auf den zugegriffen wird, außerhalb des vorbestimmten Sandboxbereichs liegt, wird die Operation, die versucht, auf den Speicher zuzugreifen, fehlschlagen. Wenn zum Beispiel das Applet foo.ocx den Befehl MOV EAX,[ESI+4] enthält, dann wird der Compiler den Schnüffel-Code vor dem MOV- Befehl einfügen, um zu verifizieren, daß der Befehl sicher ist. So wird der folgende Befehl
MOV EAX, [ESI+4]
zu:
LEA ECX, [ESI+4]
CALL SNIFFREAD4.ECX
MOV EAX, [ECX]
nachdem der Schnüffel-Code eingefügt worden ist.
Da der Schnüffel-Code einen Zusatz hinzufügt, können zusätzliche Optimierungstechniken angewendet werden, wenn der Code auf einem Basisblockniveau kompiliert wird. Wenn zum Beispiel das Applet mehrere Speicherverweise macht, die dasselbe Register verwenden, kontrolliert der Compiler den gesamten Bereich nur einmal und erzeugt keine getrennten Schnüffel-Aufrufe. So wird, wenn das Applet foo.ocx die folgenden Befehle enthält:
MOV EAX, [ESI+4]
MOV EDX, [ESI+8]
der Schnüffel-Code eher eingefügt als:
LEA ECX, [ESI+4]
CALL SNIFFREAD8.ECX
MOV EAX,[ECX]
MOV EDX,[ECX+4]
als daß der Schnüffel-Code in der weniger effizienten Weise:
LEA ECX,[ESI+4]
CALL SNIFFREAD4.ECX
MOV EAX, [ECX]
LEA ECX, [ESI+4]
CALL SNIFFREAD4.ECX
MOV EDX, [ECX]
eingefügt wird.
Die obige Beschreibung ist illustrativ und nicht beschränkend. Es werden Fachleuten bei der Durchsicht der obigen Beschreibung viele andere Ausführungsformen offensichtlich werden. Der Rahmen der Erfindung sollte daher unter Bezugnahme auf die beigefügten Ansprüche zusammen mit dem vollen Rahmen der Äquivalente bestimmt werden, auf die solche Ansprüche einen Rechtsanspruch erheben.

Claims

1. Verfahren zur Ausführung eines nicht vertrauenswürdigen Programms (36), das zur direkten Ausführung auf einer Computer-Plattform (20, 35) geschrieben ist, die einen Speicher (22) und einen Satz Anwendungsprogramm-Schnittstellenmodule (352-354) aufweist, durch Steuerung der Zugriffe, die durch das nicht vertrauenswürdige Programm außerhalb eines begrenzten Speicherbereichs (412) vorgenommen werden, in den es geladen worden ist und von dem es aus ausgeführt wird, gekennzeichnet durch Modifizieren (421, 423) des Codes des nicht vertrauenswürdigen Programms (36) selbst, so daß der nicht vertrauenswürdige Programmcode selbst Zugriffe außerhalb des begrenzten Speicherbereichs während der Zeit kotrolliert, in der die Computer-Plattform den Code des nicht vertrauenswürdigen Programms ausführt.

2. Verfahren nach Anspruch 1, wobei das Modifizieren des Code des nicht vertrauenswürdigen Programms (36) das Einfügen (423) von Prüfcode (394) in den nicht vertrauenswürdigen Programmcode zur Überwachung des Speicherzugriffscode im ursprünglichen nicht vertrauenswürdigen Programm aufweist.

3. Verfahren nach Anspruch 2, wobei der Prüfcode in den nicht vertrauenswürdigen Programmcode nach dem Kompilieren (422) des nicht vertrauenswürdigen Programms (36) eingefügt wird.

4. Verfahren nach Anspruch, 2, wobei der Prüfcode an Speicherblöcken arbeitet, die größer als einzelne Speicheradressen sind.

5. Verfahren nach Anspruch 2, wobei der in den nicht vertrauenswürdigen Programmcode eingefügte Prüfcode (435, 437, 438) mindestens einige Speicherverweise außerhalb des begrenzten Speicherbereichs verbietet.

6. Verfahren nach Anspruch 5, wobei der in den nicht vertrauenswürdigen Programmcode eingefügte Prüfcode (437) bestimmte Speicherverweise außerhalb des begrenzten Speicherbereichs erlaubt.

7. Verfahren nach Anspruch 1, wobei das Modifizieren des Codes des nicht vertrauenswürdigen Programms (36) das Ersetzen (421) von Code im ursprünglichen Programm zum Aufrufen der Anwendungsprogramm-Schnittstellen durch Code aufweist, der stattdessen Übersetzungsmodule aufruft.

8. Verfahren nach Anspruch 7, wobei der Ersetzungsschritt das Ersetzen von statischen Steuerungsverknüpfungen im nicht vertrauenswürdigen Programmcode durch einen Thunk (391-393) aufweist.

9. Verfahren nach Anspruch 7, wobei unterschiedliche Anwendungsprogramm-Schnittstellen mit unterschiedlichen Übersetzungsmodule verbunden sind.

10. Verfahren nach Anspruch 9, wobei einige der Übersetzungsmodule die Ausführung ihrer zugehörigen Anwendungsprogramm-Schnittstellen unbedingt verbieten (432).

11. Verfahren nach Anspruch 9, wobei einige der Übersetzungsmodule die Ausführung ihrer zugehörigen Anwendungsprogramm-Schnittstellen unbedingt erlauben (433).

12. Verfahren nach Anspruch 9, wobei einige der Übersetzungsmodule ferner eine Anfrage nach einer Anwendungsprogramm- Schnittstelle verarbeiten (434) und dann entweder seine Ausführung erlauben oder verbieten.

13. Verfahren nach Anspruch 1, wobei das Modifizieren des Codes des nicht vertrauenswürdigen Programms (36) sowohl aufweist:

Einfügen (423) von Prüfcode in den nicht vertrauenswürdigen Programmcode zur Überwachung des Speicherzugriffscodes im ursprünglichen nicht vertrauenswürdigen Programm; als auch Ersetzen (421) von Code im ursprünglichen Programm zum Aufrufen der Anwendungsprogramm-Schnittstellen durch Code, der stattdessen Übersetzungsmodule aufruft.

14. Verfahren nach Anspruch 13, ferner gekennzeichnet durch Laden mehrerer zusätzlicher Codemodule in den begrenzten Speicherbereich, wobei das nicht vertrauenswürdige Programm auf die zusätzlichen Codemodule (391) zugreifen kann

15. Verfahren nach Anspruch 14, wobei die zusätzlichen Module Übersetzungsmodule aufweisen.

16. Medium, das Darstellungen von Computerbefehlen und Daten zur Ausführung des Verfahrens nach Anspruch 1 aufweist.

17. Emulator zum Ausführen eines in Maschinencode geschriebenen nicht vertrauenswürdigen Programms (36), das direkt durch einen maschinenspezifischen Prozessor (21) ausführbar ist und Anwendungsprogramm-Schnittstellen (352-354) und einen begrenzten Speicherbereich (215) zum Halten des nicht vertrauenswürdigen Programms einsetzt, dadurch gekennzeichnet, daß der Emulator betriebsfähig ist, den Code eines nicht vertrauenswürdigen Programms (36) so zu modifizieren (421, 423), daß wenn das nicht vertrauenswürdige Programm (36) ausgeführt wird, der nicht vertrauenswürdige Programmcode dafür sorgt, Zugriffe außerhalb des begrenzten Speicherbereichs zu kontrollieren.

18. Emulator nach Anspruch 17, wobei der Emulator betriebsfähig ist, den Code des nicht vertrauenswürdigen Programms (36) durch Einfügen (423) von Prüfcode (394) in den nicht vertrauenswürdigen Programmcode zur Überwachung von Speicherzugriffscode im ursprünglichen nicht vertrauenswürdigen Programm zu modifizieren.

19. Emulator nach Anspruch 18, wobei der in den nicht vertrauenswürdigen Programmcode eingefügte Prüfcode mindestens einige Speicherverweise außerhalb des begrenzten Speicherbereichs verbietet (435, 437, 438).

20. Emulator nach Anspruch 17, wobei der Emulator betriebsfähig ist, den Code des nicht vertrauenswürdigen Programms (36) durch Ersetzen (421) von Code im ursprünglichen Programm zum Aufrufen von Anwendungsprogramm-Schnittstellen durch Code, der stattdessen Übersetzungsmodule aufruft, zu modifizieren.

21. Emulator nach Anspruch 20, wobei die Übersetzungsmodule Thunks (391-393) sind.

22. Emulator nach Anspruch 20, wobei unterschiedliche Übersetzungsmodule betriebsfähig sind, selektiv die Ausführung der Anwendungsprogramm-Schnittstellen erlauben und verbieten, die mit den unterschiedlichen Übersetzungsmodulen verbunden sind.

23. Aufzeichnungsmedium, das Daten speichert, die für computerimplementierbare Prozessorschritte kennzeichnend sind, die zur Erzeugung eines Emulators nach einem der Ansprüche 17-22 innerhalb eines programmierbaren Computers angepaßt sind.

24. Aufzeichnungsmedium, das Daten speichert, die für computerimplementierbare Prozessorschritte kennzeichnend sind, die angepaßt sind, einen programmierbaren Computer dazu veranlassen, ein Verfahren nach einem der Ansprüche 1-16 auszuführen.

25. Aufzeichnungsmedium nach einem der Ansprüche 23 oder 24, das eine Computerplatte aufweist.

26. Computerplatte nach Anspruch 25, die eine magnetische, magnetooptische oder optische Platte aufweist.

27. Aufzeichnungsmedium nach Anspruch 23 oder 24, das ein elektrisches Signal aufweist, das über ein Kommunikationsnetz übertragen wird.