none
Spectre und Meltdown Sicherheitsupdate dauerhaft ablehnen RRS feed

  • Frage

  • Hi Community,

    die Fachliteratur überschlägt sich zZ ja mit gut gemeinten Ratschlägen bzgl. dem Handling der Meltdown und Spectre Sicherheitslücke. Ein durchaus ernst gemeinter Tipp war, dass man im Serverbereich durchaus zwischen Sicherheitsrisikopotential und möglichen Performanceverlust abwägen kann. Die Abwägung würde bei uns für die Datenbankserver zZ zugunsten eines vernachlässigbaren Risikopotentials tendieren. Diese Server bedienen nur lokale Clients und haben selbst keinen Link ins Internet und stellen schon gar keine öffentlich erreichbare Dienste zur Verfügung, dafür wäre der zu erwartende Performanceverlust uU erheblich, da die Server eh schon zu den höher belasteten gehören.

    Soweit so gut aber da wäre zB das Update KB4056890, welches für Server 2016 abgestellt wurde. Dieses Update ist ein kumulatives Update, dass bedeutet ich kann es langfristig gar nicht erfolgreich ablehnen. Hingegen wird das Update KB4056890, abgestellt für Server 2012R2, nicht explizit als kumulativ beschrieben, kann also vermutlich erfolgreich abgelehnt werden, Klarheit haben wir aber weder noch. In den Beschreibungen beider Updates wird das Schließen dieser bestimmten Sicherheitslücke beschrieben...

    Gibt es einen Workaround, wie man auf das Schließen dieser Sicherheitslücke explizit verzichten kann, ohne auch zukünftig auf Sicherheitsupdates zu verzichten?

    Thx & Bye Tom


    Donnerstag, 11. Januar 2018 13:25

Alle Antworten

  • Nein, kumulative Updates schließen alle vorherigen Updates mit ein, deshalb werden die ja auch immer größer.
    Oder sie melden sich mit dem Hinweis, das ein vorheriges Update zuerst installiert werden muss.
    Donnerstag, 11. Januar 2018 13:45
  • Ich weiß was kumulative Updates sind. Die Frage war ja ob es eine andere Möglichkeit gibt das Schließen der diskutierten Sicherheitslücke zu verhindern? Zum einen muss ja auch die Aussage, dass man ggf darauf verzichten kann, irgendwie begründet sein, zum anderen ist ja auch nicht jeder Server von der Sicherheitslücke betroffen.

    Ich habe hier bereits Server im Haus, die seit ihrer Installation kein einziges Update mehr gesehen haben. Das sind zB RIPs für Druckplattenherstellung oder andere Industriekomponenten in der Druckvorstufe aber dieses Schicksal würde ich den Servern in der Verwaltung, die grundsätzlich anders behandelt werden, gerne ersparen.

    Die Möglichkeiten Updates auf Servern grundsätzlich nicht zu installieren sind mir schon bekannt aber das ist halt eine ziemlich brutale Methode, ich würde gerne darauf verzichten. Jedoch habe ich zumindest bis auf Weiteres davon Gebrauch gemacht. Wohl fühle ich mich aber nicht dabei...


    Donnerstag, 11. Januar 2018 13:55
  • Hi Tom,

    So wie ich das verstehe, wird das Update nur installiert, wenn ein entsprechender Registry Key gesetzt ist, dies aufgrund allfällig inkompatibler Antivirensoftware: https://support.microsoft.com/en-us/help/4072699/january-3-2018-windows-security-updates-and-antivirus-software

    Vieleicht lässt sich die Installation ja so (löschen des Keys, falls gesetzt) auch auf längere Sicht verhindern.

    Gruss,
    Tobias

    Donnerstag, 11. Januar 2018 14:24
  • Servus Tobias,

    >so wie ich das verstehe, wird das Update nur installiert, wenn ein entsprechender Registry Key gesetzt ist, dies aufgrund allfällig inkompatibler Antivirensoftware:

    So wie ich das verstanden habe, kommt dieser RegKey nur dann zum tragen, wenn eine AV Software installiert ist, die im Kernelspeicher rumwurschtelt. Das das fehlen dieses Regkeys die Installation grundsätzlich verhindert habe ich nicht so verstanden. Das macht auch wenig Sinn, weil dann vermutlich 99% aller privaten Windows Systeme ungepatcht blieben. Die wenigsten werden da anfangen freiwillig in der Registry rumzuwurschteln.

    Wir setzen zB Trend Micro ein und unser AV ist von dieser Besonderheit betroffen, wir müssen den Key setzen. Bei Servern habe ich den Key noch nicht gesetzt aber es haben auch die wenigsten Server einen Virenscanner installiert.

    Mal beobachten ob das Fehlen des Keys einen Einfluss auf das Verhalten hinsichtlich der Sicherheitslücke hat. Mein Kollege hat ein Tool gefunden, was die Anfälligkeit für die Sicherheitslücke überprüft.

    Bye Tom


    Donnerstag, 11. Januar 2018 15:25
  • So wie ich das verstanden habe, kommt dieser RegKey nur dann zum tragen, wenn eine AV Software installiert ist, die im Kernelspeicher rumwurschtelt. Das das fehlen dieses Regkeys die Installation grundsätzlich verhindert habe ich nicht so verstanden. Das macht auch wenig Sinn, weil dann vermutlich 99% aller privaten Windows Systeme ungepatcht blieben. Die wenigsten werden da anfangen freiwillig in der Registry rumzuwurschteln.


    So hatte ich das eigentlich auch verstanden, wir haben hier aber gerade das Problem, dass kaum ein Server-System den Patch anfordert, mit oder ohne Registry-Key, mit und ohne WSUS, mit oder ohne Reboot nach Setzen des Reg-Keys.

    Dazu gibt es irgendwie auch noch überhaupt keine konkreten Aussagen von Microsoft, nur ein wildes Herumraten in der Community, ob man den Reg-Key braucht oder nicht, wenn z.B. auch mal kein Virenscanner auf einem Server installiert ist (ja, sowas gibt's auch!). Oder wisst ihr da was genaueres?

    Gruß Marco

    Freitag, 12. Januar 2018 08:03
  • Es wird von MS kein Update geben, solange der AV nicht kompatible ist. Wenn die AV-Software soweit ist, setzt sie den Eintrag und MS wird die Updates ausliefern. Den Reg-Key selbst zu setzen ist mit einem Risiko verbunden.

    PS. TrendMicro ist ja auch kompatible und sollte den Key auch selbst setzen. Vielleicht mal die Virendefinitionen updaten. Wozu ein Tool? Das geht auch per Powershell. Obwohl es bestimmt schon "drittbrettfahrer" gibt, die solche Tools ausnutzen.

    Freitag, 12. Januar 2018 08:10
  • Servus,

    >Es wird von MS kein Update geben, solange der AV nicht kompatible ist.

    Dann könnte ein Workaround auf den Servern sein, einen inkompatiblen Virenscanner zu installieren und den um Himmels Willen nicht mehr updaten... ;-)

    >PS. TrendMicro ist ja auch kompatible und sollte den Key auch selbst setzen.

    Trend Micro gibt dir die Möglichkeit den key selbst zu setzen oder einen Patch im AV einzuspielen, dann setzt den Key der AV selbst:

    https://success.trendmicro.com/solution/1119183

    Ich harre jetzt mal der Dinge die da kommen, wenn mir Microsoft nicht die Möglichkeit gibt das selbst zu entscheiden, werde ich beim dagegen arbeiten langfristig nicht glücklich werden. Wenn unsere Server danach spürbar einbrechen ist das ein Thema mit dem sich die Geschäftsleitung mit Microsoft auseinandersetzen muss.

    Thx & Bye Tom

    Freitag, 12. Januar 2018 08:28
  • Servus,

    >Den Reg-Key selbst zu setzen ist mit einem Risiko verbunden.

    Warum?

    Bye Tom

    Freitag, 12. Januar 2018 08:39
  • Servus,

    >Den Reg-Key selbst zu setzen ist mit einem Risiko verbunden.

    Warum?

    Bye Tom

    Weil ich mal vermute das MS keinen zugriff mehr auf den Kernel gewährt. Der AV es aber nicht anders "gelernt" hat/kann und es dadurch zu BSOD kommen kann. (Inkompatible geworden ist)

    Schaue dir mal den Link zu an, vielleicht wird man etwas schlauer. Leider nur in English.

    https://support.microsoft.com/en-us/help/4072699/january-3-2018-windows-security-updates-and-antivirus-software

    Servus,

    >Es wird von MS kein Update geben, solange der AV nicht kompatible ist.

    Dann könnte ein Workaround auf den Servern sein, einen inkompatiblen Virenscanner zu installieren und den um Himmels Willen nicht mehr updaten... ;-)


    Genau das war auch mein denken. Aber wenn die Server keine Verbindung haben, bekommen sie doch eh keine Updates?



    • Bearbeitet ZühlkeFR Freitag, 12. Januar 2018 09:05
    Freitag, 12. Januar 2018 08:58
  • Servus,

    >Weil ich mal vermute das MS keinen zugriff mehr auf den Kernel gewährt. Der AV es aber nicht anders "gelernt" hat/kann und es dadurch zu BSOD kommen kann. (Inkompatible geworden ist)

    Hm, okay das klingt nachvollziehbar. Trend Micro hat in einem Security Bulletin jedoch explizit erwähnt, dass man den Key auch selbst setzen kann. Insofern sollte es zumindest bei uns nicht zu solchen Problemen kommen.

    >Genau das war auch mein denken. Aber wenn die Server keine Verbindung haben, bekommen sie doch eh keine Updates?

    Updates rollen wir über WSUS aus. bei Windows Server 20018 R2 habe ich jetzt mal das Update KB4056897 abgelehnt. Das wird zumindest nicht offensichtlich als kumulativ geführt, vielleicht war es das ja schon.

    Bei Server 2012R2 wird sowohl im KB Artikel KB4056898, wie auch im Artikel KB4056895 zumindest davon gesprochen, dass man ggf. den Registry Key setzen muss. Das Setzen des Keys habe ich bislang nur im Zusammenhang mit der CPU Sicherheitslücke gehört. Abgelehnt habe ich jetzt erst mal beide. Hier suche ich aber noch nach weiteren Informationen. Freigeben kann ich sie später immer noch.

    Anders schaut die Sache jedoch bei Windows Server 2016 aus. Hier scheint das Update KB4056890 den Fix für die CPU Lücke bereitzustellen, welches allerdings als kumulativ ausgewiesen ist. Hier wird ein Ablehnen langfristig nicht möglich sein. Glücklicherweise haben wir hier bislang nur zwei Testinstallationen am laufen, wollten aber Neuinstallationen nur noch auf Server 2016 durchführen. Es stehen zZ aber keine an.

    Ob ich mich bei den Servern also langfristig davor drücken kann, bleibt ungewiss. Bei den Windows 7 und Windows 10 Clients jedoch werde ich den Patch auf jeden Fall einspielen. Hier ist das Risiko doch erheblich, mit den Konsequenzen muss dann halt leben...

    Thx & Bye Tom


    Freitag, 12. Januar 2018 09:49

  • Hm, okay das klingt nachvollziehbar. Trend Micro hat in einem Security Bulletin jedoch explizit erwähnt, dass man den Key auch selbst setzen kann. Insofern sollte es zumindest bei uns nicht zu solchen Problemen kommen.


    Man kann vieles machen. Muss man aber nicht :-)

    Ich denke mal sie meinen nur ihre eigene AV Suit. Falls der Key nicht durch ein Update gesetzt wird. Aber da sie ja kompatible ist, kann da natürlich auch nichts passieren. Oder sagen wir mal lieber, sollte nicht :-) Weil ich gerade gelesen, dass es auch wieder zu spontanen reboots bei den Intel's CPUs kommt.

    https://newsroom.intel.com/news/intel-security-issue-update-addressing-reboot-issues/


    • Bearbeitet ZühlkeFR Freitag, 12. Januar 2018 10:39
    Freitag, 12. Januar 2018 10:35
  • Servus,

    >Weil ich gerade gelesen, dass es auch wieder zu spontanen reboots bei den Intel's CPUs kommt.

    https://newsroom.intel.com/news/intel-security-issue-update-addressing-reboot-issues/

    Ich denke nicht, dass das was mit dem Registryschlüssel zu tun hat, da geht es wohl um einen Chipsatztreiber. Da scheint jetzt jeder, der sich verantwortlich oder zumindest berufen fühlt, in heftigen Aktionismus zu verfallen. AMD musste auch schon einen Patch zurückziehen.

    Gemach, gemach... ;-)

    Bye Tom

    Freitag, 12. Januar 2018 10:48
  • Servus,

    >Weil ich gerade gelesen, dass es auch wieder zu spontanen reboots bei den Intel's CPUs kommt.

    https://newsroom.intel.com/news/intel-security-issue-update-addressing-reboot-issues/

    Ich denke nicht, dass das was mit dem Registryschlüssel zu tun hat, da geht es wohl um einen Chipsatztreiber. Da scheint jetzt jeder, der sich verantwortlich oder zumindest berufen fühlt, in heftigen Aktionismus zu verfallen. AMD musste auch schon einen Patch zurückziehen.

    Gemach, gemach... ;-)

    Bye Tom

    Sie haben wohl eher die CPU Lücke geschlossen und nun treten neue Probleme auf.

    Das war auch mehr so wegen "es wird schon nichts passieren" (siehe Antivirus).

    Freitag, 12. Januar 2018 13:26