Warnung: 0-Day-Schwachstelle im Internet Explorer (17.1.2020)

[English]Microsoft hat zum 17. Januar 2020 einen Sicherheitshinweis zu einer 0-Day-Schwachstelle im Internet Explorer veröffentlicht, der praktisch alle Windows-Versionen betrifft (da der Internet Explorer dort als Browser vorhanden ist). Es gibt ein Problem im JScript-Teil, das zu einer Remote Code-Ausführung genutzt werden könnte. Hier einige Informationen, auch wie man das per Workaround entschärfen kann.


Anzeige

Internet Explorer 0-Day-Schwachstelle

Zum 17. Januar 2020 hat Microsoft eine Sicherheitswarnung vor einer Zero-Day-Schwachstelle im Internet Explorer veröffentlicht, für die es keinen Patch gibt. Laut  Catalin Cimpanu hatte der chinesische Sicherheitsanbieter Qihoo 360 das letzte Woche kurz auf Twitter angerissen, den Tweet aber wieder gelöscht. Hier die Sicherheitsmeldung von Microsoft:

**************************************************************
Title: Microsoft Security Advisory Notification
Issued: January 17, 2020
**************************************************************

Security Advisories Released or Updated on January 17, 2020
=================================================

* Microsoft Security Advisory ADV200001

ADV200001 | Microsoft Guidance on Scripting Engine Memory Corruption Vulnerability
– Reason for Revision: Information published.
– Originally posted: January 17, 2020
– Updated: N/A
– Version: 1.0

In der Scripting Engine, die auch vom Internet Explorer verwendet wird, gibt es eine Memory Corruption-Schwachstelle.

A remote code execution vulnerability exists in the way that the scripting engine handles objects in memory in Internet Explorer. The vulnerability could corrupt memory in such a way that an attacker could execute arbitrary code in the context of the current user. An attacker who successfully exploited the vulnerability could gain the same user rights as the current user. If the current user is logged on with administrative user rights, an attacker who successfully exploited the vulnerability could take control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.

Bei der Ausführung von Objekten durch die Scripting Engine im Internet Explorer kann es zu Speicherüberläufen bzw. –Beschädigungen kommen.

RCE-Codeausführung möglich


Anzeige

Die Sicherheitsanfälligkeit könnte den Speicher so beschädigen, dass ein Angreifer beliebigen Code im Kontext des aktuellen Benutzers ausführen kann. Diese Schwachstelle kann eine Remote Code-Ausführung (RCE) ermöglichen.

Ein Angreifer, der die Sicherheitsanfälligkeit erfolgreich ausnutzen erhalten aber nur die gleichen Benutzerrechte wie der aktuelle Benutzer. Ist der aktuelle Benutzer aber mit administrativen Benutzerrechten angemeldet, erhält der Angreifer, die Möglichkeit, eventuell die Kontrolle über ein betroffenes System zu übernehmen. Ein Angreifer könnte dann Programme installieren, Daten anzeigen, ändern oder löschen oder neue Konten mit vollen Benutzerrechten erstellen.

Problem ist, dass ein Angreifer in einem webbasierten Angriffsszenario eine speziell gestaltete Website hosten könnte, die die Sicherheitsanfälligkeit über Internet Explorer ausnutzt. Dann könnte er versuchen, einen Benutzer dazu bringen, die Website (z. B. durch Senden einer E-Mail mit einem entsprechenden Link) anzuzeigen.

Kritisch, aber beherrschbar

Microsoft stuft die Schwachstelle, die in allen unterstützten Windows-Systemen existiert, zwar auf einigen Windows-Versionen als kritisch ein. Standardmäßig wird der Internet Explorer unter Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016 und Windows Server 2019 aber in einem eingeschränkten Modus ausgeführt, der als erweiterte Sicherheitskonfiguration bezeichnet wird.

Diese Sicherheitskonfiguration verwendet eine Gruppe von vorkonfigurierten Einstellungen in Internet Explorer, die die Wahrscheinlichkeit verringern kann, dass ein Benutzer oder Administrator speziell gestaltete Webinhalte auf einen Server herunterlädt und ausführt. Dies ist ein abschwächender Faktor für Websites, die Sie nicht zur Zone der vertrauenswürdigen Sites in Internet Explorer hinzugefügt haben.

Workaround: ggf. JScript.dll deaktivieren

Als Workaround schlägt Microsoft vor, den Zugriff auf die JScript.dll zu deaktivieren. Für 32-Bit Systeme sind folgende Befehle in einer administrativen Eingabeaufforderung auszuführen.

    takeown /f %windir%\system32\jscript.dll
    cacls %windir%\system32\jscript.dll /E /P everyone:N

Beachtet aber bei einem deutschen Windows meine nachfolgenden Hinweise, falls cacls einen Fehler wirft. Für 64-Bit Systeme sind folgende Befehle in einer administrativen Eingabeaufforderung auszuführen.

    takeown /f %windir%\syswow64\jscript.dll
    cacls %windir%\syswow64\jscript.dll /E /P everyone:N
    takeown /f %windir%\system32\jscript.dll
    cacls %windir%\system32\jscript.dll /E /P everyone:N

Achtung: Die obigen Befehle beziehen sich auf eine englische Windows-Version. In einem deutschen Windows wirft der cacls-Befehl einen Fehler bei der Ausführung. Denn hat Microsoft in der betreffenden Windows-Version auch die Gruppen lokalisiert. Im deutschsprachigen Windows muss dann statt der Gruppe ‘everyone’ ein ‘jeder’ als Attribut verwendet werden. Also so was wie:

cacls %windir%\syswow64\jscript.dll /E /P jeder:N

Danke an Bolko für den Kommentar mit dem Hinweis auf das Problem. Das ist auch wichtig, falls ihr die Hinweise Microsofts zur späteren Freigabe der Scripting Engine umsetzen wollt. Lest auch die weiteren Hinweise und Kommentare im Hinblick auf Kollateralschäden – und fertigt euch ggf. einen Wiederherstellungspunkt bzw. besser ein Backup an, bevor ihr den Microsoft Workaround ausführt.

Tipp: Ich habe mir die obigen vier Befehle sowie einen pause-Befehl als letzte Anweisung für mein Windows 7 SP1 in eine Batchdatei gespeichert, das ‘everyone’ gegen ein ‘jeder’ ausgetauscht und dann die Batchdatei über ‘Als Administrator ausführen’ gestartet. Der Batch ist dann sauber durchgelaufen, der pause-Befehl am Ende bewirkt, dass das Fenster der Eingabeaufforderung geöffnet bleibt und man die Statusmeldungen sehen kann. Zum Schließen einfach eine Taste drücken. Hoffe, das hilft.

Damit wird der Zugriff auf die jscript.dll für jeden Benutzer gesperrt und die Sicherheitsanfälligkeit lässt sich nicht mehr ausnutzen. Die Implementierung dieser Schritte führt zu einer reduzierten Funktionalität für Komponenten oder Features, die auf jscript.dll angewiesen sind. Falls es zu Problemen kommt, dass Anwendungen nicht mehr laufen, enthält der Artikel Anweisungen, um die DLL wieder freizugeben.

Standardmäßig verwenden IE11, IE10 und IE9 die Datei “Jscript9.dll”, die von dieser Sicherheitsanfälligkeit nicht betroffen ist. Diese Sicherheitsanfälligkeit betrifft nur bestimmte Websites, die Jscript als Skript-Engine verwenden. Weitere Details sind dem Microsoft-Beitrag ADV200001 zu entnehmen.

Leider Kollateralschäden!

Ergänzung: Beachtet aber die auch in nachfolgenden Kommentaren bereits aufgeführten Hinweise. So hat die obige Maßnahme eine Reihe Kollateralschäden – alles, was JScript (und die Bibliothek) benötigt, wird nicht mehr funktionieren. So gibt es den Hinweis, dass das Login an Microsoft Online-Konten im IE nicht mehr funktioniert. Und folgender Tweet deutet an, dass das Bitlocker Recovery Probleme macht.

Ich selbst habe seit dem Wochenende das Problem, dass der Firefox nicht mehr funktioniert (ich habe die portable Version in Windows 7 auf einer Partition liegen). Der Browser startet, aber selbst die Einstellungen kann ich nicht mehr öffnen – und Webseiten zeigt er nicht mehr an. Ob es mit dem Eingriff in die DLL zu tun hat, kann ich nicht sagen (neu entpackte Portable-Varianten bringen nix, auch andere Nutzerkonten oder Start im abgesicherten Modus helfen nicht). Im Tor-Bundle läuft der Firefox. Krude Sache.


Anzeige


Dieser Beitrag wurde unter Sicherheit abgelegt und mit Sicherheit verschlagwortet. Setze ein Lesezeichen auf den Permalink.

42 Antworten zu Warnung: 0-Day-Schwachstelle im Internet Explorer (17.1.2020)


  1. Anzeige
  2. Bolko sagt:

    Der Befehl funktioniert nicht:
    cacls %windir%\system32\jscript.dll /E /P everyone:N

    Fehlermeldung:
    “Zuordnungen von Kontennamen und Sicherheitskennungen wurden nicht durchgeführt.”

    Die Konsole wurde mit Adminrechten gestartet.
    Bei dem takeown-Befehl wurde auch bestätigt, dass die Datei jetzt dem Admin gehört.

    Warum funktioniert es nicht?
    Win7 x64

    • Günter Born sagt:

      Ersetze ‘everyone’ durch ‘jeder’. Problem des deutschen Windows, wo diese Werte teilweise lokalisiert werden.

      • Bolko sagt:

        Danke, mit “jeder” gibt es keine Fehlermeldung mehr.

        Anschließend habe ich mit accessenum aus den Systinternals überprüft und jetzt steht bei jscript.dll in der Spalte “Deny” “jeder”, also hat es funktioniert (Zugriff verweigert).

        • RedOne sagt:

          Wie bitte hängt man am Ende den “Pause-Befehl” an?

          einfach so? oder wie?
          pause

          Danke für einen Hinweis

          • Bolko sagt:

            Wofür brauchst du da pause?
            accessenum ist bei mir ein grafisches Tool.

            accesschk ist ein Konsolentool, da kann man die Ausgabe in eine Textdatei umleiten mit >d:\ausgabe.txt

          • Günter Born sagt:

            Hier meine Batchdatei – sorry, der Beitrag ist vor dem Frühstück entstanden und ich musste dann schnell Brötchen holen – Familie schrie nach Brot:

            takeown /f %windir%\syswow64\jscript.dll
            cacls %windir%\syswow64\jscript.dll /E /P jeder:N
            takeown /f %windir%\system32\jscript.dll
            cacls %windir%\system32\jscript.dll /E /P jeder:N
            pause

            Der Pause-Befehl verhindert, dass sich das Fenster der Eingabeaufforderung nach der Abarbeitung der Befehle automatisch schließt, man sieht also, ob Fehler ausgeworfen werden.

            HTH

          • Bolko sagt:

            In einer Batch sollte man aber vor jeden Befehl folgendes schreiben:
            start /wait “” BEFEHL

            damit gewartet wird, bis der Befehl in dieser Zeile auch wirklich beendet ist.
            Denn sonst kann es passieren, dass bereits der folgende Befehl gestartet wird, obwohl er vom vorhergehenden Befehl abhängig ist der aber noch nicht fertig ist und deshalb nicht richtig ausgeführt wird.

          • Günter Born sagt:

            Ist bei umfangreicheren Batches sicher sinnvoll. Meine obige Lösung ist hat Quick and dirty – damit wollte ich sehen, ob jeder statt everyone tut ;-).

          • 1ST1 sagt:

            start /wait “” BEFEHL ist doch völliger Quatsch, sorgt nur dafür, dass ein Befehl im eigenen Fenster gestartet wird, und jedes Mal gewartet wird, dass der Befehl abgearbeitet wird. Das heißt bei längeren Batches hat man dutzende Fenster nacheinander offen, ohne dass man was gewonnen hat. Den Sinn von start /wait “” BEFEHL habe ich noch nie verstanden. Da ist es doch sinnvoller, gleich bei BEFEHL zu bleiben, eine CMD Batch ist ja von sich aus schon kein Multitasking, sondern “Stapelverarbeitung”, eins nach dem anderen, wie die Klees gesse wern. Das wird es es mit Start ohne /wait.

          • Bolko sagt:

            @1ST1:
            Wenn man nur BEFEHL schreibt, dann wird nicht unbedingt gewartet bis der Befehl fertig ist, sondern dann kann auch der folgende BEFEHL2 ausgeführt werden, was aber manchmal nicht funktioniert, da der von BEFEHL1 abhängig sein kann. Es sind ja schliesslich nicht alle Befehle automatisch synchronisiert und bei asynchronem Aufruf kann es Datenmüll geben.

            Bei call passiert alles im selben Kontext, das heisst, der Befehl kann Variablen ändern, was manchmal nicht gewünscht ist.
            Außerdem wird mehr Heap-Speicher verbraucht, wenn sämtliche Befehle im selben Kontext abgearbeitet werden.

            Daher start /wait “”, dann wird unbedingt gewartet, Variablen können nicht verändert werden (eine Fehlerquelle weniger) und der Speicher des gestarteten Befehls wird anschließend wieder freigegeben, ohne den Speicher der Hauptbatch zu beeinträchtigen.

          • Fry sagt:

            @Bolko
            Das mit “start /wait…” ist hier Quatsch. Es handelt sich um Konsolenprogramme und der Batch läuft erst weiter, wenn jedes einzelne komplett beendet wurde.
            Das “start /wait …” braucht man nur dann, wenn es sich um GUI-Programme handelt und die den Start aus der Konsole nicht erkennen/behandeln.

      • Falsch: ersetze everyone durch *S-1-1-0!

  3. Bolko sagt:

    Wäre es ratsam, den Internet Explorer im Win7 abzuschalten?
    Systemsteuerung, Programme, “Windows-Funktionen aktivieren oder deaktivieren”, Haken bei “Internet Explorer 11” entfernen.
    Hat das Nebenwirkungen, wenn man sowieso andere Browser benutzt?

    • Günter Born sagt:

      Den Ratschlag, den IE pauschal in Windows zu deaktivieren (geht über Features und Programme) sollte man nicht geben. Einmal könnte eine DLL möglicherweise immer noch über irgend eine Extension aufgerufen werden.

      Problematischer ist aber, dass dann anderer Microsoft-Kram streikt. Letztes Jahr bin ich mal über einen Tweet von Michael Niehaus (Programmmanager bei Microsoft) gestolpert, wo er bemerkte, dass ein deaktivierter IE 11 zu Ärger bei seinem Outlook aus Office 365 führte, so dass er irgendwelche HTML-Geschichten nicht mehr nutzen konnte. Auch bei Anmeldungen an Office365, meine ich mich zu erinnern, gibt es Kollateralschäden. Daher entkernt MS den IE ja auch nicht aus Windows.

    • Dekre sagt:

      Win7 braucht den IE11.
      Ich weiß nicht wie der Edge in Win7 arbeitet. MS hat diesen auch für Win7 bereitgestellt.
      Vielleicht sollte man dann den IE11 nicht als Standardbrowser einsetzen.

      So wie ich die Lücke lese, muss man bestimmte Webseiten aufrufen und dann muss der Böse dort aktiv sein.

      In der AV-Software von Malwarebytes (pro) kann man auch die IE11 Einstellung anpassen. Das machen nicht jede AV-Software.

      Es wird sicherlich ein Patch von MS geben und da der IE11 auch in Win10 aktiv ist. wird es wohl auch was für Win7 geben.

  4. Anzeige

  5. Richard sagt:

    Danke zunächst für die immer sehr guten Infos hier im Blog!
    Und eine Frage als Nicht-Fachmann:
    Habe ich es richtig verstanden, dass die Gefahr aktuell nicht besteht,
    wenn man den Internet Explorer nicht nutzt, sondern einen
    anderen Browser? Danke für eine kurze Antwort.

    • Günter Born sagt:

      Solange keine Webseiten im IE abgerufen werden, sollte nix passieren.

      • Richard sagt:

        DANKE! Der borncity blog hat mir schon viel geholfen.
        Bin damals darauf aufmerksam geworden, als sich mein
        Win7 Pro nicht mehr updaten lies und habe dann hier
        die Lösung gefunden. Seitdem lese ich regelmäßig
        und habe viel lernen können!

        • woodpeaker sagt:

          Ich benutze den IE schon seit Jahren nicht mehr um ins Internet zu kommen.
          Man braucht ihn leider für manche NAS, da sonst nicht alles angezeigt wird und noch schlimmer ist es bei IP Cams. Die Steuerung geht ja oft über das OCX Gedöns und das funktioniert in voller Güte nur im IE

  6. AUTSCH & AUTSCH!
    Bitte hört auf, UNNÜTZEN SCHWACHSINN wie “Start WAIT …” (oder “pause”) zu verbreiten.
    1. ICACLS.exe und TAKEOWN.exe sind Kommandozeilenprogramme; die werden von CMD.exe SYNCHRON ausgeführt.
    2. Ruft Batchskripts GENERELL mit der Kommandozeile CMD.exe /K CALL “vollqualifizierter Pfadname” auf!
    Um das Windows (genauer: der als EXPLORER.exe bekanntnn Shell) selbst dauerhaft beizubringen lasst euren Administrator EINMAL folgende Kommandos in einer Eingabeaufforderung ausführen:
    FTYPE batfile=%COMSPEC% /K CALL ^”%L^” %*
    FTYPE cmdfile=%COMSPEC% /K CALL ^”%L^” %*

    Und vor allem:
    0. Microsofts “Workaround” hat Nebenwirkungen, und die Änderung an den Zugriffsrechten kann durch eine “Reparatur” jederzeit automatsch rückgängig gemacht werden.
    Wenn diese AHNUNGSLOSEN Tröpfe ihr eigenes Produkt kennen würden, dann legten sie JScript gezielt nur im IE lahm: siehe https://skanthak.homepage.t-online.de/noscript.html

  7. Tosh sagt:

    Tja, der WA von MS verursacht unter NT10 (Windows 10) Probleme mit dem Microsoft Konto.
    Habe nun das Problem, dass ich die Kontoverwaltung über die Einstellungen nicht mehr ausführen kann.
    Unter KONTEN > Ihre Infos > Mein Microsoft Konto verwalten (ist ein Link) wird folgende Fehlermeldung angezeigt:
    “Anmeldung nicht möglich
    Zur Anwendung ist JavaScript erforderlich. Entweder wird JavaScript von Ihren Browser nicht unterstützt oder es wird blockiert.
    Aktivieren Sie JavaScript in Ihren Browser oder verwenden Sie einen Browser der dies unterstützt.”

    Das MS ein WA herausgibt, der derart ungeeignet ist für Windows 10 ist äußerst peinlich.
    Wie deaktiviere bzw mache ich den WA nun rückgängig?

  8. Tosh sagt:

    Unter dem im Artikel genannten Link von MS, was zu tun ist bei Problemen (english) funktioniert im Abschnitt “How to undo the workaround” der Befehl für die 64 bit Version:

    cacls %windir%\system32\jscript.dll /E /R everyone
    cacls %windir%\syswow64\jscript.dll /E /R everyone

    für die deutsche Windowsversion

    cacls %windir%\system32\jscript.dll /E /R jeder
    cacls %windir%\syswow64\jscript.dll /E /R jeder
    nicht
    CMD unter Adminrechten ausgeführt wird angezeigt:
    Bearbeitete Datei: C:\WINDOWS\syswow64\jscript.dll

    • Tosh sagt:

      Bisher einzige Möglichkeit den Workaround rückgängig zu machen ist das Zurücksetzen von Windows über die Einstellungen.
      Was ich dann auch bis etwa 2:00 Uhr letzte Nacht gemacht habe.

      Ich rate daher von einer Anwendung dieses Workarounds bei Windows 8, 8.1 und 10 ganz klar ab!

      Was nützt ein WA wenn man sich dadurch quasi abschiesst?
      Genau, NIX als nur Probleme.

    • Bolko sagt:

      Bei mir funktionieren die Befehle.
      Woher weist du denn, dass die Befehle bei dir nicht funktionieren?

      Die Ausgabe:
      Bearbeitete Datei: C:\WINDOWS\syswow64\jscript.dll
      ist normal.

      Überprüfung mit accessenum ergibt anschließend, dass die Sperre entfernt wurde, also hat der Befehl funktioniert.

      • Tosh sagt:

        Bei mir nicht.
        Hat nicht gefunzt, obwohl dies angezeigt wurde.
        Warum?
        Tja …
        Bevor ich stunden- oder tagelang suche, ist Zurücksetzung das einzig probate Mittel und die Warnung diesen WA NICHT auszuführen.

  9. Anzeige

  10. Hans Thölen sagt:

    Windows 7 Home Premium SP 1 32 Bit.
    Vor 4 Wochen musste ich Java installieren, um auf der Webseite von NVIDIA
    einen Treiber zu suchen. Java wurde installiert, und war auch bis Vorgestern
    in der Liste meiner installierten Programme aufgeführt. Seit 2 Tagen ist Java
    spurlos aus dieser Liste verschwunden, und es wird auch sonst nirgendwo mehr
    gelistet. Was kann da passiert sein ? Ich finde keine Erklärung.

  11. Michael sagt:

    Lieber Günter Born,

    vielleicht solltest Du bei solchen Beiträgen den Hinweis auf ein Backup und/oder einen Wiederherstellungspunkt geben, damit evtl. auftretende Problem wieder rückgängig gemacht werden können.

    Erfahrene Windows-Nutzer machen das, aber nicht jeder der hier mit liest ist auch erfahren genug.

    • Tosh sagt:

      Richtig.
      Backup wurde erstellt, dennoch habe ich mich für das Zurücksetzen entschieden.
      Ist in einem solchen Fall die sauberste Lösung nach kompletter Neuinstallation.
      Nach Rücksetzung die wichtigsten Daten wieder hergestellt und keine 30 Minuten später war alles wie vorher.
      Nur eben sauber im Vergleich zu einem Backup, wo auch Altlasten mitgeschleppt werden, die nicht mehr benötigt werden.

    • Anonymous sagt:

      Ja, oder Windows neu installieren Mann, hier rennen aber auch Kunden rum … Backup und Wiederherstellungspunkt wegen ein paar Zeilen Batch? Give me a break!

      Leute, Günni hat das doch auch nur von MS kopiert und nur extra den Tipp mit “jeder” gegeben, also wenn ihr unbedingt meckern und alles besser wissen müßt, dann beschwert euch bitte einfach in Redmond, ja?

      Manche beschweren sich eben auch noch, wenn’s mal einen Tip umsonst gibt. *kopfschüttel*

  12. Andreas sagt:

    Weiterer Kollateralschaden:
    Auch Lexware Buchhalter verwendet die jscript dank RENESIS scripting engine.
    Ohne jscript keine Buchhaltung :-(

  13. Andreas sagt:

    Weiterer Nebeneffekt: Proxy-Autokonfiguration funktioniert nicht mehr. (Möglicherweise wird intern zum Auswerten der “proxy.pac” noch die “alte” jscript.dll verwendet.) Der Effekt ist reproduzierbar.
    Dadurch sind alle Softwareprodukte betroffen, die auf die System-Proxy-Einstellungen zurückgreifen. Zum Beispiel Citrix Workspace…

  14. Ronald sagt:

    Mehrere HP-Druckertreiber verwenden offenbar diese jscript.dll.
    Vermutlich Zeug was die Tonerstände usw. anzeigt.
    Mit deaktiverter DLL kein Druck auf den HP-Drucker mehr möglich.
    Weiterere WA : Universalprinting-Treiber verwenden.
    Damit kann man drucken …

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.