Umgang mit Sicherheitslücken in CPUs (Meltdown & Spectre)

  • @voja

  • Im Security Tracker sind die Kernel noch als vulnerable gelistet, wobei der Kernel generell auch als vulnerable gelistet ist.


    https://security-tracker.debian.org/tracker/CVE-2017-5715

    https://security-tracker.debian.org/tracker/CVE-2017-5753

    Code
    1. [...]
    2. Implement Kernel Page Table Isolation (KPTI, aka KAISER)(CVE-2017-5754)
    3. [...]

    https://security-tracker.debian.org/tracker/CVE-2017-5754

  • Statusupdate #1:


    Von Meltdown sind Root-Server, VPS, Storage-Server seitens der Wirtssysteme (Nodes) nicht betroffen, da diese Produkte auf KVM basieren. Wir können hier einen auf Performance optimierten Kernel nach wie vor nutzen. Die Gäste müssen allerdings geupdatet werden.


    Wir starten ab 10:50 Uhr mit den Sicherheitsupdates hinsichtlich Spectre auf den Wirtssystemen.


    Managed vServer werden vor dem Neustart der Nodes auch einen neuen Kernel erhalten. So ersparen wir uns hier einen doppelten Reboot.

    Bitte updaten Sie Ihre eigenen Systeme wenn Sie diese selbst managen sobald es für diese Sicherheitsupdates gibt. Damit das Update nicht mit unseren Reboots in einen Konflikt kommt, nach Möglichkeit nach unseren Reboots.


    Mit freundlichen Grüßen


    Felix Preuß

  • Wenn ich ein Upgrade durchführen möchte, erhalte ich folgende Meldung:

    Code
    1. The following packages have been kept back:
    2. linux-image-amd64
    3. 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.

    Hat jemand eine Idee, woran das liegen könnte?

  • Von Meltdown sind Root-Server, VPS, Storage-Server seitens der Wirtssysteme (Nodes) nicht betroffen, da diese Produkte auf KVM basieren. Wir können hier einen auf Performance optimierten Kernel nach wie vor nutzen. Die Gäste müssen allerdings geupdatet werden.

    Das beißt sich ja etwas mit den Ergebnissen der Google Security Analsysten:

    Quote

    Meltdown could have devastating consequence for cloud providers as Google researchers were able to demonstrate reading of host memory from a KVM guest OS. For a cloud service provider, this could enable attacks between customers."

    (Quelle: https://www.itproportal.com/fe…ws-the-industry-responds/)


    Oder sehe ich hier etwas falsch?

  • @bthomba: Wir spielen zusätzlich Microupdates in die Prozessoren ein. Damit sind wir nach aktuellem Kenntnisstand save gegen Meltdown.

    Quote


    Über welchen Zeitraum werden die Sicherheitsupdates sein? Oder ist dies noch unklar?

    Wir können nicht vorhersagen wie lange dieses dauert (siehe vorangegangene Posts mit Erklärung).


    Quote

    Und werden die Server währenddessen auch direkt Neugestartet oder erst später?


    Da die Sicherheitsupdates erst nach einem Neustart aktiv werden, werden die Nodes, wie zuvor beschrieben, auch neu gestartet.


    Mit freundlichen Grüßen


    Felix Preuß

  • Statusupdate #2:


    Wir haben ein Benchmark einmal vor dem Sicherheitsupdate ausgeführt und ein weiteres Mal nach dem Sicherheitsupdate. Dafür wurde ein RS8000 genutzt.


    Das Ergebnis:


    Code
    1. vorher:
    2. System Benchmarks Index Score 5673.4


    Code
    1. nachher:
    2. System Benchmarks Index Score 5479.8

    Ich denke die Sorge, dass durch das Sicherheitsupdate vieles langsamer wird, ist damit unberechtigt.


    Weiteres Statusupdates werden folgen.

  • Hallo,

    mein Server war gerade für ca 1 bis 2 Minuten weg. (Nicht offline sondern nur Verbindung abgebrochen aber nicht die ssh Verbindung)

    War das schon der angekündigte Restart oder hat das etwas damit zu tun? Oder kommt der Restart noch?

    Schau auf die Uptime im SCP oder innerhalb des Gastsystems, dann weißt Du es… ;-)

    Das scheint kein Indikator zu sein. Ich hatte jetzt nacheinander bei drei Systemen einen Verbindungsabbruch (Netzwerk nicht erreichbar) von wenigen Sekunden bis hin zu Minuten mit nicht-Anzeigbarkeit im SCP. Siehe https://forum.netcup.de/netcup…-was-passiert-hier-grade/ und einer davon hat ne Uptime von 172d im SCP. Die VMs wurden auch nicht neugestartet, sondern waren einfach nicht erreichbar...

  • Hallo,

    mein Server war gerade für ca 1 bis 2 Minuten weg. (Nicht offline sondern nur Verbindung abgebrochen aber nicht die ssh Verbindung)

    War das schon der angekündigte Restart oder hat das etwas damit zu tun? Oder kommt der Restart noch?

    Um 13:39 hatte ich laut externem Monitoring auch einen kurzen Unterbruch (2 Minuten), die Server wurden aber nicht neu gestartet (uptime immer noch 25 Tage).

    CentOS 7 / nginx / php-fpm / postfix / rspamd / clamav / dovecot / nextcloud running on RS 1000 SSDx4 G8 / VPS 500 G8 / VPS 2000 G8 Plus

  • Hi,


    ich habe jetzt die Posts hier 2-3 Mal durchgelesen. Verstehe ich es richtig, dass wenn die Server durchgestartet wurden, das Update durch ist?

    Oder anders gefragt: Ist es sicher, die Systeme nun alle wieder auf den Produktiv-Stand zu bringen, oder wird es bis Sonntag noch Updates kommen?


    Grüße

    EONABloodrayne

  • Ob ein Gast neugestartet wurde, können Sie an der Uptime im SCP sehen. Wenn der Server nur kurz nicht erreichbar war, die Uptime noch entsprechend hoch ist, ist es eventuell auf einen anderen Node gewechselt worden. Sollte das häufiger passieren, liegt ein anderes Problem vor. Bitte wenden Sie sich dann an unseren Support.


    Vielen Dank!

  • Wie gesagt waren die Server seit gestern offline. Da die Uptime nun knapp 1 Stunde ist, gehe ich davon aus, dass das Update durch ist.

    Ich gehe davon aus, dass die 72 Stunden auf die komplette Server-Landschaft gilt und wir irgendwann dazwischen durchgestartet wurden.


    Dann werde ich die Dienste wieder starten.


    Vielen Dank für eure Hilfe


    PS: Falls ich was falsch verstanden habe, korrigiert mich bitte.