[English]In allen unterstützten Windows-Versionen gibt es eine ungepatchte Schwachstelle in der Adobe Type Manager Library. Inzwischen versuchen Hacker diese Schwachstelle auszunutzen, wie Microsoft in einem Sicherheitshinweis schreibt. Ergänzung: Von 0patch gibt es inzwischen einen Fix.
Anzeige
Die Information findet sich in ADV200006, und betrifft eine Schwachstelle in der Adobe Type 1 Manager Library. Ich bin über nachfolgenden Tweet und einen Sicherheitshinweis von Microsoft per Mail auf diese Schwachstelle aufmerksam geworden.
Microsoft is aware of limited targeted attacks that could leverage unpatched vulnerabilities in the Adobe Type Manager Library, and is providing guidance to help reduce customer risk until the security update is released. See the link for more details. https://t.co/tUNjkHNZ0N
— Security Response (@msftsecresponse) March 23, 2020
Microsoft ist sich der begrenzten Anzahl gezielter Angriffe bewusst, die ungepatchte Schwachstellen in der Adobe Type Manager Library ausnutzen könnten, und stellt Hinweise zur Verringerung des Risikos bis zur Veröffentlichung des Sicherheitsupdates zur Verfügung.
Type 1 Font Parsing Remote Code Execution-Schwachstelle
In ADV200006 schreibt Microsoft, dass es in Microsoft Windows zwei Sicherheitslücken gibt, die eine Remote-Codeausführung ermöglichen, weil die Windows Adobe Type Manager Library eine speziell entwickelte Multi-Master-Schriftart – das Adobe Type 1 PostScript-Format – nicht korrekt verarbeitet. Ein Angreifer kann die Sicherheitslücke ausnutzen, wenn er z. B. einen Benutzer dazu bringt, ein speziell gestaltetes Dokument zu öffnen oder es im Windows-Vorschaufenster anzuzeigen.
Anzeige
Microsoft ist sich dieser Schwachstelle bewusst und arbeitet an einer Lösung. Updates, die Sicherheitslücken in Microsoft-Software beheben, werden normalerweise zum Patch-Dienstag (2. Dienstag im Monat) freigegeben. Aktuell liegt jedoch noch kein Sicherheitsupdate vor.
Betroffen sind alle Windows-Versionen, von Windows 7 SP1 über Windows 8.1 bis hin zu Windows 10 – und natürlich alle Server-Pendants. Auf Systemen mit Windows 10 kann ein erfolgreicher Angriff nur in einem AppContainer-Sandbox-Kontext stattfinden und ermöglicht somit nur begrenzte Berechtigungen und Fähigkeiten zur Ausführung von Code.
Maßnahmen zur Abschwächung
Microsoft gibt in ADV200006 verschiedene Maßnahmen an, mit denen sich diese, also kritisch angesehene, Schwachstelle abschwächen lässt. Eine Maßnahme besteht darin, die Vorschau für Dokumente im Explorer abzuschalten. Eine weitere Maßnahme besteht darin, die Bibliothek ATMFD.DLL zu deaktivieren. Beachtet aber (siehe auch folgende Kommentare), dass diese Maßnahmen sich weitgehend auf ältere Betriebssysteme vor Windows 10 beziehen.
Aktuell gibt es noch kein Sicherheitsupdate zum Schließen dieser Schwachstelle, obwohl Versuche zur Ausnutzung der Schwachstelle bekannt geworden sind. Aber Microsoft arbeitet an einem Patch, der voraussichtlich zum April 2020 Patchday freigegeben wird. Für Windows 7 SP1 und Windows Server 2008 R2 ist jedoch eine ESU-Lizenz erforderlich, um das dann verfügbare Sicherheitsupdate zu erhalten.
Die Leute von AGROS Security haben inzwischen einen Micropatch für ihren 0patch-Agementen entwickelt, der Windows 7 SP1 und Windows Server 2008 R2 schützt – siehe 0patch fixt 0-day Adobe Type Library bug in Windows 7.
Anzeige
>"Betroffen sind alle Windows-Versionen, von Windows 7 SP1 über Windows 8.1 bis hin zu Windows 10"
Es gibt überhaupt keine ATMFD.DLL unter Windows 10. Die beschriebenen Maßnahmen funktionieren nur bei 8.1 und älter.
Unter Windows 10 heisst die Datei: atmlib.dll
Windows Open Type Library / Adobe Systems
Diese Datei ist unter Windows 10 auch nicht in der Registry verlinkt.
Alle Maßnahmen von MS beziehen sich nur auf die alte ATMFD und nicht die amtlib:
https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/adv200006#ID0EMGAC
Hm, so ganz stimmt Deine Aussage nicht. Bis 1703 ist die Datei ' ATMFD.DLL' durchaus vorhanden.
>"Bis 1703 ist die Datei ' ATMFD.DLL' durchaus vorhanden."
Das ist sicher für Firmen noch relevant, aber unter 1909 ist sie definitiv durch vorherige System-Upgrades aus SysWOW64 und System32 durch MS entfernt worden. Ob sie auch in 1903 fehlt kann ich leider nicht mehr beantworten.
Ich hätte jetzt gerne eine Stellungnahme aus Redmond zu dem Chaos ATMFD versus amtlib.
Ich habe in den BATCH-Dateien von MS einfach den DLL-Namen geändert und die Rechtevergabe und das umbenennen hat dann auch unter Windows 10 funktioniert.
Warum MS derart vergisst ihr Hauptbetriebssystem mit korrekten Anleitungen zu versorgen erschließt sich nicht, aber ich wollte diese Erkenntnisse mit euch teilen.
Danke dir für die Ergänzung – ich trage das im englischsprachigen Blog-Beitrag nach – dann kriegen es einige Leute möglicherweise mit.
PS: Wegen der ATMFD.DLL – bin mir nicht sicher, ob MS die Nacht noch nachgebessert hat. In ADV200006 gibt es aktuell eine Tabelle im Abschnitt Mitigations, die genau angibt, in welchen Windows 10-Versionen die Datei noch vorhanden und in Benutzung ist. Durch das AppContainer-Geschehen ist die Ausnutzbarkeit in Richtung Privilege Escalation aber beschränkter als bei Win 7/8.1.
Danke, dann mache ich das Umbenennen rückgängig. Eine Sorge weniger nach dem ECC-Debakel und der SMB-Lücke.
Ich hab jetzt auf unserem Proxy und Emailserver den Empfang von OTF Dateien gesperrt, dann kommt der Kram erstmal nicht rein, bis das gepatcht ist.
Und wie schützt du dich bitte gegen die Dokumentenvorschau im Explorer und in PDF eingebettete Fonts?
Erster Nebeneffekt hier in der Firma:
Nach Deaktivierung des WebClient Dienstes funktioniert TeamViewer nicht mehr…
Ich muss die Aussage wohl zurücknehmen, nach ca. 10 Minuten funktionierte TeamViewer wieder. War wohl nur zeitliche Koinzidenz mit einem Schluckauf bei TeamViewer's Servern.
Update: Bestätigt, TeamViewer's SystemStatus meldet "Connectivity problems for a subset of users".
Klingt mir verdächtig ähnlich wie diese Sache aus 2010 die ich beim recherchieren gefunden habe:
https://www.heise.de/security/meldung/DLL-Luecke-Jetzt-auch-mit-EXE-Dateien-1076682.html
Auch hier wurde bereits über den Web Client Service problemlos ein unerwünschtes Programm geladen. ;-)
VG
Buc
Microsoft schreibt unter anderem:
Umbenennen von ATMFD.DLL
64-Bit-Systeme:
1. Geben Sie an einer administrativen Eingabeaufforderung die folgenden Befehle ein:
cd "%windir%\system32"
takeown.exe /f atmfd.dll
icacls.exe atmfd.dll /save atmfd.dll.acl
icacls.exe atmfd.dll /grant Administrators:(F)
rename atmfd.dll x-atmfd.dll
cd "%windir%\syswow64"
takeown.exe /f atmfd.dll
icacls.exe atmfd.dll /save atmfd.dll.acl
icacls.exe atmfd.dll /grant Administrators:(F)
rename atmfd.dll x-atmfd.dll
Die ersten 3 Befehle funktionieren bei mir.
Beim 4. Befehl jedoch erscheint ein Fehler.
(weiter: siehe unten)
Und zwar:
Administrators: Zuordnungen von Kontennamen und Sicherheitskennungen wurden nicht durchgeführt. 0 Dateien erfolgreich verarbeitet. bei 1 Dateien ist ein Verarbeitungsfehler aufgetreten.
Was mache ich falsch?
Ich habe das Ganze im Standardnutzerkonto über "Ausführen -> cmd – > Als Administrator ausführen" durchgeführt. Reicht das vielleicht nicht?
Eben probiert:
Auch aus dem Administratorkonto (heißt bei mir "Administration") und der Ausführung der cmd.exe als Administrator erscheint nach Eingabe des Befehls "icacls.exe atmfd.dll /grant Administrators:(F)" der oben genannte Fehler!
System: ("leider noch") Win 7 Home Premium 64 Bit SP1
Und nun?
Wenn das ein deutsches System ist, musst du den Namen auf Administratoren im Script umbenennen.
Hat sich überschnitten. Dennoch danke für die Antwort.
Allerdings sollte Microsoft (bzw. das BSI) dann auch mal alle User darauf hinweisen (wie ich finde).
Ich war ursprünglich nach dieser Anleitung (erhielt ich in einer E-Mail vom Buerger-Cert) vorgegangen: https://portal.msrc.microsoft.com/de-de/security-guidance/advisory/ADV200006
Allerdings hat man bei der deutschen Übersetzung wohl vergessen, im Befehl "icacls.exe atmfd.dll /grant Administrators:(F)" das Wort "Administrators" durch "Administratoren" zu ersetzen.
Dies habe ich nun gemacht und es funktioniert!
Sollten Win 8.1 User und darunter nun auch noch ZUSÄTZLICH dies hier ausführen, selbst wenn sie schon die atmfd.dll umbenannt haben?
"Optionales Verfahren für Windows 8.1 und ältere Betriebssysteme (ATMFD deaktivieren)" aus: https://portal.msrc.microsoft.com/de-de/security-guidance/advisory/ADV200006
Wenn man den Workaround von Microsoft befolgt werden zwei o.g. Dateien bei einem 64Bit-System (bzw. eine bei 32Bit) in x-atmfd.dll umbenannt. In meinen System existieren jedoch noch 38 weitere atmfd.dll-Dateien! Jede in einem Ordner unter C:\Windows\winsxs\wow64_microsoft-windows-gdi_31bf3856ad364e35_6.1.7601.xxxxx_none_xxxx..usw. (wobei die x immer unterschiedliche Zahlenfolgen darstellen). Wird auf diese im Betrieb nicht zugegriffen und sind diese weniger anfällig oder was hat das zu bedeuten? Warum ist das Umbenennen dieser Dateien nicht notwendig?
bitte unter neuerem windows 10 beachten:
https://twitter.com/DidierStevens/status/1242249023303499777
scheint so, als wäre der code von atmfd.dll zu fonthostdrv.exe gewandert.
Damit ergibt sich hier evtl. ein andere Angriffsstelle ..
jup