Microsoft stärkt die Immunität von Internet Explorer gegen Angriffe nach der Verwendung

    Unser Beitrag zu ASLR-Verbesserungen in neueren Windows-Versionen enthielt eine Tabelle mit den Sicherheitslücken bei der Remotecodeausführung, mit denen Angreifer bösartigen Code remote auf dem System installiert haben (Drive-by-Download). Mehr als die Hälfte dieser Sicherheitslücken ist vom sogenannten Typ. Use-After-Free (UAF). UAF kann als eine bequeme Möglichkeit für Angreifer beschrieben werden, die Kontrolle auf ihren Code zu übertragen. In einem solchen Schema sollte legitimer ausführbarer Code, z. B. Internet Explorer, eine falsche Logik für die Arbeit mit dem Speicher enthalten, die darin besteht, dass ein Code irgendwann auf einen Zeiger auf den Speicherblock im Heap zugreift, der bereits zuvor freigegeben wurde.



    Offensichtlich kann ein solcher Fehler beim Arbeiten mit dem Speicher einfach zum Absturz des Browsers führen, da auf ihn ein ungültiger Zeiger zugreift. Im Falle des Exploits verwenden Angreifer ihn jedoch für ihre eigenen Zwecke, um den anfälligen Code zu zwingen, die Kontrolle an die gewünschte Adresse zu übertragen. In der Regel wird hierfür Heap-Spray verwendet, um eine große Anzahl von Speicherblöcken an einer vorhersehbaren Adresse im Heap zu reservieren und mit den für den Angreifer erforderlichen Anweisungen zu füllen. Im Juni und JuliBei kumulativen Updates für Internet Explorer 11 hat Microsoft zusätzliche Schadensbegrenzungstechnologien in Form eines isolierten Heaps eingeführt, wenn Speicher für Objekte zugewiesen und die Freigabe von Speicherblöcken verschoben wird. Dieser Ansatz schützt den Browsercode, der beim Arbeiten mit dem Speicher möglicherweise noch Fehler enthält, vor Exploits.

    Typischerweise lautet die Logik zum Arbeiten mit dem Heapspeicher wie folgt:

    1) Der Browser weist dem Heap einen Speicherblock zu.
    2) benutzt es;
    3) Veröffentlichungen.

    Im Falle eines Fehlers im Code kann die Arbeit mit dem Speicher folgendermaßen aussehen:

    1) Der Browser weist dem Heap einen Speicherblock zu.
    2) benutzt es;
    3) Veröffentlichungen;
    4) greift wiederholt über den in der Variablen gespeicherten Zeiger auf diesen Block zu (z. B. über vtable).

    Das am häufigsten verwendete Exploitation-Layout sieht folgendermaßen aus:

    1) Der Browser weist dem Heap einen Speicherblock zu.
    2) benutzt es;
    3) Veröffentlichungen;
    4) der Benutzer besucht die Webseite mit dem Exploit;
    5) Der Exploit führt Sprühhaufen durch (um ASLR zu umgehen) und füllt die Blöcke mit dem erforderlichen Code (z. B. Shell-Code) oder Speicheradressen (um eine Sicherheitsanfälligkeit auszulösen).
    6) der Exploit schafft die Bedingungen für eine Situation, in der auf den Browsercode durch einen ungültigen Zeiger zugegriffen wird, der bereits gültig ist, wie in Absatz 4 angegeben;
    7) Der Browser kehrt zum Zeiger zurück und überträgt die Steuerung mit nicht autorisiertem Code an den Speicherblock (führen Sie zuvor Exploit-Gadgets aus, die DEP für Heap-Blöcke über ntdll! NtProtectVirtualMemory deaktivieren ).

    In dieser Situation kann zum Schutz des anfälligen Codes vor Ausnutzung ein separater Speicherhaufen und eine verzögerte Freigabe des Speichers verwendet werden. Da der Speicherblock später freigegeben wird, können Angreifer diese Adresse nicht erneut reservieren. Ein solcher Mechanismus wurde von Microsoft eingeführt.


    Abb. Das Zuweisen von Speicher in einem isolierten Heap mithilfe der CMarkup :: CreateInitialMarkup- Methode zum Initialisieren eines CMarkup-Objekts finden Sie unter Sicherheitsanfälligkeit in Microsoft Internet Explorer CMarkup . Vor MS14-035 wurde die Zuordnung von einem gemeinsamen Prozessspeicherhaufen vorgenommen.


    Abb. Juli MS14-037 führte die verzögerte Freigabe von Speicherblöcken mit MemoryProtection :: CMemoryProtector :: ProtectedFree ein, der den Block nicht tatsächlich freigibt, sondern lediglich die erforderlichen Hinweise dazu in der Systemdatenstruktur markiert.


    Abb. Methoden, die für die Implementierung der verzögerten Speicherlogik verantwortlich sind.


    Abb. Die MemoryProtection :: CMemoryProtector :: ProtectedFree- Methode führt die verzögerte Freigabe von Speicherblöcken des isolierten Heaps _g_hIsolatedHeap und des Heaps des _g_hProcessHeap- Prozesses selbst ein .


    Abb. Die Freigabe des verzögerten Speichers wird auch von der CTreeNode-Klasse verwendet (siehe vorherige CVE-2013-3893).

    Wenn der Benutzer an der aktuellen Version von Windows 8.1 x64 mit Internet Explorer 11 arbeitet, verfügt er über die erforderlichen Funktionen, um die Ausnutzung von 0-Tage-Sicherheitslücken zu verhindern.



    Bild
    Sei sicher.

    Jetzt auch beliebt: