Adobes Kampf gegen die Zero-Day-Schwachstellen im PDF-Format

Exploits für PDF-Schwachstellen in Adobe Reader und Acrobat

01.10.2010 | Autor / Redakteur: Martin Dombrowski / Peter Schmitz

Zero-Day-Schwachstellen in Adobe Reader und Acrobat stellen aktuell das größte Sicherheitsrisiko für Unternehmen dar, da hier PDF oft noch als sicheres Format angesehen wird.
Zero-Day-Schwachstellen in Adobe Reader und Acrobat stellen aktuell das größte Sicherheitsrisiko für Unternehmen dar, da hier PDF oft noch als sicheres Format angesehen wird.

Die Zero-Day-Schwachstellen für Adobe Programme nehmen kein Ende. Kaum ist eine Lücke in Flash gestopft tauchen schon wieder neue auf, diesesmal in den PDF-Tools Adobe Reader und Acrobat. Die Exploits zu den Schwachstellen sind bereits bei Malware „in the wild“ aufgetaucht und für das Metasploit Framework gibt es auch schon das fertige Modul, mit dem man das passende Exploit zur Ausnutzung der Sicherheitslücke erstellen kann. Nur auf den Patch warten die User noch immer.

Am 06. September erhielt der Security-Experte Mila Parkour eine E-Mail, die zuerst SPAM zu sein schien (siehe Bilderstrecke). Bei der Analyse der angehängten PDF-Datei stellte sich jedoch recht schnell heraus, dass es sich hierbei um ein unbekanntes PDF-Exploit handelte. Am 08. September erschien von Adobe ein Security Advisory (CVE-2010-2883) zu der Zero-Day-Schwachstelle im Adobe Reader und Acrobat, die sich auf die von Mila Parkour gefundene Schwachstelle bezieht.

Adobe kündigte ein Patch frühestens in KW40 an. Bei der Betrachtung des Verlaufs der Geschehenisse fällt auf, dass es wie schon so oft in der Vergangenheit, mehrere Wochen dauert bis eine gefundene Schwachstelle durch ein entsprechendes Sicherheitsupdate geschlossen wird.

Adobe verschluckt sich bei der Verarbeitung des SING-Fonts

Die Schwachstelle befindet sich in der Bibliothek “CoolType.dll” und kann durch eine PDF-Datei mit einem speziell präparierten Smart Independent Glyphlets (SING) Font zur Ausführung von Schadcode genutzt werden.

Antiviren-Hersteller berichten darüber, dass der eingeschleuste Schadcode über “Return Oriented Programming” (ROP) Schutzfunktionen wie das DEP und das ASLR umgehen kann. DEP (Data Execution Prevention) ist eine Sicherheitsfunktion, welche es verhindert, Code in nicht legitimen Speicherbereichen auszuführen. ASLR (Address space layout randomization) dient dem erschweren von erfolgreichen Angriffen auf Systemen, indem verschiedene Speicherbereiche des Programms (Stack, Heap, PEB, TEB, Bibliotheken) an undeterministischen Positionen im Speicher abgelegt werden. Da sich diese mit jedem Aufruf des Programms verändern, wird es massiv erschwert stabile Exploits für Sicherheitslücken in der Software zu schreiben.

Inhalt

Inhalt des Artikels:

Kommentare werden geladen....

Kommentar zu diesem Artikel

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 2047499 / Sicherheitslücken)