[English]Das riecht nach Ärger für Administratoren in Unternehmensumgebungen, wo der Edge-Browser i.d.R. zum Einsatz kommt. Ein Blog-Leser hat mich darüber informiert, dass der Edge sich auf die Version 125.0.2535.67 aktualisiert habe, obwohl das im WSUS definitiv nicht freigegeben ist. Ich stelle mal einige Informationen zum Fall zusammen, verbunden mit der Frage, ob das bei der Blog-Leserschaft beobachtet wurde bzw. bekannt ist.
Anzeige
Edge 125.0.2535.67
Vor einigen Tagen (24. Mai 2024) hat Microsoft den Edge 125.0.2535.67 im Stable Channel freigegeben. In diesem Update wurden verschiedene Bugs und Leistungsprobleme behoben. So wurde ein Browserabsturz behoben, der beim Versuch auftrat, aus einer Dropdown-Liste mit einer großen Anzahl von Optionen auszuwählen.
Zudem hat Microsoft einen Fix für CVE-2024-5274 für Microsoft Edge Stable Channel (Version 125.0.2535.67) integriert, der vom Chromium-Team als Exploit in freier Wildbahn gemeldet wurde. Es handelt sich um einen Type Confusion-Bug in der V8 JavaScript-Engine von Chrome.
Microsoft weist zudem darauf hin, dass die Erweiterung Microsoft Defender Application Guard (MDAG) veraltet ist. Da Application Guard veraltet ist, wird es keine Migration zu Edge Manifest V3 geben. Die entsprechenden Erweiterungen und die zugehörige Windows Store-App werden nach Mai 2024 nicht mehr verfügbar sein. Betroffen sind MDAG für Chrome und Firefox. Microsoft gibt aber Hinweise, wie Unternehmen die Browser-Umgebung per AppLocker-Richtlinien oder mit dem Microsoft Edge-Verwaltungsdiensts absichern können.
Update am WSUS vorbei!
Blog-Leser Joachim T. hat sich zum 28. Mai 2024 per Mail gemeldet und wies darauf hin, dass der Edge am WSUS vorbei auf die Version 125.0.2535.67 aktualisiert worden sei (siehe folgenden Screenshot der Updates). Der Leser schrieb:
Anzeige
Vielleicht interessant für das Blog: Edge 125.0.2535.67 hat sich eben auf unseren Clients automatisch installiert, ohne Freigabe auf WSUS. Es ist nicht mal verfügbar auf WUS zur Freigabe!
Wir verwalten Edge per WSUS bisher ohne Probleme. Freigegeben ist 125.0.2535.51
Installierte Updates, Zum Vergrößern klicken
Als Beleg hat der Leser dann noch einen Screenshot des WSUS mitgeliefert, der einerseits zeigt, dass kein Edge-Browser zur Auslieferung "approved", also freigegeben wurde. Der Edge 125.0.2535.67 ist nicht mal im WSUS aufgeführt.
Edge im WSUS, Zum Vergrößern klicken
Der Leser schreibt dazu: "Der letzte WSUS Sync war heute [28.5.2024] 12:14 (nur zwei Security Intelligence Updates). Es sind keine unapproved/failed or needed Updates vorhanden. Unter unapproved/any sieht das so aus, also auch nichts Interessantes".
Approved Updates im WSUS, Zum Vergrößern klicken
Trotzdem wurde zum 28. Mai 2028, laut Leser, plötzlich auf allen Windows 10 Pro Clients der Edge-Browser auf Version 125.0.2535.67 aktualisiert.
Edge-Update, Zum Vergrößern klicken
Joachim schreibt dazu: "Das hatten wir bisher noch nie und könnte auch für andere Admins von Interesse sein." Keine Ahnung, ob das zutrifft, aber der Edge hat die Möglichkeit, Updates selbsttätig am WSUS vorbei zu beziehen. Bereits im Oktober 2020 fragt jemand in diesem Q&A-Beitrag, ob es die Möglichkeit gibt, Edge-Updates ausschließlich per WSUS auszuliefern. Dort lautet die Antwort, dass unter Windows die Edge-Updates per GPO deaktiviert sein müssen.
Anzeige
Provided as is: learn.microsoft.com/en-us/windows/deployment/update/wufb-wsus
Bei mir geht schon sehr lange Zeit die Edge Updaterei am WSUS vorbei, da ich den Autoupdater bei den Clients nicht per GPO deaktiert habe. Hatte aber bisher keinerlei Probleme mit den Edge Updates.
So long
Yumper
.67 ist seit heute Nacht per WSUS verfügbar.
Naja, um das abschließend bewerten zu können, müsste man noch die Konfig auf den Clients kennen. Vielleicht hat sich da warum auch immer ein Fehler in den GPOs eingeschlichen. Weil prinzipiell könnte man den Edge schon so konfigurieren, dass er sich die Updates nicht vom WSUS zieht, sondern das AutoUpdate direkt ins Internet geht.
Die GPOs sind korrekt konfiguriert, ich hatte ja auch erwähnt, dass es bisher nicht vorgekommen ist, dass Edge sich selbständig updatet, da nur das Update per WSUS per GPOs erlaubt wurde.
Das kann ich bestätigen, Update am WSUS vorbei. Sauerei.
@Pau1
Entdeckt habe ich heute einen Eintrag "Microsoft EdgeUpdate Policies" der auf nicht konfiguriert steht. Ist mir so noch nie aufgefallen. Das ist also wie mit dem Suchfeld in WIN 10, ein Update schaltet es einfach ein (und fragt ob es so bleiben soll). Wenn man also nicht ständig die GPO-Änderungen beobachtet, jubeln einem die Narren aus Redmond immer wieder mal was unter. Wobei die Narren sind eigentlich wir, die das Zeug von denen noch nutzen.
Danke für den Hinweis :)
Könntest Du uns bitte den genauen Pfad in den GPOs zu diesem Setting sagen? Ich finde das leider nicht bei uns und MS hat dazu auch keine Info: https://learn.microsoft.com/en-us/deployedge/microsoft-edge-policies & https://learn.microsoft.com/en-us/deployedge/microsoft-edge-update-policies
Danke :)
Hast Du die administrativen Vorlagen denn überhaupt installiert und im AD verteilt?
https://www.microsoft.com/de-de/edge/business/download
Die sind *nicht* out-of-the-box vorhanden!
Ja natürlich sind die ADMX am aktuellen Stand und per Sysvol verteilt. Eine Antwort auf meine Frage wäre aber hilfreicher, als mir etwas zu unterstellen ;)
>>> Ja natürlich sind die ADMX am aktuellen Stand und per Sysvol verteilt.
Nicht wirklich. Wo habt ihr die denn her?
Sauerei? Lieber froh sein, dass man mit dem Update nicht mehr von CVE-2024-5274 gehackt werden kann. Das wäre nämlich wirklich eine Sauerei.
Sorry aber als Admin ist es doch sowieso Pflicht nach jedem Update gewissenhaft zu kontrollieren und nicht erst ab Windows 10/11. Da zeigt sich halt mal wieder wie gewissenhaft manche ihre Arbeit machen!
heute nachts ist diese Version und auch die neue extended stable 124.0.2478.121 im WSUS eingetrudelt. Ansonsten ist es, wie die Vorredner schreiben: das lässt sich per GPO alles einstellen.
Trotzdem ist es eigenartig, dass das, wie auch über Winget, erst gestern freigegeben wurde.
Fachkräftemangel wahrscheinlich.
und darüber hinaus eine Art OOB Sicherheitsupdates für Dotnet als 6.0.31, 7.0.20 und 8.06
Finde die Stelle nicht, eigentlich gar nichts mit WSUS, habt ihr einen Tip für mich? Computerkonfiguration>Richtlinien>Adminstative Vorlagen>Microsoft Edge-Update
Es gibt keine "WSUS" Einstellung für den Edge.
Per Default zieht der Edge selbst (ohne Windows Update) sich die Updates direkt das war schon immer so beim Edge, genauso wie beim Chrome und FF und…..
Das selbst Update kannst du per Edge GPO abschalten. Dann bekommt der Edge erstmal überhaupt keine Updates mehr, denn es gibt keine Edge Update per WU/MU,
diese gibt es nur über WSUS, sofern dort freigeben und Windows selbst (nicht der Edge) so konfiguriert ist das Windows sich die Updates vom WSUS holt.
https://admx.help/?Category=EdgeChromium&Policy=Microsoft.Policies.Update::Pol_UpdatePolicyMicrosoftEdge&Language=de-de
Danke euch!
Bei den Servern klappt ja auch das Verteilen der Edge-Updates, nur bei den Clients nicht.
Microsoft Edge Update/Applications/Microsoft Edge & Microsoft Edge Update/Microsoft Edge WebView2 Runtime:
Update policy override: Updates disabled
Microsoft Edge Update/Preferences
Auto-update check period override: Enabled
Minutes between update checks: 60
Diese Einstellungen nur für Clients zum Forcen eines Updates
Microsoft Edge
Notify a user that a browser restart is recommended or required for pending updates: Enabled
Notify a user that a browser restart is recommended or required for pending updates Required – Show a recurring prompt to the user indicating that a restart is required
Set the time period for update notifications: Enabled
Set the time period for update notifications: 3600000
Und im WSUS den Edge als Produkt hinzufügen. Damit konnte ich bisher steuern, dass Updates nur per WSUS kommen. Clients und Server haben die selben Settings und bei den Servern wurde auch nichts automatisch installiert, nur bei den Windows 10 Clients.
Bedenken sollte man aber, dass Edge-Updates via WSUS alleine schon von MS später zum WSUS kommen (selbst man man selbigen maximal, d. h. stündlich, syncen würde.
Je seltener man zudem den Sync fährt, desto später kämen dann die Updates über WSUS bei den Clients an.
Also in meinem WSUS taucht das fragliche Update auf und läßt sich genehmigen/ablehnen.
"Keine Ahnung, ob das zutrifft, aber der Edge hat die Möglichkeit, Updates selbsttätig am WSUS vorbei zu beziehen."
Definitiv ja! Gilt aber auch für andere Produkte (Chrome etc.) – du mußt die Konfiguration auch für den Updater der jeweiligen Anwendung konfigurieren (Gruppenrichtlinien -> Administrative Vorlagen).
Dies wäre ein passabler Start für den Fragesuchenden:
https://learn.microsoft.com/de-de/deployedge/configure-microsoft-edge#2-set-mandatory-or-recommended-policies
Danke für den Hinweis. Zu: "Definitiv ja! Gilt aber auch für andere Produkte (Chrome etc.) – du musst die Konfiguration auch für den Updater der jeweiligen Anwendung konfigurieren (Gruppenrichtlinien -> Administrative Vorlagen)."
Zeigt imho, wie kaputt das Ganze für den kritischen Beobachter ist! Vielleicht sehe ich es zu blauäugig, aber es gehört eine GPO-Einstellung auf die Clients "Alle Updates per WSUS ziehen" und gut ist. Aktuell sieht es für mich so aus, dass der Administrator für jede Fuzzi-Anwendung (also Chrome, Edge, Teams …) schauen darf, ob es eine GPO gibt, hoffen, dass diese funktioniert (und nicht per Update deaktiviert wird) und er diese auch korrekt konfiguriert hat.
Jetzt verstehst Du vielleicht, warum ich jedes mal maule, wenn die Browser-Pupsis ein neues Major-Release rausbringen (nur, um die erste Zahl zu pushen).
Denn das bedeutet jedes mal eine NEUE Gruppen-Richtlinie, damit es nicht unübersichtlich wird und die administrativen Vorlagen nicht inkompatibel werden.
Ja, es ist kaputt. Einerseits gut, andererseits aber eben viel Fummel-Kram, den man ständig im Auge behalten muß.
Wäre cool, wenn wirklich alle installierten Programme "Alle Updates per WSUS ziehen" würden. Das ist aber auf einem Windows-System normalerweise nicht der Fall. Denn kein Dritthersteller liefert an Microsoft entsprechende WSUS-Pakete.
Aber man kann sich behelfen… Hatte ich schonmal beschrieben, muss mich ja nicht wiederholen…
Ich bin da so nicht bewandert – aber lassen sich die Installer für die Updates nicht vom Software-Entwickler herunterladen und dann im WSUS importieren? Ich erinnere mich dunkel, so etwas für den Microsoft Software-Zoo mal beschrieben zu haben (ging im IE und im Edge mit Kniffen).
O365 Updates kommen – anders als ein "klassisches Office (z. B. 2019)" beispielsweise nicht via WSUS. Das Geht entweder direkt via MS oder via Fileshare oder eben dann via SCCM/Softwareverteilung.
Mittels Drittanbieter-Tool, könnte man eine WSUS etwas "aufbohren" -> ist aber auch nix allumfassendes.
WSUS geht ein bisschen. Mit MECM und Drittanbieter-Plugin hinter dem WSUS geht alles, automatischer Download der Updates von den Herstellerseiten, automatische Packetierung, bereitstellen auf dem WSUS, Updateinstallation. Hab ich hier im Blog schon beschrieben, ich wiederhole mich da aber nicht gerne.
Ist das nicht genau eine der Aufgaben für die ein Admin da ist ?
;-P
Normal sollte das doch so laufen das jedes Update bevor es ins Produktivsystem eingespielt wird auf Herz und Nieren getestet wird… das impliziert auch das alle anderen Update Möglichkeiten ausgeschaltet sind! Das gilt für Windows selbst und für jedes Programm das auf dem Rechnern läuft.
Was machen die Admins da? Eier schauckeln?
Genau deswegen wollen wir das ja per WSUS verteilen und nicht einfach so. Damit man es vorher testen kann.
Und ihr patcht den Edge wirklich via WSUS?
Für Chromium Browser kommen doch täglich Updates.
Da kann man doch höchstens wöchentlich nach ziehen, sonst ist man ja täglich damit beschäftigt.
Wir patchen Edge über den integrierten automatischen Updater.
Da gab es nie ein Problem. Wenn doch, dreht man via GPO die forcierte Version zurück. Mussten wir mal bei Chrome machen.
Wir müssen das per WSUS machen. Vor kurzem gab es das Problem, dass eine Edge-Version eine defekte WebView-Komponente mitgebracht hat, wo dan Plugins in Outlook nicht mehr funktioniert haben. Ja, man kann per GPO die Version zurückdrehen, aber das benötigt einen Restart. Nicht lustig bei Session Hosts einer RDS Farm.
Da muss man proaktiv arbeiten, nicht reaktiv.
Da nutzt man die Versionierung eines Citrix-Provisioning-Servers…
Es sind bei uns nur wenige Maschinen, die das Update über den WSUS ziehen, allerdings habe ich nie nachvollzogen, warum dem so ist. Ich vermute, es sind nur die Upgrade-Installationen, auf die der Edge einst nachträglich installiert wurde und die alten GPOs nachwirken.
oder weil das SelbstUpdate des Edge einfach schneller war.
Wir verteilen den Edge gesteuert über unsere Software-Verteilung (per WSUS nur für Server). Im WSUS habe ich den Edge nicht als Produkt aboniert, ich importiere ihn (und sein Zwilling WebView2) manuell über den Microsoft Update Catalog. Gestern war Edge/WebView2 Version .67 definitiv nicht im Update Catalog verfügbar. Den Autoupdater habe ich per GPO deaktiviert (wie auch beim Chrome, Firefox ESR) und zusätzlich die Scheduled Tasks der Updater gelöscht/deaktiviert. Einerseits kommen die Clients eh nicht direkt nach draussen und andererseit nutzen wir zu 95% Clients mit einem "Golden Image", was soll da ein Autoupdater? Den Autoupdater per GPO allein zu deaktivieren, hat damals beim Chrome nach meiner Erfahrung "irgendwie" nicht gereicht. Bis vor wenigen Versionen vom Chrome wurde der Autoupdater auch angetriggert, wenn man sich die installierte Version anzeigen lassen wollte (Drei Punkte Menü, Hilfe, Über Google Chrome). Dann sprang sofort ein UAC Prompt an, der Autoupdater war per GPO deaktiviert. Das hat der Edge nach meiner Beobachtung nie gemacht. Alles nur noch Murks…
Wir haben die Autoupdater zusätzlich per Applocker/Antivirus Application Control gesperrt und verteilen diese Updates per Deployment.
Du importierst mehrfach pro Woche / pro Monat manuell Updates, welche entweder per Auto-Update kämen oder per Sync am WSUS eintrudeln würden?
Hui, die Zeit hat man bei uns nicht (mehr).
Sync doch die Updates automatisch in den WSUS rein -> wenn Du manuell die Kontrolle behalten willst oder musst, kann man ja die Updates am WSUS auch manuell freigeben (alleine das kann ggf. schon aufwändig werden).
Exakt :)
WSUS ist ein gutes kostenloses Werkzeug, wenn man weiß, wie man ihn nutzt. Manuelle Freigaben, Testgruppen, alles kein Problem.
Wenn MS dann aber GPOs ignoriert und mir unter der Hand Edge updatet, dann ist das nicht lustig.
Auto-Update verträgt sich technisch nicht wirklich mit Citrix MCS/PVS aka "Golden Image", zudem gibt es Branchen, die sich aufgrund der Regulatorik auch nicht mit "Auto-Update" vertragen. Da möchte man schon wissen, welche Versionen produktiv im Einsatz sind (und sei es auch nur für die Prüfer).
Prüft ihr denn auch immer schön alle vier Wochen (bei einem Major Release vom Chrome/Edge/WebView2) die zugrundeliegenden ADMX-Vorlagen, wie es das BSI in seinen Mindestanforderungen vorsieht? ;)
Da ist der zeitliche Aufwand, die Browser mal eben per Softwareverteilung systematisch zu verteilen, eher als gering zu betrachten (und das nervt schon gewaltig, Chromium-Browser waren im Mai mit 3 Zero-Day dabei, das hat Macromedia/Adobe Flash nie geschafft).
Apropos WSUS — Quizzfrage: Ganz so einfach machte es MS einem mit dem Ding nicht. Wie lautet denn zum Beispiel das zu abonnierende Produkt für "Windows Server 2022 LTSC"?
Das meine Damen und Herren ist Grund, seine Terminalserver bzw Windows Clients (sofern noch vorhanden) OFFLINE(!) zu betreiben. Einzige Anwendung mit hinterlegtem Proxy ist der Firefox. Einzige Windows VM, die im Proxy raus darf ist der WSUS.
https://blog.jakobs.systems/blog/20240506-service-tips-windows/
Genau so geht es! Ok… Das Software-Deployment darf sich auch die Updates automatisch von den jeweiligen Herstellern ziehen. Aber sonst ist idealerweise Funkstille.