Bekommen Windows 7-Nutzer ein SHA-2-Update Problem?

win7Besitzer von 32-Bit-Windows 7-Systemen laufen möglicherweise in das Problem, dass sie bald (d.h. vor Ablauf des Support-Zeitraums) keine Updates mehr bekommen. Hintergrund ist, dass das für SHA-2-signierte Updates erforderliche Paket KB4474419 nicht installiert werden kann.


Anzeige

Wir haben heute Juni-Patchday, wo Microsoft Sicherheitsupdates verteilt. Daher möchte ich das Problem thematisieren, um herauszufinden, ob eine größere Anzahl an Nutzern von 32-Bit-Windows 7-Systemen betroffen ist.

Hintergrund: Die Nachrüstung für SHA-2-Updates

Zuerst ein kurzer Ausblick auf den Hintergrund. Microsoft hatte 2018 angekündigt, ab Mitte 2019 seine Windows-Updates nur noch mit SHA-2-Signaturen (statt mit SHA-1 und SHA-2) zu versehen – die Signierung mit SHA-1 entfällt dann aus Sicherheitsgründen. Ich hatte im Artikel Windows 7: Ab April 2019 wird ein ‘SHA-2-Update’ benötigt darüber berichtet.

Benutzer von Windows 7 SP1 (sowie der Server Pendants) und WSUS benötigen daher ab April 2019 ein spezielles Update, welches die Maschine für SHA2-Codesignaturen ertüchtigt. Für eine Übergangszeit werden aber noch Updates mit beiden Signaturen ausgeliefert.

Microsoft hat zum 12. März 2019 den Support-Beitrag 4472027 (2019 SHA-2 Code Signing Support requirement for Windows and WSUS) dahingehend erweitert, als das die für Windows 7 Service Pack 1, Windows Server 2008 R2 Service Pack 1 und Windows Server 2008 Service Pack 2 erforderlichen SHA-2-Updates genannt werden.

Update KB4474419 (SHA-2 code signing support update for Windows Server 2008 R2 and Windows 7: March 12, 2019) rüstet die Unterstützung für die SHA-2-Signaturauswertung für die genannten Betriebssysteme nach. Ich hatte im Blog-Beitrag Windows 7: Updates rüsten SHA-2-Support nach darauf hingewiesen.

Am 18. Juni 2019 muss in Umgebungen mit WSUS 3.0 SP1 das Update KB4484071 installiert sein, um noch Updates zu erhalten. Für Windows 7 SP1 und Windows Server 2008 SP2 ist der SHA-2-Support ab dem 13. August 2019 verpflichtend. Ab September 2019 gibt es keine Updates mehr, wenn die Vorbereitungsupdates für den SHA-2-Support fehlen (siehe diesen Microsoft-KB-Artikel).

Installationsprobleme mit Updates KB4474419

Ich hatte im Blog-Beitrag Windows 7: Updates rüsten SHA-2-Support nach bereits auf Installationsprobleme mit diesem Update hingewiesen. Manche Nutzern haben bei Windows 7 in der 32-Bit-Version echte Probleme. Microsoft hat zwar am 12. März 2019 das Update KB4474419 für die Unterstützung der SHA-2-Codesignierung für Windows Server 2008 R2, Windows 7 und Windows Server 2008 herausgebracht. Dessen Installation endet aber bei manchen Nutzern in einer Neustart-Schleife, wie man in diesen Kommentaren nachlesen kann. Es dreht sich dabei potentiell um die Updates:


Werbung

Bei Dr. Windows gibt es diesen Thread zum Problem. Michael ILOFF hat es auch im englischsprachigen Blog-Beitrag in diesem Kommentar auf den Punkt gebracht: Ohne Installation des SHA-2-Updates werden Betroffene nach August 2019 keine neueren Updates mehr verarbeiten können. In Microsofts KB-Artikeln wie hier habe ich bisher keinen Hinweis auf diese Probleme gefunden.

Fehlerursachen für die Neustartschleife

Die Ursache für das Installationsproblem mit der anschließenden Neustartschleife scheinen fremde Bootlader oder verbogene Partitionsstrukturen zu sein.

Ein KB-Artikel KB3033929 aus 2015

Von Microsoft gibt es einen alten KB-Artikel KB3033929 (Microsoft-Sicherheitsempfehlung: Verfügbarkeit der SHA-2-Codesignaturunterstützung für Windows 7 und Windows Server 2008 R2) vom 10. März 2015. Dort geht es genau um eine Unterstützung für die SHA-2-Codesignatur, die sich nicht installieren lässt. Dort heißt es, dass das Update nicht installierbar sei, wenn folgende Bedingungen gelten:

Einige Benutzer können dieses Sicherheitsupdate nicht installieren, wenn ihre Computer die folgenden Bedingungen erfüllen:

  • Sie verfügen über eine Multiboot-Konfiguration von Windows und verschiedene Linux-Distributionen
  • Sie verwenden keinen Windows-Bootloader
  • Windows- und Linux sind auf verschiedenen Laufwerken installiert

Wir konnten gesichert feststellen, dass Systeme, bei denen der Windows-Bootloader als primärer Loader aktiviert ist, dieses Update erfolgreich installieren können, und dass Systeme, auf denen ein anderer Bootloader als primärer Bootloader angegeben ist, das Update selbst dann nicht installieren können, wenn der Benutzer mit diesem Loader Windows auswählt.

Microsoft schlägt folgenden Workaround vor: Um dieses Problem zu umgehen, können Sie entweder Windows als Standardbootloader verwenden oder die BIOS-Einstellungen so ändern, dass der Windows-Bootloader direkt aktiviert wird, wenn Sie dieses Update installieren. Heise hat im Jahr 2015 den Artikel Bootschleife nach SHA-2-Update für Windows 7 auf Basis der obigen Informationen veröffentlicht, der noch praktische Ansätze liefert. Interessant sind auch die Kommentare zu diesem Artikel, die diverse Konstellationen als Fehlerursache samt Lösungsansätzen benennen.

Das hilft möglicherweise bei Update KB4474419

Behält man die obige Information im Hinterkopf, kommt man möglicherweise auch bei Update KB4474419 der Lösung näher. Nachfolgend habe ich mal einige Fundstellen aufgeführt, die das bestätigen:

  • In diesen Thread auf Dr. Windows zum Problem kommt die klare Aussage: Ich habe das Problem gestern bei mir lösen können! Das update läuft nicht durch wenn ein “alternativer bootloader” benutzt wird! Der Nutzer verweist auf meinen SHA-2-Artikel bei heise (siehe folgender Punkt).
  • Im heise-Beitrag hatte ich geschrieben: Inzwischen hat sich in einem englischen Microsoft-Forenthread eine mögliche Ursache herauskristallisiert. Die Update-Installation scheitert, wenn ein fremder Bootlader (etwa Linux GRUB2, der auf eine Linux-Partition zeigt) vorhanden ist. Nach Entfernen des Bootladers oder ‘abklemmen’ des Linux-Laufwerks lässt sich das Update dann erfolgreich installieren.
  • Auch in diesem Kommentar auf meinen heise-Artikel gibt es einen Hinweis: Es reicht die Windowsplatte als erstes Bootmedium im Bios zu setzen. Danach lief bei mir das Update durch.

Aus dem weiter oben zitierten heise-Beitrag aus 2015 möchte ich zudem auf diesem Kommentar verweisen. Die Aussage: Es muss für die Windows Boot Partition das ‘boot’-Flag gesetzt sein, damit es funktioniert. Das lässt sich mit Partitionierungswerkzeugen bewerkstelligen.

Weitere Ursachen für die Bootschleife kann auch installierte Software sein, die den Bootlader von Windows 7 manipuliert. Aus dem hohlen Bauch fallen mir das Acronis sowie das frühere TrueCrypt (heute VeraCryt) ein – ob es zutrifft, weiß ich nicht. Hier wird Syslinux als Bootlader genannt. Abschließende Frage: Ist überhaupt noch jemand von diesem Problem betroffen?

Ähnliche Artikel
SHA-2-Patch für Windows 7 kommt wohl im März 2019
Knipst der Wechsel zu SHA-2 “das Web” aus?
Windows 7: Ab April 2019 wird ein ‘SHA-2-Update’ benötigt
Windows 7: Updates rüsten SHA-2-Support nach
Microsoft Security Update Releases/Revisionen Mai 2019


Anzeige
Dieser Beitrag wurde unter Update, Windows 7 abgelegt und mit , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

14 Responses to Bekommen Windows 7-Nutzer ein SHA-2-Update Problem?

  1. Karl Wester-Ebbinghaus (@tweet_alqamar) sagt:

    Hallo Günter, Acronis Trueimage verändert die Bootreihenfolge nur dann, wenn die recht selten genutzte Try and Decide Funktion genutzt wird, die sich eigene Partitionen anlegt.

  2. ID sagt:

    Heute ab 19 Uhr wird sich zeigen ;-)

  3. Werbung

  4. Hans Thölen sagt:

    Windows 7 Home Premium Service Pack 1 32 Bit.
    Bei mir sind die Updates KB4474419 und KB4490628 in der Liste ” Installierte
    Updates ” vorhanden. Bekomme ich trotzdem Probleme mit neuen Updates ?

  5. Robert sagt:

    Hier laufen mehrere Maschinen mit Windows 7 64BIT im Double Boot mit Linux Mint. Allerdings ist der bevorzugte Bootloader der von Windows. Grub kommt erst an 2. Stelle. Installiert sind auch die SHA-2 Updates KB4474419 und KB4490628. Ich hatte bisher keinerlei Probleme. Sollte ich trotzdem noch auf was achten oder bin ich da auf der sicheren Seite?

  6. Volko sagt:

    Betrifft 64-Bit Dual-Boot Systeme genauso … kann ich aus eigener Erfahrung bestätigen: Linux Mint 19 64-Bit und Windows 7 Prof. 64-Bit auf jeweils eigener SSD; primäres Bootdevice mit Bootmanager GRUB ist die Linux SSD … Erfolgreiche Installation des vorgenannten Updates erfordert die temporäre Festlegung der Windows SSD als primäres Bootdevice im BIOS.

    • Bernard sagt:

      In so einem Fall ist GRUB doch völlig überflüssig.

      Einfach beim Systemstart über einen BIOS-Befehl (F9, F12 oder ESC) die zu startende Festplatte auswählen.

      Da ist jeder Software-Boot-Manager überflüssig. Das UEFI-BIOS regelt das.

      • Volko sagt:

        Kann man natürlich auch so machen … persönlich bevorzuge ich aber die Lösung mit Grub, weil ich es einfach komfortabler finde.
        Ist schlicht eine reine Geschmacksfrage und daher nicht als Gegenstand einer kontroversen Diskussion geeignet.

      • Robert sagt:

        Du hast für jedes OS eine eigene SSD. Ich habe leider nur jeweils 1 SSD mit 2 Partitionen. Hab die 2 Betriebssysteme auf der einen Platte und habe nicht die Möglichkeit im BIOS zu wählen welche ich nehmen soll so wie Du sagst.

        • Volko sagt:

          So wie es scheint, besteht das Problem nicht wenn Linux und Windows wie bei Dir auf demselben Datenträger in eigenen Partitionen liegen … andernfalls wäre die Installation der besagten Updates bei Dir nicht erfolgreich durchgelaufen … dementsprechend bist Du auf der sicheren Seite.

  7. Sebastian sagt:

    Hallo,

    also bei uns in der Firma alles normal
    x86 und x64 Windows 7 SP1 Pro

    Schönen Patchday noch!

  8. Werbung

  9. Sebastian sagt:

    Hallo zusammen,

    wir haben nun einen alten PC “ausgegraben” der schon seit August 18 nicht mehr im Netz war.
    Um Updates zu bekommen, müsste ich nun folgende Updates manuell vorher installieren wenn ich richtig liege?

    1. kb4490628 SSU
    2. kb4489878 Rollup März 2017
    3. kb4474419 SHA2 Patch

    Stimmt das so oder muss ich was anders machen?

    Besten Dank

Schreibe einen Kommentar

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