Heise-Bericht: Weitere Spectre-NG-Patches im August vom 07.05.2018

  • Thread starter Thread starter andreas0
  • Start date Start date
A

andreas0

Guest
Zitat-Auszug von Heise vom 07.05.2018:
Für die Beseitigung der gefährlichsten Spectre-NG-Lücke müssen sich Intels Kunden sogar noch länger gedulden. Sie betrifft ebenfalls die Core-i- sowie Xeon-Prozessoren und erlaubt es, etwa aus einer Virtuellen Maschine heraus deren Wirt oder andere VMs zu attackieren. Das ist insbesondere bei der Nutzung von Cloud-Systemen fatal. Derzeit plant Intel dazu Patches erst im dritten Quartal. Konkret steht der 14. August im Raum. Zur Absicherung der Architektur plant Intel eine Kombination aus Hardware-Updates in Form von neuem Microcode und Software-Verbesserungen, die die Betriebssystem-Hersteller umsetzen müssen.
Click to expand...

Schaut man sich diesen Berichtsauszug von Heise genauer an, so sieht es so aus, als sollte man sich derzeit aus Sicherheitsgründen als potentieller Kunde nicht für eine virtuelle Maschine (vServer) entscheiden, sondern eher für enen physischen Server. Oder wie seht ihr dies?
 
andreas0 said:
... so sieht es so aus, als sollte man sich derzeit aus Sicherheitsgründen als potentieller Kunde nicht für eine virtuelle Maschine (vServer) entscheiden, sondern eher für enen physischen Server.
Click to expand...
Das sage ich ja schon seit Jahren, aber insbesondere hier im SSF werden VMs/Cloud ja gerne als Eierlegendewollmilchsäue mit ausserordentlich hohem Sicherheitslevel dargestellt und verkauft.

Naja, echte Hardwarespezialisten und Assemblerprogrammierer sind von diesen Bugs jedenfalls nicht überrascht, sondern viel mehr davon, dass diese Bugs erst jetzt als problematisch veröffentlicht werden.

Schade dass die Bugs in den nächsten CPU-Revisionen oder CPU-Generationen gefixt werden, denn das waren nette hilfreiche Shortcuts für Leute die wissen was sie tun.


Andererseits sind glücklicherweise noch ein paar ähnliche Hardware-Bugs übrig, so dass nicht alle Shortcuts verbrannt sind.


In Punkto VMs/Cloud gibt es zudem derzeit um die hundert bekannte offene Bugs in den gängigen Produkten um die VMs gegenseitig und auch das Hostsystem zu manipulieren.


Kurz: Wer seine kritischen Daten der Cloud oder VMs anvertraut, der hat bereits verloren, unabhängig davon ob sich die VMs/Cloud inhouse oder extern befindet.
 
Ausschliesslich Testsysteme, meinethalben auch noch Spielumgebungen ala Bluestacks, aber nicht mehr.

Vernünftig skaliertes echtes Blech ist IMHO immer die beste Lösung, sowohl performancetechnisch als auch sicherhetstechnisch.


Wenn man echtes Blech auch noch etwas "underclocked"/downscaled, dann lebt diese nicht nur erheblich länger, man hat auch immer eine ausreichende Reserve.
Zusätzlich hält man den OS- und Softwarestack so klein wie möglich (alle nicht zwingend benötigte Funktionen entsorgen aka gar nicht erst einkompilieren) und gewinnt so weitere Ressourcen zurück und kann weiter downscalen.
So spart man oft am Ende so gar noch Strom im Vergleich zu aufgemotzten VM-Hosts/Clouds.
 
... und Features wie Live-Migration im Defekt-Fall, Ressourcen-Anpassung und andere kleine Nettigkeiten, die Virtualisierung bietet sind kein Argument?

Echtes Blech bedingt, daß für den Ausfall des Systems gleiches echtes Blech bereitsteht und (ab jetzt wird's komplexer) idealerweise in 0-Zeit übernimmt.

Und eine Virtualiserungsumgebung auf ded. eigener Hardware mit Software, die man selbst kontrolliert - wo ist da aus Deiner Sicht das Problem?
 
Mein Eingangspost bezieht sich hier nicht auf die Gegenüberstellung von virtuellen zu physischen Servern in Bezug auf die Performance, sondern soll potentielle Kunden eher dazu anregen, bevor sie sich für eine Art der Server entscheiden, zu prüfen, welche Art von Server wird eigentlich für das zukünftige Projekt (z.B. Online-Shop oder -Forum) in Bezug auf den Zugriff sensibler Daten benötigt.

  • Handelt es sich hier um sensible Daten, an die auf keinen Fall Dritte gelangen dürfen, so sollte man sich hier eher für einen physischen Server, auf dem auch gerne eine oder mehrere eigene virtuelle Server laufen, entscheiden.

  • Handelt es sich hier ausschließlich um nicht sensible Daten, die im Internet sowieso jeder abrufen können soll, so kann man sich auch gern für einen virtuellen Server entscheiden, der auf einem nicht exklusivem Host-System des Providers (physischen Server) liegt. Denn bei dieser Art von Servern kann man sich dann auch eher erlauben, dass das derzeitige Sicherheitsloch durch eventuell unberechtigte Dritte bzw. durch unbekannte weitere Kunden des Providers ausgenutzt wird.
Und wie seht ihr Dies aus eurem Blickwinkel?
 
You must log in or register to reply here.
Back
Top