Was sind die Risiken, wenn ein Server oder Hypervisor für Meltdown nicht gepatcht wird?
Es wird gemunkelt, dass der Patch für Meltdown eine 30% ige Leistungsstrafe nach sich zieht, was nach Möglichkeit zu vermeiden wäre. Dies wird also zu einem Problem bei der Bewertung des Sicherheits- und Leistungsrisikos.
Ich suche nach einer Faustregel, um das Risiko zu bewerten, einen Server oder Hypervisor nicht zu patchen.
Nach dem Lesen von den Whitepapers ist mein Verständnis, dass Sie den Patch definitiv anwenden müssen, wenn Ihr Computer:
- ist eine Workstation, auf der zufälliger potenziell schädlicher Code ausgeführt wird - einschließlich es stellt sich heraus , Java Skript von zufälligen Websites,
- ist ein VM, das möglicherweise schädlichen Code ausführen kann (was im Wesentlichen der erste Fall ist).
- ist ein Hypervisor, der nicht vertrauenswürdige VMs neben vertraulichen VMs ausführt (was im Wesentlichen der erste Fall ist).
Mein Verständnis ist, dass das Risiko in den folgenden Fällen (signifikant) geringer ist:
- server, der auf dedizierter Hardware ausgeführt wird und eine streng kontrollierte Reihe von Prozessen in einem streng kontrollierten Netzwerk ausführt (einschließlich der Nichtverwendung eines Webbrowsers zum Besuch nicht vertrauenswürdiger Websites)
- VM, die eine streng kontrollierte Reihe von Prozessen auf einem Virtualisierungsstapel anderer streng kontrollierter VMs ausführt, alle in einem streng kontrollierten Netzwerk.
Ist das logischer Klang oder fehlt mir etwas?
UPDATE: Frühanwender des Patches in Azure melden keine merkliche Verlangsamung , daher ist dies möglicherweise alles umstritten.
Verwandte Frage: Was sind die Risiken, wenn ein Workstation-Betriebssystem für Meltdown nicht gepatcht wird?
Wenn Sie Code aus nicht vertrauenswürdigen Quellen auf einem Computer ausführen, auf dem Daten vorhanden sind, auf die dieser Code keinen Zugriff haben soll, müssen Sie grundsätzlich patchen. Desktop-Computer sollten gepatcht werden, da sie die unglückliche Angewohnheit haben, auf nicht vertrauenswürdigen Code zu stoßen. Shared-Hosting-Server, insbesondere virtuelle private Server-Hosts, müssen gepatcht werden, da mit Meltdown ein Benutzer auf die Daten aller anderen Benutzer zugreifen kann.
Beachten Sie, dass der Meltdown-Angriff kann nicht zum Ausbruch einer virtuellen Maschine verwendet werden . Sie können aus einem Container, einer Sandbox oder einem paravirtualisierten System ausbrechen. Wenn Sie jedoch den Meltdown-Angriff in einem vollständig virtualisierten System ausführen, erhalten Sie nur Zugriff auf den Kernelspeicher dieser VM, nicht auf den Kernelspeicher des Hosts.
Mein Verständnis des Problems ist, dass es sich um ein lokales Informationsleck handelt, wobei lokal bedeutet, dass die Informationen "nur" an Prozesse auf derselben physischen Hardware und nicht (direkt) an entfernte Systeme weitergegeben werden. Und es handelt sich um einen Angriff, der sich in der Praxis als nützlich erwiesen hat, um vertrauliche Informationen zu extrahieren, auch wenn er derzeit nicht trivial auszunutzen ist. Wie einfach der Exploit ist, kann sich jedoch schnell ändern, wie Rowhammer zeigt. Dies entwickelte sich innerhalb kurzer Zeit von einem meist theoretischen Problem zu einer zuverlässigeren Ausnutzung des Problems mithilfe von Javascript in einem Browser oder zu root Android Telefone.
Wenn also die Möglichkeit besteht, dass nicht vertrauenswürdiger Code auf dem Server ausgeführt wird, sollten Sie patchen. Aus diesem Grund haben alle größeren Cloud-Anbieter ihre Systeme bereits gepatcht oder werden dies in Kürze tun. Und deshalb wurden die Patches so schnell in den Linux-Kernel integriert, was für Änderungen am Speichersubsystem sehr ungewöhnlich ist.
Beachten Sie, dass nicht vertrauenswürdiger Code möglicherweise nicht nur ausgeführt wird, wenn Sie nicht vertrauenswürdige Benutzer im System haben. Dies kann auch passieren, wenn Sie Daten verarbeiten, die aus einer nicht vertrauenswürdigen Quelle stammen. Beispielsweise könnte ein Angreifer vorhandene Funktionen Ihres Webservers verwenden, um ein Bild hochzuladen, das dann auf Ihrem Server konvertiert wird (d. H. Skalieren oder ähnliches). Angesichts der Vorgeschichte von Fehlern in Grafikbibliotheken ist es nicht unwahrscheinlich, dass diese Konversation zur Codeausführung führt. Und angesichts der Art des Problems bezweifle ich, dass Sandkästen, Docker oder ähnliches die Ausnutzung des Fehlers stoppen werden.