Besitzer 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.

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.

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?