{"id":202682,"date":"2018-03-28T07:12:48","date_gmt":"2018-03-28T05:12:48","guid":{"rendered":"https:\/\/www.borncity.com\/blog\/?p=202682"},"modified":"2021-09-25T23:47:49","modified_gmt":"2021-09-25T21:47:49","slug":"windows-7-januar-patches-reien-total-meltdown-sicherheitslcke","status":"publish","type":"post","link":"https:\/\/borncity.com\/blog\/2018\/03\/28\/windows-7-januar-patches-reien-total-meltdown-sicherheitslcke\/","title":{"rendered":"Windows 7: Januar-\/Februar 2018-Patches reißen Total Meltdown-Sicherheitslücke"},"content":{"rendered":"

[English<\/a>]Das scheint wohl schief gegangen zu sein. Wer die Microsoft Meltdown-Updates vom Januar 2018 unter Windows 7 installierte, handelte sich nicht nur m\u00e4chtig \u00c4rger ein. Tief unter der Haube rei\u00dfen die Meltdown-Patches ein riesiges Sicherheitsloch auf. Damit kann jeder Prozess ohne Exploits unter Windows 7 auf beliebige Speicherbereiche lesend und schreibend zugreifen. Hier ein paar Informationen.<\/p>\n

<\/p>\n

Worum geht es?<\/h2>\n

\"\"Zum Jahreswechsel 2018 wurden ja die Schwachstellen mit den Namen Meltdown und Spectre auf (Intel) CPUs bekannt. \u00dcber diese Schwachstellen l\u00e4sst sich von nicht privilegierten (Anwendungs-)Prozessen auf Informationen im Speicher zugreifen \u2013 ein sicherheitstechnischer GAU. Ich hatte \u00fcber das Thema hier im Blog berichtet (siehe Linkliste am Artikelende).<\/p>\n

\"Meltdown\/Spectre\"<\/p>\n

Die Softwarehersteller versuchten hektisch die Schwachstellen mit Updates abzudichten. Auch Microsoft schob im Januar 2018 einige Updates zum Abschw\u00e4chen der Meltdown-L\u00fccken auf seine Windows-Maschinen (siehe Link-Liste am Artikelende). Dabei hat man aber wohl den Teufel mit Belzebub ausgetrieben, denn die Meltdown-Patches f\u00fcr Windows 7 haben eine riesige Sicherheitsl\u00fccke im Kernel aufgerissen. Diese erlaubte jedem Prozess, den kompletten Speicherinhalt (mit Leistungen von Gigabyte pro Sekunde) zu lesen, und es war auch m\u00f6glich, an beliebige Speicheradressen zu schreiben.<\/p>\n

Es war kein Exploit mehr n\u00f6tig, um Speicherbereiche auszulesen oder zu manipulieren. Denn Windows 7 \u00fcbernahm die Arbeit, den ben\u00f6tigten Speicher in jeden laufenden Prozess einzubinden. Die Ausnutzung erforderte lediglich schlichte Lesen- und Schreibenoperationen auf den bereits gemappten virtuellen Speicher. Darauf macht Ulf Frisk im Blog-Beitrag Total Meltdown?<\/a> aufmerksam (danke an Blog-Leser Hansi f\u00fcr den Hinweis<\/a>).<\/p>\n

Die Details<\/h2>\n

Ulf Frisk schreibt im Blog-Beitrag Total Meltdown?<\/a>, dass das das User\/Supervisor-Berechtigungsbit durch den Patch im selbstreferenzierenden PML4-Eintrag auf die User gesetzt wurde. Dadurch standen die Seitentabellen in jedem Prozess dem User-Mode-Code zur Verf\u00fcgung. Die Seitentabellen sollten normalerweise nur vom Kernel selbst zug\u00e4nglich sein.<\/p>\n

\"PCILeech
\n(Quelle: Ulf Frisk)<\/p>\n

Mit einem kleinen Programm pcileech lie\u00df sich dies in der Eingabeaufforderung leicht testen, wie der obige Screenshot und die nachfolgende Abbildung zeigen.<\/p>\n

\"PCILeech
\n(Quelle: Ulf Frisk)<\/p>\n

In Kompaktform: Windows verwaltet die Speicherzugriffe \u00fcber eine Page Memory List (die PML4), wo auch geregelt ist, welcher Prozess auf welches Speicher zugreifen darf. Die PML4 ist die Basis der 4-stufigen In-Memory Page Table Hierarchie. Mit dieser \u00fcbersetzt die CPU Memory Management Unit (MMU) die virtuellen Adressen eines Prozesses in physikalische Speicheradressen im RAM. Weitere Informationen zum Thema Paging finden sich im Dokument Getting Physical: Extreme abuse of Intel based Paging Systems <\/em>– Part 1<\/a> und Part 2<\/a>.<\/p>\n

Windows h\u00e4lt einen speziellen Eintrag in dieser obersten PML4-Seitentabelle, der sich selbst referenziert. Das Problem: In Windows 7\u00a0 ist die PML4-Selbstreferenzierung an der Position 0x1ED, Offset 0xF68 zu finden (erst in Windows 10 ist die Position des Eintrags randomisiert).<\/p>\n

Das bedeutet, dass die PML4 immer auf die Adresse: 0xFFFFFFF6FB7DBED000 im virtuellen Speicher abgebildet wird. Dies ist normalerweise aber eine Speicheradresse, die nur dem Kernel (Supervisor) zur Verf\u00fcgung gestellt wird. Leider ist beim Januar 2018 Patch ein Unfall passiert, indem das Berechtigungsbit f\u00e4lschlicherweise auf User gesetzt wurde. Dies bewirkte, dass die PML4 in jeden Prozess eingeblendet und f\u00fcr die Ausf\u00fchrung von Code im User-Mode zur Verf\u00fcgung gestellt wurde.<\/p>\n

Besitzt ein (User-)Prozess Lese-\/Schreibzugriff auf die Seitentabellen, ist es trivial einfach, auf den gesamten physikalischen Speicher zuzugreifen. Ausnahme stellt nur Speicher dar, der zus\u00e4tzlich durch Extended Page Tables (EPTs), die f\u00fcr die Virtualisierung verwendet werden, gesch\u00fctzt ist. Alles, was man tun muss, ist, eigene Page Table Entries (PTEs) in die Seitentabellen zu schreiben, um auf beliebigen physikalischen Speicher zuzugreifen, schreibt Ulf Frisk.<\/p>\n

Toolkit zum Testen<\/h2>\n

Ulf Frisk hat auf GitHub das PCILeech direct memory access attack toolkit<\/a> ver\u00f6ffentlicht. Es reicht, laut Frisk, das Toolkit herunterzuladen und dann die in seinem Beitrag hier<\/a> angegebenen pcileech.exe dump<\/em> Befehle auszuf\u00fchren. Aktuell habe ich ich aber noch Probleme, das zu testen, da mir der Befehl nur die Parameter auflistet.<\/p>\n

Es sind wohl nur Windows 7 x64-Systeme (und nat\u00fcrlich Windows Server 2008 R2, da dieser den gleichen Kernel samt Patches teilt) anf\u00e4llig, die mit den Update von Januar und Februar 2018 gepatcht wurden. Mit dem M\u00e4rz 2018-Update f\u00fcr Windows 7 ist diese L\u00fccke geschlossen. Aber da gibt es andere Probleme (siehe Patchday: Weitere Microsoft Updates zum 13. M\u00e4rz 2018<\/a>).<\/p>\n

Frisk entdeckte diese Schwachstelle kurz nach dem er am Patch-Dienstag im M\u00e4rz 2018 das Update, das die L\u00fccke schloss,\u00a0 installiert hatte. Er schreibt aber, dass er nicht in der Lage war, die Verwundbarkeit mit bekannten CVEs oder anderen bekannten Problemen zu korrelieren.<\/p>\n

Nachtrag: Patch vom Patch<\/h2>\n

Auch das M\u00e4rz 2018 Sicherheits-Update vom 13. hat nicht geholfen. Daher hat Microsoft am 29.3.2018 ein Sicherheits-Update nachgeschoben (siehe\u00a0Windows 7\/Server 2008 R2: Update KB4100480 (29.3.2018)<\/a>).<\/p>\n

\u00c4hnliche Artikel:
\n<\/strong>Windows 10: Kritische Updates vom 3.1.2018<\/a>
\nKritische Sicherheitsupdates f\u00fcr Windows 7\/8.1\/Server (3.\/4.1.2018)<\/a>
\nWeitere Updates (Internet Explorer, GDI) 3.1.2018<\/a><\/p>\n

Sicherheits-Updates f\u00fcr Windows 7\/8.1<\/a> (13. M\u00e4rz 2018)
\nPatchday: Weitere Microsoft Updates zum 13. M\u00e4rz 2018<\/a><\/p>\n

AMD-GAU & AV-\u00c4rger: Neues zu Windows-Sicherheitsupdates<\/a>
\nWindows Updates (KB4056892, KB4056894 etc.) f\u00fcr AMD tempor\u00e4r zur\u00fcckgezogen<\/a>
\nMicrosoft Patchday: Office, Flash, Windows (9. Januar 2018)<\/a>
\nPatchday: Windows 10-Updates 13. M\u00e4rz 2018<\/a>
\nIntel Microcode-Updates Stand 11. M\u00e4rz 2018<\/a>
\nIntel Fixes gegen Meltdown und Spectre wegen Bugs gestoppt<\/a>
\nMeltdown-\/Spectre: Testtool-\u00dcbersicht<\/a>
\nMeltdown und Spectre: Was Windows-Nutzer wissen m\u00fcsse<\/a>
\nInfos zu Meltdown und Spectre: Was man wissen sollte \u2013 Teil 1<\/a>
\nInfos zu Meltdown und Spectre: Was man wissen sollte \u2013 Teil 2<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

[English]Das scheint wohl schief gegangen zu sein. Wer die Microsoft Meltdown-Updates vom Januar 2018 unter Windows 7 installierte, handelte sich nicht nur m\u00e4chtig \u00c4rger ein. Tief unter der Haube rei\u00dfen die Meltdown-Patches ein riesiges Sicherheitsloch auf. Damit kann jeder Prozess … Weiterlesen →<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[426,185],"tags":[6753,4328,1782,4315,4294],"class_list":["post-202682","post","type-post","status-publish","format-standard","hentry","category-sicherheit","category-update","tag-meltdown","tag-sicherheit","tag-sicherheitslucke","tag-update","tag-windows-7"],"_links":{"self":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts\/202682","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/comments?post=202682"}],"version-history":[{"count":0,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts\/202682\/revisions"}],"wp:attachment":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/media?parent=202682"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/categories?post=202682"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/tags?post=202682"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}