highandhigh/cve-2015-0057Detaillierte technische Analyse und Exploit-Implementierung für CVE-2015-0057, eine Use-After-Free-Schwachstelle in win32k.sys, die 32-Bit- und 64-Bit-Windows-Systeme von XP bis 8.1 abdeckt.
Autor: Aaron Adams
Übersetzung: 55-AA
Anmerkung des Übersetzers: Teile dieses Artikels wurden sinngemäß übersetzt; bei Fragen siehe Original.
Begriffe:
Anfang dieses Jahres stieß ich auf eine interessante Schwachstelle in win32k.sys (CVE-2015-0057) und realisierte eine stabile Ausnutzung auf 32-Bit- und 64-Bit-Systemen, die von XP bis Windows 8.1 reicht (mit einigen Ausnahmen). Dieser Artikel beschreibt ausführlich, wie ich die Ausnutzung auf beiden Plattformen umgesetzt habe; am Ende sind auch einige zusätzliche Dinge angehängt. Außerdem wird beschrieben, wie die Ausnutzung mit niedrigen Integritätsrechten unter Windows 8.1 mit aktiviertem SMEP gelingt.
Dieser Artikel ist lang; ich habe mich bemüht, so viele Details wie möglich zu liefern, um die Komplexität der Ausnutzung dieser Schwachstelle zu zeigen, statt diese Details zu verbergen. Natürlich habe ich auch einige Details ausgelassen. Ich hoffe, diese Details sind für euch hilfreich.
Am 10. Februar 2015 veröffentlichte Microsoft Details zu MS15-010. Dieser Bug wurde zuerst von Udi Yavo von enSilo entdeckt. Udi gab eine hervorragende Analyse auf dem Breaking-Malware-Blog: „one bit rule-bypassing windows 10 protections using single bit“. Ich empfehle, diesen Artikel gründlich zu lesen, um den Bug tiefgehend zu verstehen, auch wenn ich hier so viele Details wie möglich nennen werde – Details zu einigen Hürden, die beim Auslösen der Schwachstelle überwunden werden müssen. Die Ausnutzung dieser Schwachstelle ist sehr interessant; viele Details stammen aus Udids Blog. Hier seine Aussage:
Angemessene Offenlegung: Obwohl dieser Blog technisch ist, werden wir keinen Code und keine vollständigen Details preisgeben, um zu verhindern, dass irgendein Techniker diesen Exploit nachbauen kann.
Als Bonus für die Ausnutzung dieser Schwachstelle erhielten wir eine Pokémon-Entwicklung: Tech-Elf. Ich muss Udi wohl Anerkennung zollen, denn er hat den Bug entdeckt und im Blog die Zusammenhänge sowie Details zur Ausnutzung bereitgestellt – das war äußerst nützlich.
Zuvor hatte ich niemals eine Schwachstelle in win32k.sys ausgenutzt und war mit User-Mode-Callbacks und vielen zugehörigen APIs nicht vertraut. Deshalb danke ich auch einigen bekannten Sicherheitsforschern für ihre im Internet verfügbaren hervorragenden Ressourcen, etwa Skywing, Tarjei Mandt, Alex Ionescu und j00ru. Diese Leute haben so viel technisches Wissen öffentlich bereitgestellt; sie alle verdienen Anerkennung. Eine Arbeit, auf die ich mich stark gestützt habe, ist Tarjei Mandts Win32k.sys exploitation paper.
Während ich diesen Exploit schrieb, realisierte ein hervorragender Reverse Engineer eine stabile Ausnutzung von CVE-2015-1701; der dortige Beispielcode zu User-Mode-Callbacks war sehr nützlich. Dank an den Autor.
Erwähnenswert ist, dass meine folgende Analyse unter Windows 7 durchgeführt wurde, da es offenbar die einzige Version ist, in der alle Strukturen in win32k.sys über entsprechende Symbole verfügen. Die meisten dieser Symbole lassen sich auf Strukturen in anderen Versionen von win32k.sys anwenden. Aus unbekannten Gründen entfernte Microsoft diese Symbole ab Windows 8.
Schließlich möchte ich sagen: Mein Ansatz zur Ausnutzung ist ziemlich komplex. Es ist durchaus möglich, dass es einen einfacheren Weg gibt, den ich nur nicht gefunden habe. Ich würde gern hören, wenn jemand einen anderen Ansatz verwendet hat. Wie auch immer, ich hoffe, all das ist hilfreich für die Erforschung von win32k.sys-Schwachstellen.
Im Folgenden werfen wir einen Blick auf den Bug im Disassembler-Code von win32k!xxxEnableWndSBArrows. Es ist ein ziemlich eleganter Bug:
Ungepatchter Zustand:
.text:FFFFF97FFF1B157D mov r8d, r13d
.text:FFFFF97FFF1B1580 mov rdx, r14
.text:FFFFF97FFF1B1583 call xxxDrawScrollBar ; 触发usermode callback
.text:FFFFF97FFF1B1588 jmp short loc_FFFFF97FFF1B1519
[...]
.text:FFFFF97FFF1B1519 mov eax, [rbx] ; 引用 tagSBINFO 指针而没有经过检查
.text:FFFFF97FFF1B151B mov ebp, 0FFFFFFFBh
.text:FFFFF97FFF1B1520 xor eax, esi
Im obigen Code kann Win32K!xxxDrawScrollBar unter bestimmten Umständen in den Benutzermodus zurückrufen. Im Benutzermodus kann der Zeiger auf tagSBINFO vom Angreifer freigegeben werden. Wenn die Ausführung zum obigen Code zurückkehrt, referenziert der Code an der Adresse 0xFFFFF97FFF1B1519 einen ungültigen Zeiger.
Gepatchter Zustand:
.text:FFFFF97FFF1D69C3 xor r8d, r8d
.text:FFFFF97FFF1D69C6 mov rdx, rbp
.text:FFFFF97FFF1D69C9 call xxxDrawScrollBar ; 触发usermode callback
.text:FFFFF97FFF1D69CE cmp rbx, [rdi+0B0h] ; 检查 tagSBINFO 指针是否正确
---.text:FFFFF97FFF1D69D5 jz short loc_FFFFF97FFF1D69E4; 如果正确则继续原来的流程
| .text:FFFFF97FFF1D69D7 mov rcx, rbp
| .text:FFFFF97FFF1D69DA call _ReleaseDC
| .text:FFFFF97FFF1D69DF jmp loc_FFFFF97FFF1D6958 ; 跳转到函数退出
|->.text:FFFFF97FFF1D69E4 mov eax, [rbx] ; 放心地使用正确的 tagSBINFO 指针
.text:FFFFF97FFF1D69E6 xor eax, r14d
In der gepatchten Version sehen wir eine Prüfung, bevor der tagSBINFO-Zeiger verwendet wird. Die zugehörigen Strukturinformationen werden später angegeben.
Bei der Umsetzung dieses Exploits führten wir mehrere Korruptionen durch. In einer dieser Korruptionen wird die Schwachstelle ausgelöst.
Die technische Ursache dieses Bugs ist ein UAF (Use-after-Free) im Desktop-Heap. Anfangs war das verwirrend für mich, da ich die User-Mode-Callback-Mechanismen in win32k.sys nicht kannte und nicht verstand, wie sie funktionieren. Deshalb nahm ich an, es handle sich um eine Race Condition bei einer Sperre, die zu UAF führt. Tatsächlich wird die Sperre jener Struktur korrekt verwendet, und der Ablauf entspricht den Erwartungen. Kurz gesagt, die eigentliche Ursache ist:
Die Funktion win32k!xxxEnableWndSBArrows besitzt einen Zeiger auf ein tagSBINFO im Desktop-Heap, der aus der fensterbezogenen tagWND-Struktur gelesen wird und eine Bildlaufleiste beschreibt.
win32k!xxxEnableWndSBArrows ruft eine Funktion auf, die einen User-Mode-Callback auslöst (diese Funktion kann im Benutzermodus per Hook abgefangen werden).
Sobald der Code im Benutzermodus ausgeführt wird, kann die Struktur im Desktop-Heap über andere win32k-Systemaufrufe verändert werden, einschließlich des Freigebens der tagSBINFO-Struktur aus dem Desktop-Heap.
Nach der Rückkehr in den Kernelmodus referenziert win32k!xxxEnableWndSBArrows tagSBINFO nicht erneut aus tagWND und prüft auch nicht, ob der ursprünglich referenzierte Zeiger gültig ist, sondern verwendet direkt den ursprünglich referenzierten Zeiger – der tatsächlich bereits freigegeben wurde.
Das ist schon alles; abgesehen von User-Mode-Callbacks ist diese Phase ziemlich klar.