Adobe Reader: Mit der Sandbox in den Protected Mode

Transkript

1 Adobe Reader: Mit der Sandbox in den Protected Mode Suchit S. Mishra 1 Kurzfassung: Sandboxing wird heute nur von relativ wenigen Anbietern genutzt. Sicherheitsexperten sehen aber im Sandboxing eine gute Möglichkeit, die Auswirkungen von Sicherheitslücken und Exploits zu reduzieren. In den vergangenen zwei Jahren haben Entwickler gängiger Web-Browser und Produktivitäts-Tools Sandbox-Funktionen in ihre Produkte integriert, um auf die zunehmenden Sicherheitsbedrohungen zu reagieren. Zudem wurden Best Practices für die Entwicklung einer sicheren Sandbox mit eingeschränkten Funktionen für Windows definiert. Dieser Beitrag erläutert die technischen Details und das Design der Sandbox in Adobe Reader X Protected Mode sowie die Schutzfunktionen und Zukunftsperspektiven dieses Konzepts. Stichworte: Sandbox, Protected Mode, PDF, Adobe Reader 1. Design der Adobe Reader Sandbox 1.1 Was ist eine Sandbox? Eine Sandbox ist ein Sicherheitsmechanismus, der es ermöglicht, eine Anwendung in einer isolierten Laufzeitumgebung einzusetzen, in der bestimmte Funktionen (wie das Installieren oder Löschen von Dateien oder die Modifikation von Systeminformationen) deaktiviert sind. Adobe Reader erhält durch Sandboxing (auch Protected Mode) eine zusätzliche Sicherheitsebene. Dadurch bleibt bösartiger Code in PDF-Dateien innerhalb der Adobe Reader Sandbox und kann keine anderen Funktionen im System des Anwenders ausführen. Die Adobe Reader Sandbox nutzt die Sicherheitsfunktionen des Betriebssystems, um die Ausführung von Prozessen nach dem Prinzip der geringstmöglichen Berechtigung (Principle of Least Privilege) zu verhindern. So laufen Prozesse, die Ziel eines Angreifers sein könnten, mit eingeschränkten Rechten und müssen daher Aktionen wie den Dateizugriff über einen separaten, sicheren Prozess durchführen. Dieses Design hat drei grundlegende Effekte: - Die gesamte Verarbeitung von PDFs, also Analyse (Parsing) von PDFs und Bildern, Ausführung von JavaScript, Rendern von Fonts und 3D-Rendering läuft in der Sandbox ab. - Prozesse, die Aktionen außerhalb der Sandbox starten müssen, können dies nur über einen Trusted Proxy, einen so genannten Broker Process. - Die Sandbox unterscheidet zwei Sicherheitsprinzipale (Security Principals): den Benutzerprinzipal (User Principal) im Zusammenhang mit der Sitzung des angemeldeten Benutzers und den PDF-Prinzipal für den isolierten Prozess, der Parsing und Rendern des PDF übernimmt. Diese Unterscheidung wird mit Hilfe!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 1 Adobe Systems Inc., San Jose, California, USA!

2 einer Trust Boundary auf der Prozessebene zwischen dem Sandbox-Prozess und der restlichen Sitzung des angemeldeten Benutzers im Betriebssystem etabliert. Ziel dieses Konzepts ist es, sämtliche potenziell bösartigen Daten mit den eingeschränkten Rechten des PDF-Prinzipals und nicht mit den vollen Rechten des Benutzerprinzipals zu verarbeiten. Die nachfolgende Grafik verdeutlicht die Interprozesskommunikation (Inter-Process Communication - IPC) für einen Fall, in dem die Sandbox Aktionen anfordert, die über den Broker als Benutzerprinzipal (User Principal) statt über den PDF-Prinzipal laufen müssen, z. B. der Aufruf eines Betriebssystem-API oder der Schreibzugriff auf eine Datei. Abb. 1 - High Level Design der Adobe Reader Sandbox Für die meisten Unternehmensanwendungen ist Sandboxing ein relativ neues Konzept, weil die nachträgliche Implementierung bei einer ausgereiften Software (mit mehreren Millionen Code-Zeilen), die bereits in zahlreichen Umgebungen installiert wurde, sehr aufwendig ist. Zu den wenigen kürzlich ausgelieferten Produkten, die das Sandbox- Konzept umsetzen, gehören Microsoft Office 2007 MOICE, Google Chrome und Office 2010 Protected View. Dabei besteht die Herausforderung darin, das Sandboxing zu implementieren, ohne den Workflow der Benutzer durch Deaktivieren wichtiger Funktionen einzuschränken. Das Ziel ist letztlich, ein hohes Sicherheitsniveau zu erreichen, um das Auffinden und Fixen von Bugs zu ergänzen. 1.2 Design-Prinzipien Die Sandbox wurde auf Basis verschiedener Best Practices für die Sicherheit konzipiert:

3 - Nutzung der vorhandenen Sicherheitsarchitektur des Betriebssystems: Die Adobe Reader Sandbox nutzt Sicherheitsfunktionen des Windows- Betriebssystems wie Restricted Tokens (eingeschränkte Token), Job Objects (Auftragsobjekte) und Low Integrity Levels (niedrige Integritätsebenen). - Nutzung vorhandener Implementierungen: Die Adobe Reader Sandbox baut auf der Google Chrome Sandbox auf und berücksichtigt zudem den Microsoft Office 2010 Protected Mode. - Least-Privilege-Prinzip (Principle of Least Privilege): Jeder Prozess (ausführbarer Code) kann nur auf die Ressourcen zugreifen, die zur Ausführung von Aktionen zum legitimen Zweck erforderlich sind. - Annahme, dass alle Sandbox-Daten nicht vertrauenswürdig (untrusted) sind: Es wird davon ausgegangen, dass alle Daten, die aus der Sandbox kommen, potenziell schädlich sind, bis sie geprüft wurden. 1.3 Sicherheitsfunktionen der Adobe Reader Sandbox Gehen wir einmal davon aus, dass ein Angreifer einen beliebigen Code ausführen kann, weil er eine bisher ungepatchte Sicherheitslücke im Adobe Reader Renderer entdeckt hat und den Benutzer dazu bringen kann, eine entsprechend präparierte PDF- Datei anzuklicken, die als -Anhang eingegangen ist. Ebenso könnte der Benutzer auch auf einer Website auf einen Link zu einer präparierten PDF-Datei klicken. Früher konnte ein Doppelklick und das nachfolgende Rendern dieser PDF- Datei dazu führen, dass der Rechner des Benutzers vollständig lahmgelegt wird. Wenn beispielsweise der Angreifer eine Sicherheitslücke entdeckt hatte, die einen Pufferüberlauf in den Adobe Reader JavaScript APIs oder einen Ganzzahlüberlauf (Integer Overflow) in den Fonts-Komponenten verursacht. Dann musste der Angreifer seine potenziellen Opfer nur noch dazu bringen, die präparierte PDF-Datei zu öffnen, indem er sie mit einer Spam-Mail verschickte oder einen entsprechenden Link auf einer beliebten Website bereitstellte. Vorrangige Ziele: Die Sandboxing-Architektur des Adobe Reader soll im Wesentlichen verhindern, dass der Angreifer: 1. Malware auf dem Computer des Benutzers installiert 2. die Tastatureingaben des Benutzers überwacht, wenn dieser ein Programm bedient Schafft es der Angreifer, eine der genannten Aktionen durchzuführen, kann er einen beträchtlichen Schaden anrichten. Ist erst einmal Malware auf dem Computer des Benutzers installiert, kann der Angreifer Zugriffsrechte für Aktionen wie Schreiben, Aktualisieren, Löschen von Daten im Dateisystem und in der Registry erlangen und einen Botnet-Client installieren, der Befehle über das Netzwerk entgegen nimmt und den Computer für koordinierte Attacken über das Internet einsetzt. Im zweiten Fall könnte der Angreifer durch die Aufzeichnung von Tastatureingaben versuchen, vertrauliche und sensible Informationen wie Passwörter und Kreditkartendaten zu stehlen.

4 Vereinfacht gesagt, verhindert die Adobe Reader Sandbox ähnlich wie die Google Chrome Sandbox, dass der Angreifer Malware installiert oder das Dateisystem manipuliert und somit die Kontrolle über den Computer des Benutzers erhält. Dies führt uns wieder zurück zum Least-Privilege-Prinzip: Ein Exploit könnte so innerhalb einer Anwendung ausgeführt werden, aber keinen Schaden anrichten, da er durch die extrem restriktive Sandbox-Umgebung blockiert wird. Dadurch wird letztlich die Verwundbarkeit des Adobe Reader stark reduziert. 2. Der Sandbox-Prozess im Detail Werfen wir nun einen Blick auf die Komponenten, die vom Windows-Betriebssystem für den Sandbox-Prozess und die Zugriffsbeschränkung bereitgestellt werden. Abb. 2 - Der Adobe Reader Sandbox-Prozess 2.1 Granularität der Prozessebenen Bei Prozessen, die in der Sandbox ablaufen, bedeutet die Einhaltung des Least- Privilege-Prinzips, dass die Aktivität des Prozesses in vielen Fällen auf die Kommunikation mit dem Broker-Prozess beschränkt ist. Unter Windows kann der Code also keine Eingabe-Ausgabe-Operationen mit der Festplatte, der Tastatur oder dem Display durchführen, ohne dafür einen Systemaufruf zu starten. Und die meisten Systemaufrufe veranlassen Windows zur Durchführung einer Sicherheitsprüfung. Der Adobe Reader Sandbox-Prozess läuft aber in einer Umgebung, in der diese Sicherheitsprüfung für die eingeschränkten Aktionen nicht funktioniert. Die fehlgeschlagene Sicherheitsprüfung führt dann dazu, dass der Code in der Sandbox isoliert wird. Der Adobe Reader kann also die Code-Funktionalität

5 einschränken, indem er exakt definierte Beschränkungen des Windows- Sicherheitsmodells anwendet. Dazu gehören: - Einschränkung des Token für den Sandbox-Prozess: o Ablehnung oder Einschränkung von Sicherheitskennungen (Security Identifiers - SIDs) o Entfernung von Berechtigungen - Zuordnung einer Sandbox zu einem Auftragsobjekt (Job Object) mit Einschränkungen - Durchführung des Sandbox-Prozesses mit niedriger Integrität unter Windows Vista, Windows 7 und Windows Server 2008 Das Adobe Reader Team nutzt diese Merkmale des Windows-Betriebssystems, um bestimmte Kategorien von Attacken zu entschärfen und Angriffe abzuwehren, bei denen eine präparierte PDF-Datei versucht, eine Sicherheitslücke im Adobe Reader auszunutzen. 2.2 Einschränkung von Sicherheitskennungen (SIDs) und Berechtigungen Eine Sicherheitsebene entsteht durch die Beschränkung der Rechte für Lesen und Schreiben sowie das Ausführen von Programmcode usw. in Abhängigkeit von der Vertrauenswürdigkeit des Prozessbesitzers. Die Identifikation der rollenspezifischen Rechte und Berechtigungen des Besitzers wird mit Hilfe eines Token für den sicheren Zugriff (Security Access Token) realisiert, wenn sich der Benutzer anmeldet. Nach der Windows-Sicherheitsterminologie ist der Benutzer des Readers ein Vertrauensnehmer ( Trustee ). Jeder Prozess, den der Vertrauensnehmer aufruft, wird in einem Sicherheitskontext ausgeführt, der zum Teil durch den Zugriffstoken definiert ist. Die Zugriffstoken setzen sich aus zwei Hauptkomponenten zusammen: Sicherheitskennungen (SIDs) und Berechtigungen (Privileges). Windows beschreibt den Sicherheitskontext jedes Prozesses, der auf Anforderung des Vertrauensnehmers ausgeführt wird, durch das Setzen dieser beiden Komponenten. Der Reader modifiziert diesen Kontext für Prozesse in der Sandbox wie folgt: - Ablehnen oder Einschränken von SIDs. SIDs von Zielprozessen werden modifiziert durch: o Kennzeichnung aller SIDs als DENY_ONLY, außer für BUILTIN\Users, Everyone, User s Logon SID, NTAUTHORITY\INTERACTIVE. o Hinzufügen der folgenden SIDs zur Liste mit eingeschränkten SIDs: BUILTIN\Users, Everyone, User s Logon SID, NTAUTHORITY\RESTRICTED. - Hinzufügen einer SID mit niedriger Integritätsebene (nur für Vista, Windows 7 und Windows Server 2008). - Entfernen von Berechtigungen. Alle Berechtigungen außer dem SetChangeNotifyPrivilege werden von den Zugriffstoken des Zielprozesses entfernt.

6 Durch diese Maßnahme beschränkt Adobe Reader die Zugriffstoken zusätzlich, um den Zugriff auf sicherungsfähige Objekte (Securable Objects) oder privilegierte Vorgänge einzuschränken. Abb. 3 Abgelehnte SIDs, eingeschränkte SIDs und Berechtigungen für den Adobe Reader Sandbox-Prozess 2.3 Auftragsobjekte (Job Objects) Für bestimmte Aufgaben lassen sich Gruppen von Zielprozessen als eine Einheit in einem Auftragsobjekt zusammenfassen. Windows-Auftragsobjekte sind sicherungsfähige Objekte, die ihre Prozessattribute steuern. Deshalb kann ein Auftragsobjekt zusätzliche globale Restriktionen für alle Prozesse erzwingen, mit denen es verbunden ist. Wie bei anderen sicherungsfähigen Objekten wird auch der Zugriff auf Auftragsobjekte mit einer Sicherheitsbeschreibung (Security Descriptor) gesteuert. Die Sandbox-Prozesse von Adobe Reader werden in einem Auftrag mit den folgenden Einschränkungen zusammengeführt: - ActiveProcess ActiveProcess-Limit = 1 - Desktop Limited Umschalten zu / Erstellen von Desktops nicht möglich - Display Settings Aufruf von ChangeDisplaySettings nicht möglich - Exit Windows Verlassen von Windows via ExitWindows(Ex) nicht möglich - USER Handles Verwendung von USER Handles, die Prozessen außerhalb des gleichen Auftrags zugeordnet sind, nicht möglich - System Parameters Veränderung von Systemparametern über die Funktion SystemParametersInfo nicht möglich - Administrator Access verhindert, dass Prozesse in dem Auftrag einen Token verwenden, der die lokale Administratorengruppe spezifiziert Diese Einschränkungen verhindern, dass bösartiger Programmcode in der Sandbox in Teile des Betriebssystems eindringt.

7 Abb. 4 Einschränkungen für Auftragsobjekte (Job Objects) 2.4 Niedrige Integrität Der Windows Integrity Mechanism ist eine Komponente der Windows-Architektur, die die Zugriffsberechtigungen von Anwendungen einschränkt, indem sie Integritätsebenen (Kennzeichnung der Vertrauenswürdigkeit) für alle Prozesse und sicherungsfähigen Objekte anwendet. Der Integritätsmechanismus allein ist keine Wunderwaffe, erleichtert jedoch seit seiner Einführung mit Windows Vista erheblich die Implementierung des Sandbox-Konzepts, weil damit Zugriffsbeschränkungen für viele Teile des Betriebssystems durchgesetzt werden. Teile der Ressourcenverwaltung wie das Dateisystem verhindern somit, dass weniger vertrauenswürdige Prozesse Objekte auf höheren Integritätsebenen modifizieren können. Für den Adobe Reader laufen Zielprozesse als Prozesse mit niedriger Integrität, wodurch verhindert wird, dass diese mit Prozessen höherer Integrität kommunizieren. Dieser Mechanismus stellt die notwendige Zugriffskontrolle auf Prozessebene bereit. Da der Integritätsmechanismus für Windows-Systeme ab Vista verfügbar ist, bietet das Sandbox-Konzept für diese und die nachfolgenden Plattformen einen besseren Schutz als für Windows XP. Process Explorer Die Screenshots in den Abbildungen 3 und 4 wurden mit dem Tool Process Explorer erstellt. Dieses Tool eignet sich sehr gut, um den Sandbox-Prozess und die Schutzfunktionen für das Betriebssystem unter Windows zu bewerten. So können Sie beispielsweise einmal im Process Explorer die Tabs Security und Job von verschiedenen Anwendungen vergleichen, die angeblich über eine Sandbox oder einen Protected Mode verfügen. 2.5 Kein separates Desktop für Adobe Reader Protected Mode Im dritten Teil seines Artikels Practical Windows Sandboxing empfiehlt David LeBlanc, den Sandbox-Prozess in einem separaten Desktop laufen zu lassen, weil es

8 innerhalb eines Windows-Desktops nur geringe Sicherheitsfunktionen gibt. Das Adobe Reader Engineering Team hat diese Möglichkeit getestet und Adobe Reader in einem separaten Desktop laufen lassen. Das Team kam zu dem Schluss, dass dieses Vorgehen beträchtliche Änderungen der Architektur erfordern und dadurch die Bereitstellung einer Adobe Reader Sandbox bis weit in das Jahr 2011 verzögern würde. (Die Integration einer Sandbox in eine komplexe Anwendung wie Adobe Reader wurde verglichen mit dem nachträglichen Einbau eines zusätzlichen Erdgeschosses in ein 20-stöckiges Hochhaus.) Es stellte sich also die Frage, ob wir nahezu alle Sicherheitsmerkmale, die ein separates Desktop bietet, auch mit anderen Verfahren realisieren können. Die Antwort lautet: Yes, we can! Dieser Abschnitt beschreibt detailliert, wie wir dies erreicht haben und welche Grenzen es dabei gab. (An dieser Stelle möchten wir David LeBlanc vom Microsoft Office Team und Nicolas Sylvain vom Google Chrome Team für Ihre Unterstützung bei der Suche nach Alternativen einen besonderen Dank aussprechen.) Shatter Attack Ein Angriffsszenario, das ein separates Desktop verhindern könnte, ist eine so genannte Shatter Attack. Um Shatter-Attacken zu vermeiden, müssen wir sicherstellen, dass der Sandbox-Prozess ohne explizit gewährte Erlaubnis keine Windows-Meldungen an Fenster senden kann, die zu anderen Prozessen gehören. Wir konnten diese Art von Attacken im Adobe Reader Protected Mode unter Windows XP SP3 und höher entschärfen, indem wir zwei Verfahren angewendet haben: Unser Auftragsobjekt (Job Object) setzt die Einschränkung UILIMIT_HANDLES und verhindert so, dass der Sandbox-Prozess auf User Handles zugreifen kann, die von Prozessen erzeugt wurden, welche nicht im Zusammenhang mit unserem Job stehen. Ab Windows Vista lassen wir den Sandbox-Prozess zudem mit niedriger Integrität laufen. Mit User Interface Privilege Isolation (UIPI) wird dadurch verhindert, dass Prozesse Meldungen an Fenster senden, die zu anderen Prozessen mit höherer Integritätsebene gehören Missbrauch von SetWindowsHookEx SetWindowsHookEx ist ein leistungsfähiges Windows API, über das Malware in jeden Prozess eindringen kann, der im gleichen Desktop läuft. Wird der Sandbox-Prozess in einem separaten Desktop ausgeführt, kann dies verhindert werden. Auch ohne ein separates Desktop konnten wir diese Attacken mit dem Adobe Reader Protected Mode entschärfen, indem wir die folgenden Techniken eingesetzt haben: - Unser Auftragsobjekt setzt die Einschränkung UILIMIT_HANDLES. Dadurch kann der Sandbox-Prozess keine Hooks in Prozessen setzen, die nicht zu unserem Job gehören. - Die Adobe Reader Sandbox läuft mit einem eingeschränkten Token. Dadurch ist unser Prozess für Windows nicht vertrauenswürdig und in der Lage, einen Hook zu setzen.

9 - Ab Windows Vista läuft der Prozess mit niedriger Integrität. Durch die User Interface Privilege Isolation (UIPI) wird verhindert, dass Hooks in Prozessen mit höherer Integrität gesetzt und DLLs mit SetWindowsHookEx integriert werden können Transiente Keylogger Mit Keylogging-Malware versuchen Angreifer, wertvolle Informationen durch Erfassen der Tastatureingaben in anderen Prozessen zu stehlen. Im Idealfall verhindert die Verwendung eines separaten Desktops für den Sandbox-Prozess diese Art von Attacken. Auch ohne Verwendung eines separaten Desktops konnten wir diese Attacken mit dem Adobe Reader Protected Mode entschärfen, allerdings nur unter Windows Vista, Windows Server 2008 und Windows 7: - Unter Windows Vista und späteren Versionen läuft der Sandbox-Prozess auch mit niedriger Integrität. Durch die User Interface Privilege Isolation (UIPI) wird verhindert, dass Tastatureingaben von Prozessen mit höherer Integrität erfasst werden können Screen Scraping-Attacken Durch Ausführen des Sandbox-Prozesses in einem separaten Desktop kann Malware entschärft werden, die versucht, Informationen durch Auslesen von Bildschirminhalten (Screen Scraping) zu stehlen. Mit der Kombination aus UIPI, eingeschränktem Token und Handles-Restriktionen unserer Sandbox können wir Screen Scraping-Attacken entschärfen, ohne den Prozess in einem separaten Desktop auszuführen. Leider können wir diese zurzeit noch nicht implementieren, da ein Großteil unseres Codes in Adobe Reader explizit den Zugriff auf das Desktop Window Handle erfordert. Wir planen, dieses Problem in einem späteren Dot-Release zu lösen. Damit beenden wir den Abschnitt mit Details zum Adobe Reader Sandbox-Prozess und der Nutzung des Windows-Sicherheitsmodells für die Abwehr von Attacken durch Malware und transiente Keylogger.

10 3. Broker-Prozess und Interprozesskommunikation Sehen wir uns nun die die Broker Policies (Broker-Richtlinien) und die Interprozesskommunikation (IPC) an, die der Sandbox-Prozess für den Austausch mit dem Broker-Prozess verwendet. Der Broker-Prozess läuft mit regulären Benutzerrechten und verwendet Richtlinien (Policies), um dem Sandbox-Prozess einen indirekten und sicheren Zugriff auf Objekte zu ermöglichen. Als privilegierter Controller ermöglicht der Broker-Prozess so die Ausführung des Sandbox-Prozesses. Einige Aktionen sind als eine Art Whitelist Bestandteil der Broker-Policies und können daher von der Sandbox indirekt über den Broker ausgeführt werden. Zu den Whitelist-Aktionen gehören: - Schreiben in den TEMP-Ordner des Benutzers - Schreiben (Speichern) von Adobe Reader-spezifischen, vom Benutzer modifizierten Einstellungen in die Registry - Starten einer Tracker-Funktion für die gemeinsame Überarbeitung von Dokumenten - Starten eines.docx-anhangs in Microsoft Word 3.1 Interprozesskommunikation (IPC) Die Interprozesskommunikation des Broker-Prozesses ist das Gateway der Sandbox zum restlichen Betriebssystem. Die vom Broker offengelegte IPC ist auch eine Angriffsfläche für den Protected Mode. Bösartiger Code, der innerhalb des Sandbox- Prozesses läuft, könnte die Funktionalität des Broker-Prozesses oder eine Sicherheitslücke im Broker selbst nutzen. Abb. 5 IPC von Sandbox und Broker-Prozess Die Multiprozess-Architektur des Adobe Reader Sandbox Broker erfordert die sichere Kommunikation zwischen Prozessen. Die Adobe Reader IPC verwendet die Standard- Mechanismen von Windows für gemeinsamen Speicher und Ereignisse. Abbildung 5 zeigt ein Beispiel mit einem Sandbox-Prozess, der versucht, eine Datei auf die Festplatte zu schreiben. Da Sandboxing ( Protected Mode ) aktiviert ist, wird die Erstellung der Datei wie folgt über den Broker-Prozess umgeleitet:

11 1. Die Sandbox versucht, eine Datei zu erstellen. 2. Der Vorgang schlägt fehl. 3. Der Sandbox-Prozess sendet eine Anfrage an den Broker, damit dieser die Erstellung der Datei übernimmt. 4. Der Broker bewertet die Sandbox-Anfrage mit Hilfe von Policies, um zu entscheiden, ob die Anfrage angenommen oder abgelehnt wird. Wird die Anfrage abgelehnt, sendet der Broker eine Fehlermeldung zurück. 5. Der Broker startet den CreateFile-Aufruf. 6. Das Betriebssystem übergibt den Dateihandle an den Broker. 7. Der Broker dupliziert den Dateihandle in den Sandbox-Prozess. 8. Der Sandbox-Prozess schreibt die Datei auf die Festplatte. Bei so vielen Schritten für die Durchführung einer Aktion ist zu vermuten, dass die Performance beeinträchtigt wird. In Tests haben wir jedoch festgestellt, dass der Reader X mit aktiviertem Protected Mode im Vergleich zum Reader 9 tatsächlich ebenso gut oder besser abschneidet. 3.2 Policies Die Einschränkungen, denen ein Sandbox-Prozess unterliegt, werden mit Hilfe einer Policy (Richtlinie) konfiguriert. Die Policy ist eine Schnittstelle, über die die Broker Application Programming Interfaces (APIs) Einschränkungen und Freigaben definieren können. Die Sandbox-Einschränkungen sind so grob konzipiert, dass sie alle sicherungsfähigen Ressourcen betreffen, auf die die Sandbox zugreifen kann. Doch in einigen Fällen sind feinere Definitionen erforderlich. Über die Policy kann der Broker so genannte Whitelist-Regeln festlegen. Diese ermöglichen es dem Broker, der Sandbox den Zugriff auf bestimmte Operationen (z. B. CreateFile) oder bestimmte benannte Objekte (z. B. den TEMP-Ordner des Benutzers) zu ermöglichen, die sonst durch die Einschränkungen des Sandbox-Prozesses verhindert würden. Die Form der Regeln für jedes Subsystem ist unterschiedlich, doch im Allgemeinen werden sie auf Basis eines Zeichenfolgemusters (String Pattern) ausgelöst. So kann beispielsweise eine Datei-Regel wie folgt aussehen: AddRule(SUBSYS_FILES, FILES_ALLOW_READONLY, L c:\\temp\\app_log\\*.log ) Diese Regel besagt, dass der Zugriff gewährt wird, wenn eine Sandbox eine Datei im schreibgeschützten Modus öffnet, sofern die Datei dem angegebenen Muster entspricht. In diesem Fall wären die Bedingungen von der Datei c:\temp\app_log\myapp.log erfüllt. Die meisten Broker-Aktionen werden über Policies gesteuert. Eine typische Policy könnte festlegen: Erlaube alle Schreiboperationen im TEMP-Ordner des Benutzers oder Erlaube alle Schreiboperationen in der Registry unter HKCU\Software\Adobe\Acrobat Reader\10.0. So agiert der Broker zum Teil als eine Art Policy Manager und setzt die festgelegten Richtlinien durch, während die Sandbox-Prozesse einfach nur Ressourcen anfordern.

12 Stellt der Broker fest, dass die Policy den jeweiligen Zugriff erlaubt, wird die Anfrage weitergeleitet, andernfalls wird der Zugriff abgelehnt. Die Policies sind so engmaschig, dass sie nur die erwünschten Operationen erlauben, aber großzügig genug, um der Anwendung die Standardaktionen zu ermöglichen, ohne dass Schadprogramme Erfolg haben. Außer für die oben beschriebenen Aktionen wird der Broker auch für privilegierte Vorgänge wie die Aufgaben des Adobe Reader Updater und die Erstellung spezieller Objekte des Component Object Model (COM) genutzt. Es gibt drei Policy-Arten, die auf unterschiedliche Weise erstellt werden: - Hard-Coded Policies: Bestimmte grundlegende Aktionen für die Anwendung sind in Hard-Coded Policies gekapselt. Dazu gehört beispielsweise das Schreiben in HKCU\Software\Adobe\Acrobat Reader\10.0\* oder %APPDATA%\Adobe\Acrobat\10.0\*. - Dynamische Policies: Diese Policies regeln Operationen, die aus der Interaktion von Benutzern mit einer PDF-Datei resultieren. Sie werden dynamisch on the-fly erstellt und von einem Bestätigungsdialog begleitet. Wenn beispielsweise ein Benutzer versucht, eine PDF-Datei zu speichern, zeigt der Broker das Dialogfeld Speichern unter an und der vom Benutzer angegebene Dateiname wird in die Liste der Dateien aufgenommen, für die Schreibzugriff gewährt wird. - Admin-Configurable Policies: Ein Administrator kann über eine Konfigurationsdatei Whitelist-Regeln festlegen, um einige der Sandbox- Einschränkungen für spezielle Workflows oder Plugins zu umgehen. So könnte beispielsweise der Schreibzugriff für plugin-spezifische Application Data- oder Registry-Bereiche erlaubt werden. Policies werden immer dann genutzt, wenn eine Zugriffsanforderung zum Öffnen der folgenden Kernel-Objekte erfolgt: File, Registry, Named Pipe, Section, Mutant und Event. Sie werden auch für den Start externer Hilfsprozesse (z. B. Adobe Reader Updater oder Comments Synchronizer) angewendet. 3.3 Broker API als Trust Boundary In den vorausgehenden Abschnitten haben wir sämtliche Einschränkungen beschrieben, denen der Sandbox-Prozess unterliegt. Dadurch entsteht ein zusätzlicher Schutzwall gegen unbefugte Zugriffe, weil bösartiger Code in PDF-Dateien in der Adobe Reader Sandbox isoliert wird und somit keine regulären privilegierten Vorgänge auf dem System des Benutzers ausführen kann. Bösartiger Code, der im Sandbox-Prozess ausgeführt wird, müsste also eine weitere Sicherheitslücke im Broker-Code nutzen, um höhere Berechtigungen zu erhalten. Die Implementierung einer Sandbox stellt eine effektive zusätzliche Sicherheitsmaßnahme dar, weil sie Angriffe abwehren kann. Allerdings ist das Sandbox-Konzept keine Wunderwaffe, insbesondere da Exploit-Kits, die zwei oder mehr Sicherheitslücken und Angriffsmethoden nutzen, immer intelligenter vorgehen.

13 Bei der Adobe Reader Sandbox gibt es zwei logische Angriffspunkte, die für eine Attacke genutzt werden könnten: 1. Lokale Kernel-Sicherheitslücken 2. Sicherheitslücken im Broker-Prozess des Adobe Reader Die Diskussion lokaler Kernel-Sicherheitslücken würde den Rahmen dieses Dokuments sprengen. Daher werden wir in diesem Abschnitt den Broker-Prozess des Adobe Reader als potenzielle Angriffsfläche betrachten und erläutern, welche Gegenmaßnahmen wir ergriffen haben. Es gibt eine Vielzahl von APIs im Broker des Adobe Reader Protected Mode, die die zahlreichen Funktionen des Adobe Reader unterstützen. Die große Mehrheit der APIs wird für Intercepted Win32 APIs (z. B. APIs für Drucken) oder für den Zugriff auf sicherungsfähige Kernel-Objekte (wie Sections, Events und Mutants) verwendet. Die restlichen APIs lassen sich in zwei Kategorien einteilen: 1. APIs, die Dienste für den Adobe Reader bereitstellen. Ein Beispiel wäre das Starten einer ausführbaren Datei aus einer Whitelist mit Anwendungen. 2. APIs, die Bestätigungsdialoge aus dem Broker-Prozess starten, bevor potenziell gefährliche Vorgänge ausgeführt werden. Ein Beispiel ist der folgende Dialog, in dem der Benutzer die Deaktivierung des Protected Mode bestätigen muss: Abb. 6 - Bestätigungsdialog zur Deaktivierung des Protected Mode Diese Broker-APIs stellen offensichtlich eine große Angriffsfläche dar. Der Adobe Reader Broker behandelt Daten, die über das API eingehen, als nicht vertrauenswürdig. Um Sicherheitslücken im Broker-Prozess zu vermeiden, hat das Adobe Reader Team die folgenden Best Practices für die Entwicklung sicherer Software implementiert: - Validierung von Eingaben für jeden Parameter - Beschränkung der erlaubten Parameter auf eine kleine Auswahl, die in der Whitelist geführt wird - Code-Prüfung und Code-Inspektion - API-Fuzzing (Testen mit zufälligen Daten) - Statische Code-Analyse

14 - Penetrationstests Ein großer Teil der oben genannten Aufgaben wurde mit Hilfe von externen Fachleuten durchgeführt. 3.4 Sicherheitsvergleich: Adobe Reader X versus Adobe Reader 9 In den vorausgegangenen Abschnitten haben wir die Einschränkungen beschrieben, denen der Sandbox-Prozess unterliegt. In diesem Abschnitt beschreiben wir, mit welchen Maßnahmen verhindert wird, dass der Broker-Prozess von Angreifern genutzt werden kann, um Berechtigungen zu erlangen. Am Ende dieses Dokuments steht ein Vergleich der Sicherheit von Adobe Reader Version 9 unter Windows XP und Adobe Reader X unter Windows 7 bei Angriffen mit präparierten PDF-Dateien. Sehen wir uns zunächst an, welche Sicherheitsfunktionen Adobe Reader 9 bietet: - Data Execution Prevention (DEP) Ein Angreifer könnte leicht eine Sicherheitslücke in Adobe Reader 9 ausnutzen, um mit einer präparierten PDF-Datei und verschiedenen Methoden die DEP (deutsch: Datenausführungsverhinderung) zu umgehen. Die folgende Grafik verdeutlicht die gängigsten Schritte eines Angriffs, bei dem Malware mit Adobe Reader 9 auf einem Windows XP-System installiert wird, wenn Benutzer standardmäßig als Administrator angemeldet sind: Abb. 7 Typischer Angriff zur Installation von Malware mit Adobe Reader 9 unter Windows XP Betrachten wir nun im Vergleich dazu, welche Maßnahmen für einen erfolgreichen Angriff auf Adobe Reader X Protected Mode unter Windows 7 erforderlich sind: Im Broker-Prozess und im Sandbox-Prozess sind die folgenden Sicherheitsfunktionen aktiviert: - Data Execution Prevention (DEP) - Address Space Layout Randomization (ASLR)

15 - Structured Exception Handling Overwrite Protection (SEHOP) Die Kombination dieser Sicherheitsfunktionen des Betriebssystems stellt eine beträchtliche Hürde für Angreifer dar, die über eine präparierte PDF-Datei die Ausführung von bösartigem Code erreichen wollen. Zunächst müssten die Sicherheitsfunktionen der Sandbox überwunden werden, um dann mit Hilfe der präparierten PDF-Datei eine Sicherheitslücke im Adobe Reader Broker-Prozess zu finden, die das Erlangen höherer Berechtigungen ermöglicht. Für den Broker-Prozess sind jedoch alle der oben aufgeführten Sicherheitsfunktionen aktiviert (DEP, ASLR, SEHOP). Der Angreifer müsste also mit der präparierten PDF-Datei diese Hürden im Broker-Prozess überwinden, um durch die Ausführung seines Codes höhere Berechtigungen zu erlangen. Aber selbst wenn er bis zu diesem Punkt kommt, wird er unter Windows Vista und späteren Windows-Versionen nicht in der Lage sein, die Kontrolle über das System zu übernehmen. Abb. 8 - Angriff zur Installation von Malware mit Adobe Reader X unter Windows 7 Der Broker-Prozess läuft auf diesen Plattformen nicht mit einer Administrator- Sicherheitskennung (SID), daher müsste der Angreifer an diesem Punkt eine weitere Sicherheitsfunktion umgehen, um höhere lokale Berechtigungen zu erlangen und damit seine Attacke erfolgreich abzuschließen. Ist der Adobe Reader Protected Mode aktiviert, muss der Angreifer also fünf verschiedene Hürden überwinden (anstatt zwei), um mit dieser konventionellen Attacke erfolgreich zu sein und Malware dauerhaft zu installieren. Es gibt natürlich viele verschieden Arten von Angriffen, aber dieses Beispiel zeigt, wie viel schwieriger es ist, diese konventionelle Front Door -Attacke auszuführen, wenn Adobe Reader mit allen Sicherheitsfunktionen des Protected Mode läuft.

16 4. Einschränkungen des Adobe Reader Protected Mode Da die Funktion der Sandbox in hohem Maße von der Zuverlässigkeit des Betriebssystems abhängt, ist sie auch von potenziellen Fehlern des Betriebssystems betroffen. Ähnlich wie die Google Chrome Sandbox nutzt auch die Sandbox des Adobe Reader Protected Mode das Windows-Sicherheitsmodell und die Sicherheitsfunktionen des Betriebssystems. Aufgrund dieser immanenten Abhängigkeit kann die Sandbox zwar nicht gegen Probleme oder Bugs des Betriebssystems schützen, sie kann jedoch die Folgen dieser Probleme begrenzen, wenn Code in der Sandbox ausgeführt wird, weil die dadurch viele gängige Attacken blockiert werden. Die erste Version der Adobe Reader Sandbox schützt nicht gegen: - Unbefugten Lesezugriff auf das Dateisystem oder die Registry. Wir planen entsprechende Funktionen für ein zukünftiges Release. - Netzwerkzugriff. Wir prüfen Möglichkeiten zur Beschränkung des Netzwerkzugriffs in späteren Versionen. - Lese- und Schreibzugriffe auf die Zwischenablage - Unsichere Betriebssystem-Konfigurationen Die letzte Zutat einer Windows Sandbox wäre nach dem Rezept für Practical Windows Sandboxing die Verwendung eines separaten Desktop für das Rendern der Benutzeroberfläche (UI). Aufgrund der komplexen Änderungen, die für die Rendering-Funktionen von Adobe Reader erforderlich gewesen wären, haben wir uns jedoch gegen diese Variante entschieden. Stattdessen haben wir die Attacken identifiziert, die ohne separates Desktop begünstigt werden Shatter-Attacken und SetWindowsHookEx DLL Injection Attacken. Diese werden durch alternative Methoden entschärft, z. B. durch niedrige Integrität und Einschränkungen für die Auftragsobjekte (Job Objects) der Sandbox. 5. Fazit Der Adobe Reader Protected Mode basiert wie auch die Chrome Browser Sandbox von Google auf der Practical Windows Sandboxing Technologie von Microsoft. Der Protected Mode wurde so konzipiert, dass der Adobe Reader nicht für Angriffe mit bösartigen PDF-Dateien genutzt werden kann, um Änderungen am System vorzunehmen oder dieses zu kontrollieren. Bisher genügte nur eine Sicherheitslücke in Anwendungen wie Adobe Reader, um durch Ausführung von Malware den Computer des Anwenders zu manipulieren. Mit aktivierter Sandbox-Funktion muss der Angreifer mindestens zwei Sicherheitslücken finden, die er ausnutzen kann, wodurch der Aufwand beträchtlich steigt. Adobe Reader Protected Mode ist keine Wunderwaffe und schützt den Anwender nicht gegen gängige Attacken aus dem Web wie SQL Injection, Phishing oder das so genannte Clickjacking. Der Protected Mode ist lediglich eine weitere Verteidigungslinie mit einem innovativen Konzept für die Entschärfung von Malware-Attacken.