[English]Zum 12. November 2024 hat Microsoft wohl Sicherheitsupdates für Windows Server 2008 R2 herausgegeben. Wer diese Updates installieren ließ, musste anschließend feststellen, dass die älteren Browser, die auf diesen Maschinen bisher genutzt werden konnten, nicht mehr funktionieren. Es gibt inzwischen aber einen Workaround, um wieder einen Browser zum Laufen zu bringen. Ist aber eher ein Exoten-Problem, da wohl nur noch wenige Windows Server 2008 R2 laufen dürften.
Anzeige
Windows 7/Server 2008 R2 sind EOL
Windows 7 ist längst aus dem Support gefallen, und auch Windows Server 2008 R2 bekommt seit Januar 2024 auch keinen Extended Security Update (ESU) Support mehr (siehe auch Windows Server 2008 R2 bekommt ESU-Support bis 9. Januar 2024). Andererseits war Windows Embedded POSReady 7 noch bis zum 24. Oktober 2024 im Support (siehe).
Aber es gibt von Microsoft immer noch Sicherheitsupdates für Windows Server 2008 R2. Einige Nutzer von Windows 7 haben dann die Sicherheitsupdates von Windows Embedded POSReady 7 verwendet, um Sicherheitslücken auf ihren Betriebssystemen zu patchen und diese weiter zu betreiben.
Browser fallen aus dem Support
Google hat auf Grund des Lebensendes den Support für seinen Chromium-Browser für Windows 7 SP1 und Windows 8.1 sowie die Server-Pendants im Januar 2023 mit der Version 109 beendet. Ich hatte im Blog-Beitrag Windows 7/8.1: Google beendet den Support im Februar 2023, Edge auch betroffen auf diesen Sachverhalt hingewiesen.
Damit fallen auch alle auf Chromium basierenden Browser, wie der Microsoft Edge, in höheren Versionen für diese Betriebssysteme aus. Lediglich für Windows Server 2012 R2 haben Microsoft und Google zugesagt, Sicherheitsupdate für den Google Chrome / Edge 109 bereitzustellen. Und es gibt noch den Firefox, dessen Entwickler den Browser unter Windows 7 noch bis zum 3. Quartal 2024 unterstützen wollten (siehe Windows 7/8.1: Firefox gewährt Support bis mind. 3. Q. 2024). So weit zur Vorgeschichte.
Sicherheitsupdates legen Browser lahm
Für mich überraschend scheint es zum Patchday, November 2024, doch noch Updates für Windows Embedded POSReady 7 und Windows Server 2008 / R2 gegeben zu haben. Zum Beitrag Patchday: Windows Server 2012 / R2 und Windows 7 (12. November 2024) hat sich R.S. mit diesem Kommentar gemeldet. Er schrieb, dass es für Windows Server 2008 R2 auch noch ein Update für den Internet Explorer (KB5046630) und ein Update für .NET (KB5046543) gebe – hatte ich hier im Blog nicht mehr thematisiert. Die Updates für Windows Server 2008 R2 lassen sich auch bei Windows 7 installieren.
Anzeige
Dann hat sich Bolko mit diesem Kommentar gemeldet, und fragt, ob die Browser nach Installation der Updates noch funktionieren. Ein weiterer Nutzer kommentiert hier: "Alle Legacy Browser sind mit dem Update, unter Windows 7 und 2008 R2, kaputt." Er hat es in einer virtuellen Maschine getestet, Chrome 109, Edge 109, Firefox ESR 115, Opera 95 funktionieren nicht mehr.
Es kristallisiert sich aber heraus, dass das Internet Explorer Update KB5046630 nicht die Ursache ist. Leser Trillian schreibt, dass die Update KB5046705 als auch KB5046687 (im Microsoft Update Catalog für Windows Server 2008 R2 erhältlich) unter Windows Server 2008 R2 (und wohl unter Windows 7) die alten Browser unbenutzbar machen.
Ein schmutziger Workaround
Bolko hat in diesem Kommentar die Datei Win32k.sys als Ursache angegeben. Wer vom Exoten-Problem betroffen ist (es dürften nur noch wenige der Altsysteme laufen), kann den von Bolko in diesem Kommentar skizzierten Workaround verwenden.
Nach dem Abschalten des Integritätscheck und der Treibersignaturprüfung über BCDEdit kann die Datei Win32k.sys aus einem alten Backup vor den November 2024-Updates verwendet werden, um die im November 2024 gepatchte Version zu ersetzen.
Ähnliche Artikel:
Browser-Ärger I: Edge will erneut Google Chrome-Tabs importieren (Nov. 2024)
Browser-Ärger II: Nov. 2024-Updates für Server 2008/R2 legen ältere Browser lahm
Anzeige
Technischer Hinweis: "Weiterlesen" ist auch hier in die Folgeüberschrift gerutscht.
Danke! Erklärung zum Hintergrund: Es scheint eine Eigenart des klassischen WordPress-Editors zu sein, dass er mir den more-Tag beim Einfügen mit Folgetags verhackstückt. Früher habe ich mit dem Windows Live Writer (WLW) gebloggt – da kam das praktisch nicht vor. Seit dem Blog-Umzug auf all-incl.com habe ich meinen Workflow so umgestellt, dass ich direkt in WordPress im Classic-Editor (mit Erweiterungen) bloggen kann (der WLW funktioniert in der neuen Konstellation nicht mehr – und ich kann auch unter Linux bloggen).
Mir fällt der verunglückte more-H2-Tag meist nicht auf, weil ich mir selten die Startseite des Blogs mit den Kurzfassungen der Beiträge ansehe – ich arbeite im WordPress-Dashboard und schaue mir nur die finalen Beiträge an. Von daher bin ich froh, wenn dieser Fehler gemeldet wird – ich korrigiere und lösche danach den Kommentar.
Workflow im Classic Editor: Cursor direkt nach den letzten Punkt des erstes Absatzes setzen, dann per Button "Weiterlesen" einfügen.
Du bloggst sehr viel? Theoretisch hast Du Recht – kann man so machen – und ist auch der normale Workflow -> "Artikelbild per Plugin einfügen, Anreißertext möglichst verfassen, more-Tag einfügen und weiterschreiben". Und wenn ich mir den HTML-Code auf dem Tab "Text" anschaue, sehe ich auch das Malheur.
Nur entstehen bei mir Blog-Beiträge nicht nach der reinen Lehre der Art "wat is ene Dampfmaschine". Da wird ein Text vom Scratch geschrieben, ich stelle Absätze um, mir fällt ein "Oh, am Anfang könnte noch ein Titel stehen", damit es ggf. mit weiteren Überschriften passt, und dann geht der Text raus. Manchmal ändere ich auch noch was nach dem Publizieren, und schon ist das Malheur passiert. Ich müsste nach jeder Änderung am Artikelanfang den HTML-Code kontrollieren – da ich noch auf andere Sachen zu achten habe, ist das eher unrealistisch. Das Problem fällt mir i.d.R. nur auf, wenn ein Nutzer das dann anmerkt. Ich sehe bei 5-10 Blog-Beiträgen / Tag auch keine wirkliche Alternative.
Firefox 115 ESR soll laut Mozilla noch bis mindestens März 2025 Updates bekommen.
Der Waterfox leider nicht. Der basiert ja eigentlich auf den ESR-Versionen von Firefox und war sonst immer konservativ beim Übernehmen von Mozilla-Spinnereien. Nun aber ist er alternativlos auf Version 128 umgestiegen und präsentiert seit dieser Woche unter Win7 ein Warnsymbol „Update nicht möglich – System nicht kompatibel". Verlinkt auf eine „404 Page not found"-Adresse.
Ärgerliche Voreiligkeit des Entwicklers (der zugleich versäumt hat, den eingebauten Feedback-Link so zu ändern, dass Feedback ihn erreicht und nicht Mozilla).
Solchen Leuten gönnt man Windows 11.
Moin Herr Born!
Mozilla hat den Support für den Firefox 115 ESR unter Windows 7/8 bis bis März 2025 verlängert:
"We decided to extend support for ESR 115 only on Windows 7-8.1 and macOS 10.12-10.14 up to March 2025. We will re-evaluate this decision in early 2025 and announce any updates on ESR 115's end-of-life then."
Quelle: https://whattrainisitnow.com/release/?version=esr
Noch zwei kleine Ergänzungen:
Die Updates für Windows Server 2008 R2 funktionieren nur bei den 64-bit Windows-7-Versionen.
Via Premium Assurance gibt es für Windows Server 2008 R2 verlängerten Support bis Januar 2026. Theoretisch/praktisch ließen sich darüber ebenso Windows-7-x64-Versionen bis Januar 2026 patchen…
Danke für die Ergänzungen – wusste im Hinterkopf "da war noch was", habe aber auf die Schnelle nichts bei einer Suche gefunden.
Das mit den 64bit ist logisch, da es Server 2008R2 nicht als 32bit-Version gibt.
Der Workaround ist wirklich schmutzig, da er damit das Sicherheitsupdate aushebelt und damit geschlossene Lücken wieder aufreißt.
Auf Servern ist das Nichtfunktionieren der Browser ein kleineres Problem, denn auf Servern sollte grundsätzlich kein Browser installiert sein.
Das Problem entsteht nur, wenn man die Serverupdates auch für Windows 7 nutzt.
Da das aber von Microsoft so nicht vorgesehen ist, ist es nicht unwahrscheinlich, das es da keinen Fix von Microsoft geben wird.
Moin R.S.!
Windows 'Server 2008 R2 eingerichtet als Terminalserver für den Internetzugang von Clients benötigt sehr wohl eine funktionierende Browserlösung. Und da auch die unter Windows Server 2008 R2 lauffähige Edge-Version davon betroffen ist, ist es eventuell doch nicht so unwahrscheinlich, dass Microsoft da einen Fix anbieten wird… (Just My Cent! ^^)
Alte Browser ist gut.
Das Update blockiert Firefox 115.17.0esr *und* der Edge 11(?). Was interessanterweise nicht blockiert ist der *uralte* MS-IE!
Auch die HTML Darstellung in Thunderbird läuft ohne Probleme.
An der Stelle bleibt dann die Deinstallation des kompletten 400 MB KB.
Das Problem liegt an der Sandbox der Browser.
Bei der Initialisierung bekommt die Sandbox keinen Speicher (STATUS_NO_MEMORY).
Das Kernel-Modul win32k.sys soll wohl direkte Systemaufrufe durch die user32 dll und gdi32.dll abblocken.
Das alte ungoogled Chromium 109.0.5414.120 und SRWare Iron 109.0.5550.0 funktionieren, aber es ist noch nicht klar, warum.
So wird das Problem immer weiter eingegrenzt.
Alternativen zum schmutzigen Hack, indem man die Sandbox abschaltet oder die Sandbox-Sicherheit reduziert:
Supermium (Chromium) wird mit Parameter
–no-sandbox
gestartet.
Firefox wird mit geänderter Umgebungsvariable zur Reduzierung der Sandbox-Sicherheit per Konsolenbefehl gestartet:
C:\Windows\System32\cmd.exe /c "set MOZ_DISABLE_CONTENT_SANDBOX=1 && start firefox"
2.Möglichkeit für Firefox:
in einer Batch (firefox_ohne_Sandbox.cmd):
set MOZ_DISABLE_CONTENT_SANDBOX=1
set MOZ_DISABLE_GMP_SANDBOX=1
set MOZ_DISABLE_GPU_SANDBOX=1
set MOZ_DISABLE_NPAPI_SANDBOX=1
set MOZ_DISABLE_RDD_SANDBOX=1
set MOZ_DISABLE_SOCKET_PROCESS_SANDBOX=1
firefox.exe
3.Möglichkeit für Firefox:
Man kann beim Firefox auch im Profil-Ordner die Datei prefs.js öffnen und am Ende die Zeile hinzufügen, um die Sandbox-Sicherheit auf niedrigste Stufe einzustellen:
user_pref("security.sandbox.content.level", 1);
Alternativer Weg zur 3ten Möglichkeit für Firefox:
* Man öffnet den Konfigurationseditor von Firefox („about:config")
* security.sandbox.content.level in die Suchzeile eingeben
* Den voreingestellen Level-Wert von 6 auf 1 ändern und speichern
* Neustart
*Done
Cave: Dieser Weg funktioniert natürlich nur wenn man KB5046705 oder KB5046687 noch nicht (!) installiert hat.
Gerade eines Besseren belehrt worden: Das Aufrufen des Konfigurationseditors funktioniert unabhänging von eingestellten Sandbox-Sicherheits-Level!
Daher meine Bitte an Herrn Born: Diese Antwort und die Vorherige (16. November 2024 um 16:01 Uhr) löschen… Thx!
Gerade ein wenig mit dem Firefox Workarount nach Installation von KB5046705 herumgespielt:
Sandbox-Sicherheitslevevel 1 – 4: Keine Probleme
Erst ab Level 5 stürzen beim Browserstart die Tab`s mit der entsprechenden Fehlermeldung ab…
Also ist im Moment Best Practice, den Level auf 4 zu setzen.
r3dfox = aktueller ESR-Firefox für alte Systeme (angeblich bis Windows XP) hat keine Probleme mit dem Patch. Falls jemand nicht mit der config oder mit Parametern herumspielen möchte.
github.com/Eclipse-Community/r3dfox
Moin @ All!
In der Zwischenzeit hat Microsoft die Probleme mit KB5046705 / KB5046687 bestätigt.
Der Fix erfolgt mit den Dezember-Updates.
Link: https://answers.microsoft.com/en-us/windows/forum/all/kb5046687-on-windows-nt-61-seems-to-brick-firefox/5f27b88c-63f6-44a2-9ff3-da3d79cf57df