31
Meltdown und Spectre: Realitätscheck
Die unangenehme Realität
Der Prozessorfehler mit seinen Varianten Meltdown und Spectre ist seit Juni 2017 bekannt. Trotzdem sind immer noch über 80% meiner Rechner oder Geräte durch den CPU-Bug gefährdet. Hier mein persönlicher Realitätscheck.
Alle meine Windows Rechner (und die meiner Verwandten und Eltern) haben Mainboards, die älter als 10 Monate sind, manche sogar 1 bis 3 Jahre. Dafür wird es wahrscheinlich keine Bios-Updates mehr geben, dementsprechend ist der CPU-Patch für Spectre auf all diesen Rechnern, trotz Microsoft Update, nicht aktiv.
Auf meinen Linux Desktop-Rechnern ist der neue Kernel mit den Microcode Update auch nicht drauf, da er noch nicht verteilt wird. Da hoffe ich auf schnelle Besserung mit der nächsten Update-Welle von Fedora Linux.
Meine Server laufen auch unter Linux, dementsprechend ist das für mich ein spannendes Zeitspiel (Kriminelle vs Updates).
Synology stuft den Fehler nur als "Moderate" ein ein verspricht Updates. Qnap sieht ihn als "Severity: High" an und führt lediglich eine Liste seine Geräte mit dem Fehler (fast alle Geräte sind betroffen).
Meine pfSense Firewall soll die Tage eine Patch für Meltdown bekommen, Spectre dauert noch ein wenig (ist ein BSD System).
Einzig alle Apple-Geräte (bis auf einen 24er iMac von 2007) haben ein Update von Meltdown und Spectre (Variante 2) bekommen. Dazu zählt auch mein aktuelles iPhone, meine iPads und dem AppleTV. Spectre Variante 1 wurde beim Safari gepatcht und Apple rät aktuell dazu, nur Software aus dem Appstore (iOS oder macOS) zu nutzen, damit keine Schadsoftware in das System gelangt.
Für mein Android Nexus 9 und 7 gibt es keine Patches mehr und wie es bei der Steuerungshardware und Software von meinem Haus aussieht ist nicht bekannt (da sind auch CPU von Intel oder ARM drin).
Auch der Status meine Playstation 4 oder den ganzen Streaminggeräten (z.B. Amazon Fire) ist mir aktuell noch nicht bekannt.
Folgende Geräte kann ich daher sofort ausschalten und/oder entsorgen: iPad 1, iPhone 4, iMac 24 (Late 2007 Modell, aber vielleicht kommt ja doch noch ein Update), Nexus 7, Nexus 9 und Microsoft Surface 1.
Bei allen anderen Geräten kann ich nur hoffen, dass es in naher Zukunft ein Update gibt und Microsoft auf Microcode Update von sich aus setzt. Wenn nicht, entsorge ich auch diese endgültig und kaufe mir ein aktuelles Surface zum Testen. Dazu hat Microsoft nämlich schon ein Kernel Microcode Update in Windows 10 von sich aus gebracht (na, es geht doch).
Für alle, die jetzt denken dass ich übertrieben handle, haben das Thema und die Gefahr des Prozessorfehlers leider noch nicht verstanden (und nein ich werde diese Hardware auch nicht verschenken oder weitergeben). Wenn ich diese Hardware weiterhin benutze, ist es nur eine Frage der Zeit, bis diese angegriffen wird und meine Passwörter oder sonstige Daten auf paste.bin landen.
Wir brauchen eine Art "Abwrackprämie", die Intel, AMD oder ARM bezahlen
Siehe dazu auch meine Beiträge:
Gruß
Frank
Der Prozessorfehler mit seinen Varianten Meltdown und Spectre ist seit Juni 2017 bekannt. Trotzdem sind immer noch über 80% meiner Rechner oder Geräte durch den CPU-Bug gefährdet. Hier mein persönlicher Realitätscheck.
Alle meine Windows Rechner (und die meiner Verwandten und Eltern) haben Mainboards, die älter als 10 Monate sind, manche sogar 1 bis 3 Jahre. Dafür wird es wahrscheinlich keine Bios-Updates mehr geben, dementsprechend ist der CPU-Patch für Spectre auf all diesen Rechnern, trotz Microsoft Update, nicht aktiv.
Auf meinen Linux Desktop-Rechnern ist der neue Kernel mit den Microcode Update auch nicht drauf, da er noch nicht verteilt wird. Da hoffe ich auf schnelle Besserung mit der nächsten Update-Welle von Fedora Linux.
Meine Server laufen auch unter Linux, dementsprechend ist das für mich ein spannendes Zeitspiel (Kriminelle vs Updates).
Synology stuft den Fehler nur als "Moderate" ein ein verspricht Updates. Qnap sieht ihn als "Severity: High" an und führt lediglich eine Liste seine Geräte mit dem Fehler (fast alle Geräte sind betroffen).
Meine pfSense Firewall soll die Tage eine Patch für Meltdown bekommen, Spectre dauert noch ein wenig (ist ein BSD System).
Einzig alle Apple-Geräte (bis auf einen 24er iMac von 2007) haben ein Update von Meltdown und Spectre (Variante 2) bekommen. Dazu zählt auch mein aktuelles iPhone, meine iPads und dem AppleTV. Spectre Variante 1 wurde beim Safari gepatcht und Apple rät aktuell dazu, nur Software aus dem Appstore (iOS oder macOS) zu nutzen, damit keine Schadsoftware in das System gelangt.
Für mein Android Nexus 9 und 7 gibt es keine Patches mehr und wie es bei der Steuerungshardware und Software von meinem Haus aussieht ist nicht bekannt (da sind auch CPU von Intel oder ARM drin).
Auch der Status meine Playstation 4 oder den ganzen Streaminggeräten (z.B. Amazon Fire) ist mir aktuell noch nicht bekannt.
Folgende Geräte kann ich daher sofort ausschalten und/oder entsorgen: iPad 1, iPhone 4, iMac 24 (Late 2007 Modell, aber vielleicht kommt ja doch noch ein Update), Nexus 7, Nexus 9 und Microsoft Surface 1.
Bei allen anderen Geräten kann ich nur hoffen, dass es in naher Zukunft ein Update gibt und Microsoft auf Microcode Update von sich aus setzt. Wenn nicht, entsorge ich auch diese endgültig und kaufe mir ein aktuelles Surface zum Testen. Dazu hat Microsoft nämlich schon ein Kernel Microcode Update in Windows 10 von sich aus gebracht (na, es geht doch).
Für alle, die jetzt denken dass ich übertrieben handle, haben das Thema und die Gefahr des Prozessorfehlers leider noch nicht verstanden (und nein ich werde diese Hardware auch nicht verschenken oder weitergeben). Wenn ich diese Hardware weiterhin benutze, ist es nur eine Frage der Zeit, bis diese angegriffen wird und meine Passwörter oder sonstige Daten auf paste.bin landen.
Wir brauchen eine Art "Abwrackprämie", die Intel, AMD oder ARM bezahlen
Siehe dazu auch meine Beiträge:
- Meltdown und Spectre: Die machen uns alle was vor
- Sicherheitslücke Spectre und Meltdown: Status prüfen
Gruß
Frank
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 361600
Url: https://administrator.de/imho/meltdown-und-spectre-realitaetscheck-361600.html
Ausgedruckt am: 23.12.2024 um 02:12 Uhr
31 Kommentare
Neuester Kommentar
Moin,
sieht bei uns nicht anders aus. Alles, was nicht mehr updatefähig ist, wird zeitnah ersetzt. Bisher sind nur 2 Rechner betroffen.
Mal sehen, wann es die updates bei den servern für die eingesetzten Modelle gibt.
Gruss
Looser
sieht bei uns nicht anders aus. Alles, was nicht mehr updatefähig ist, wird zeitnah ersetzt. Bisher sind nur 2 Rechner betroffen.
Mal sehen, wann es die updates bei den servern für die eingesetzten Modelle gibt.
Gruss
Looser
Tja,
und die Kurse von AMD und Intel steigen bestimmt schon wieder deutlich.
Denn nach der Entschuldigung sind die doch fertig und ältere Geräte (>3 Jahre) müssen vermutlich ersetzt werden weil es es keine Updates mehr geben wird. Unter andere Anbieter gibt es nun mal nicht.
Muss man nicht eigentlich den Schaden begleichen den man angerichtet hat?
Allein der Schade bei gemieteter Rechenleistung geht doch in die Milliarden. Man muss ja jetzt mehr mieten um die gleiche Leistung zu erhalten.
Tja.... Pech gehabt.
Ich habe jedenfalls noch keine Mail von AWS erhalten, dass die meine Rechnung um 5% kürzen werden.
Sind ja nun auch nicht deren CPUs... oder doch?
Stefan
und die Kurse von AMD und Intel steigen bestimmt schon wieder deutlich.
Denn nach der Entschuldigung sind die doch fertig und ältere Geräte (>3 Jahre) müssen vermutlich ersetzt werden weil es es keine Updates mehr geben wird. Unter andere Anbieter gibt es nun mal nicht.
Muss man nicht eigentlich den Schaden begleichen den man angerichtet hat?
Allein der Schade bei gemieteter Rechenleistung geht doch in die Milliarden. Man muss ja jetzt mehr mieten um die gleiche Leistung zu erhalten.
Tja.... Pech gehabt.
Ich habe jedenfalls noch keine Mail von AWS erhalten, dass die meine Rechnung um 5% kürzen werden.
Sind ja nun auch nicht deren CPUs... oder doch?
Stefan
Hi,
Meine Rechner von Lenovo (X220, T520, T420s) und auch Dell (T3600) sind nach aktuellem Stand bei BIOS-Updates außen vor. Von noch älteren Möhren will ich gar nicht reden.
Aber wenn von Fedora in absehbarer Zeit Patches für die Microcodes der Intel-CPUs ins OS zu erwarten sind:
Würde es nicht Sinn machen, zumindest temporär Linux aufzuspielen, auf dass die Patches Bestand haben, wenn man danach wieder auf Windows zurückkehrt?
Gruß, Nemo
@Frank:
Danke für die offenen Worte; besonders auch unter "Die machen uns alle etwas vor".
Meine Rechner von Lenovo (X220, T520, T420s) und auch Dell (T3600) sind nach aktuellem Stand bei BIOS-Updates außen vor. Von noch älteren Möhren will ich gar nicht reden.
Aber wenn von Fedora in absehbarer Zeit Patches für die Microcodes der Intel-CPUs ins OS zu erwarten sind:
Würde es nicht Sinn machen, zumindest temporär Linux aufzuspielen, auf dass die Patches Bestand haben, wenn man danach wieder auf Windows zurückkehrt?
Gruß, Nemo
@Frank:
Danke für die offenen Worte; besonders auch unter "Die machen uns alle etwas vor".
Es ist eine Illusion zu glauben, daß der Hersteller sowas zahlt. Das Geld dafür kommt entweder vom Kunden oder vom Steuerzahler, also von uns.
lks
Wenn die Geräte nicht älter als 2 Jahre sind könnte man sich eventuell noch an den Verkäufer aufgrund der Gewährleistung wenden.
Der P4 sollte zwar auch betroffen sein, der wird aber definitiv nicht ersetzt und bleibt wie er ist. Mit Linux sollte da der Microcode verfügbar sein, wenn das gepatcht werden sollte.
Der P4 sollte zwar auch betroffen sein, der wird aber definitiv nicht ersetzt und bleibt wie er ist. Mit Linux sollte da der Microcode verfügbar sein, wenn das gepatcht werden sollte.
@Nemo-G
Leider nein, Microcode Updates sind nicht permanent. Sie werden direkt beim Booten des Systems geladen und sobald man dieses System wieder ausschaltet, ist das Update auch wieder verschwunden (unter Linux und BSD, wie das Windows macht ist mir nicht bekannt).
Mit jeden neuen Start wird es auch immer wieder neu reingeladen. Daher ist ein Microcode Update im Bios oder UEFI am sinnvollsten. Da wird es im Speicher vom Bios/UEFI gehalten, da diese Chips Daten auch speichern können. Damit ist das Update auch nach den Neustart noch verfügbar. Eine CPU kann man nicht verändern, sie hat keinen Chip, um das Update zu speichern.
Gruß
Frank
Würde es nicht Sinn machen, zumindest temporär Linux aufzuspielen, auf dass die Patches Bestand haben, wenn man danach wieder auf Windows
Leider nein, Microcode Updates sind nicht permanent. Sie werden direkt beim Booten des Systems geladen und sobald man dieses System wieder ausschaltet, ist das Update auch wieder verschwunden (unter Linux und BSD, wie das Windows macht ist mir nicht bekannt).
Mit jeden neuen Start wird es auch immer wieder neu reingeladen. Daher ist ein Microcode Update im Bios oder UEFI am sinnvollsten. Da wird es im Speicher vom Bios/UEFI gehalten, da diese Chips Daten auch speichern können. Damit ist das Update auch nach den Neustart noch verfügbar. Eine CPU kann man nicht verändern, sie hat keinen Chip, um das Update zu speichern.
Gruß
Frank
Zitat von @Frank:
... Mit jeden neuen Start wird es auch immer wieder neu reingeladen. Daher ist ein Microcode Update im Bios oder UEFI am sinnvollsten. ...
Wenn denn eines zur Verfügung gestellt wird.... Mit jeden neuen Start wird es auch immer wieder neu reingeladen. Daher ist ein Microcode Update im Bios oder UEFI am sinnvollsten. ...
Danke, @Frank, für Deine Erläuterungen, obgleich ich mir eine positive Antwort gewünscht hätte.
Gruß, Nemo
Zitat von @Nemo-G:
Würde es nicht Sinn machen, zumindest temporär Linux aufzuspielen, auf dass die Patches Bestand haben, wenn man danach wieder auf Windows zurückkehrt?
Würde es nicht Sinn machen, zumindest temporär Linux aufzuspielen, auf dass die Patches Bestand haben, wenn man danach wieder auf Windows zurückkehrt?
Wie Frank schon ausgegührt hat, funktioniert das nicht, weil der Mucrocode bei jedem boot von neuèm geladen werden muß. Sinnvoller wäre es da, dauerhaft zu dem OS zu wechseln, das die patches hat.
lks
Zitat von @Windows10Gegner:
Wenn die Geräte nicht älter als 2 Jahre sind könnte man sich eventuell noch an den Verkäufer aufgrund der Gewährleistung wenden.
Die 2 Jahre Gewährleistung gibt es nur für Privatkunden. Bei Gewerblichen beträgt diese häufig nur 6 oder 12 Monate.Wenn die Geräte nicht älter als 2 Jahre sind könnte man sich eventuell noch an den Verkäufer aufgrund der Gewährleistung wenden.
Hallo Frank!
Mein Wissensstand ist, dass zur Ausnutzung der Lücke ein Angreifer Code auf dem Zielsystem ausführen muss.
daher bin ich z.B. bei der PfSense noch völlig entspannt und das ist ja auch die Begründung, warum z.B. AVM seine Produkte als nicht betroffen ansieht.
Liege ich da so verkehrt?
Gruß
Buc
Mein Wissensstand ist, dass zur Ausnutzung der Lücke ein Angreifer Code auf dem Zielsystem ausführen muss.
daher bin ich z.B. bei der PfSense noch völlig entspannt und das ist ja auch die Begründung, warum z.B. AVM seine Produkte als nicht betroffen ansieht.
Liege ich da so verkehrt?
Gruß
Buc
Zitat von @the-buccaneer:
Mein Wissensstand ist, dass zur Ausnutzung der Lücke ein Angreifer Code auf dem Zielsystem ausführen muss.
daher bin ich z.B. bei der PfSense noch völlig entspannt und das ist ja auch die Begründung, warum z.B. AVM seine Produkte als nicht betroffen ansieht.
Liege ich da so verkehrt?
Das überlege ich ja auch.Mein Wissensstand ist, dass zur Ausnutzung der Lücke ein Angreifer Code auf dem Zielsystem ausführen muss.
daher bin ich z.B. bei der PfSense noch völlig entspannt und das ist ja auch die Begründung, warum z.B. AVM seine Produkte als nicht betroffen ansieht.
Liege ich da so verkehrt?
Dann dürften Server in LANs eigentlich nicht betroffen sein, sondern nur Webserver.
Bzw. stellt sich die Fragen: "Wenn ein Bösewichtig Code auf meinem Server ausführen kann, ist er doch sowieso drin?".
Stefan
Jein, denn am Servern hängen normalerweise jede Menge Clients mit vielen Usern. Somit viele potentielle Angriffsflächen.
Also min. alle Clients updaten sollte Pflicht sein, um das Risiko zu minimieren. Ganz weg bekommt man das eh nicht.
Gruß Looser
Also min. alle Clients updaten sollte Pflicht sein, um das Risiko zu minimieren. Ganz weg bekommt man das eh nicht.
Gruß Looser
Tja, und alle sprechen aktuell nur von Updates der Server.
Ich habe noch kein Updates für Clients gesehen. Win7, 8, 10.
Ich bin ja weiter gespannt.
Btw. Ist die Crack-WLAN-Lücke eigentlich schon überall gestopft?
Davon hört man gar nichts mehr..... Schelm wer bei der Kombination der beiden böses denkt...
Stefan
Ich habe noch kein Updates für Clients gesehen. Win7, 8, 10.
Ich bin ja weiter gespannt.
Btw. Ist die Crack-WLAN-Lücke eigentlich schon überall gestopft?
Davon hört man gar nichts mehr..... Schelm wer bei der Kombination der beiden böses denkt...
Stefan
Ich habe noch kein Updates für Clients gesehen. Win7, 8, 10.
KB4056892 gibt es auch für Windows 10.
In Verbindung mit den BIOS Update wird die Lücke dann als "geschlossen" angezeigt.
Zitat von @Looser27:
KB4056892 gibt es auch für Windows 10.
In Verbindung mit den BIOS Update wird die Lücke dann als "geschlossen" angezeigt.
70% meiner medizinischen Kunden verwenden Win7 32Bit....KB4056892 gibt es auch für Windows 10.
In Verbindung mit den BIOS Update wird die Lücke dann als "geschlossen" angezeigt.
gewünscht bis 04/20
Autsch...
Zitat von @StefanKittel:
gewünscht bis 04/20
Zitat von @Looser27:
KB4056892 gibt es auch für Windows 10.
In Verbindung mit den BIOS Update wird die Lücke dann als "geschlossen" angezeigt.
70% meiner medizinischen Kunden verwenden Win7 32Bit....KB4056892 gibt es auch für Windows 10.
In Verbindung mit den BIOS Update wird die Lücke dann als "geschlossen" angezeigt.
gewünscht bis 04/20
vermutlich noch ohne Sp1
lks
PS: Meine Kunden sitzen auch weitgehend auf Win7 fest.
Moin,
Mal abgesehen davon, dass ich W10 jetzt nicht so besonders schick finde ... an den Büchsen hängt diverse Medizintechnik, die nicht direkt preiswert ist, stellenweise noch mit seriellen Schnittstellen. Teils gibt es keine updates der zugehörigen softwares für W10, teils keine Treiber, wenn doch, lassen sich die Hersteller das mehr als fürstlich bezahlen.
Serverseitig scheine ich aus der Geschichte rauszukommen, HP scheint bis hinunter nach Gen8 patches anbieten zu wollen, meine Büchsen sind alles Esprimos - da finde ich überhaupt kein statement von Fujitsu.
Wenn ich mir aber überlege, dass ich mit spectre, meltdown und weiss der Geier noch für nicht publik gewordenen Lecks seit 10 Jahren durchs Leben krabbel ... ist mir das eigentlich auch Wurst.
LG, Thomas
Autsch...
was heisst autsch? Ich werde ebenfalls W7 - wenn auch x64 - bis zum vorvorletzten Tag betreiben.Mal abgesehen davon, dass ich W10 jetzt nicht so besonders schick finde ... an den Büchsen hängt diverse Medizintechnik, die nicht direkt preiswert ist, stellenweise noch mit seriellen Schnittstellen. Teils gibt es keine updates der zugehörigen softwares für W10, teils keine Treiber, wenn doch, lassen sich die Hersteller das mehr als fürstlich bezahlen.
Serverseitig scheine ich aus der Geschichte rauszukommen, HP scheint bis hinunter nach Gen8 patches anbieten zu wollen, meine Büchsen sind alles Esprimos - da finde ich überhaupt kein statement von Fujitsu.
Wenn ich mir aber überlege, dass ich mit spectre, meltdown und weiss der Geier noch für nicht publik gewordenen Lecks seit 10 Jahren durchs Leben krabbel ... ist mir das eigentlich auch Wurst.
LG, Thomas
Kann man so machen....ich persönlich würde jedoch auf ein aktuelles OS setzen und ggf. die nicht mehr supporteten Teile über eine VM laufen lassen.
Klar, ich hab gut reden, weil mein Zeug alles unter Windows 10 läuft. Aber ich habe auch erst gewechselt, als ich alle Software-Updates zusammen hatte.
Was die BIOS-Updates angeht, so ist Fujitsu echt mal grottig. Da tut sich genau NULL. Deswegen werde ich die betreffenden Geräte aussortieren.
Das Problem mit publik gewordenen Sicherheitslücken ist aus meiner Sicht immer, dass dann verstärkt versucht wird, nicht schnell genug gepatchte Systeme zu infiltrieren....
Es bleibt wie immer ein Wettlauf.
Gruß
Looser
Klar, ich hab gut reden, weil mein Zeug alles unter Windows 10 läuft. Aber ich habe auch erst gewechselt, als ich alle Software-Updates zusammen hatte.
Was die BIOS-Updates angeht, so ist Fujitsu echt mal grottig. Da tut sich genau NULL. Deswegen werde ich die betreffenden Geräte aussortieren.
Das Problem mit publik gewordenen Sicherheitslücken ist aus meiner Sicht immer, dass dann verstärkt versucht wird, nicht schnell genug gepatchte Systeme zu infiltrieren....
Es bleibt wie immer ein Wettlauf.Gruß
Looser
KB4056892 gibt es auch für Windows 10.
In Verbindung mit den BIOS Update wird die Lücke dann als "geschlossen" angezeigt.
In Verbindung mit den BIOS Update wird die Lücke dann als "geschlossen" angezeigt.
Hier liegt ja das Problem von Windows (egal ob Version 7 oder 10), es wird für 90% aller PCs kein Bios Update mehr geben. Kann man das als "geschlossen" bezeichnen?
siehe dazu auch: Meltdown und Spectre: Die machen uns alle was vor
Gruß
Frank
Moin,
meine Büchsen sind alles Esprimos - da finde ich überhaupt kein statement von Fujitsu.
Dann lies das mal.
Gruß
Uwe
meine Büchsen sind alles Esprimos - da finde ich überhaupt kein statement von Fujitsu.
Dann lies das mal.
Gruß
Uwe
Zitat von @Frank:
Hier liegt ja das Problem von Windows (egal ob Version 7 oder 10), es wird für 90% aller PCs kein Bios Update mehr geben. Kann man das als "geschlossen" bezeichnen?
siehe dazu auch: Meltdown und Spectre: Die machen uns alle was vor
Gruß
Frank
KB4056892 gibt es auch für Windows 10.
In Verbindung mit den BIOS Update wird die Lücke dann als "geschlossen" angezeigt.
In Verbindung mit den BIOS Update wird die Lücke dann als "geschlossen" angezeigt.
Hier liegt ja das Problem von Windows (egal ob Version 7 oder 10), es wird für 90% aller PCs kein Bios Update mehr geben. Kann man das als "geschlossen" bezeichnen?
siehe dazu auch: Meltdown und Spectre: Die machen uns alle was vor
Gruß
Frank
Natürlich nicht, aber der Artikel gibt zumindest noch einen Funken Hoffnung....
Zitat von @the-buccaneer:
Mein Wissensstand ist, dass zur Ausnutzung der Lücke ein Angreifer Code auf dem Zielsystem ausführen muss.
daher bin ich z.B. bei der PfSense noch völlig entspannt und das ist ja auch die Begründung, warum z.B. AVM seine Produkte als nicht betroffen ansieht. Liege ich da so verkehrt?
Mein Wissensstand ist, dass zur Ausnutzung der Lücke ein Angreifer Code auf dem Zielsystem ausführen muss.
daher bin ich z.B. bei der PfSense noch völlig entspannt und das ist ja auch die Begründung, warum z.B. AVM seine Produkte als nicht betroffen ansieht. Liege ich da so verkehrt?
Ja, das stimmt. Bisher muss die Schadsoftware irgendwie auf das System kommen (über Browser, Mail, Remote Exploit, Kernel-Fehler, etc).
Dank der Kreativität der Entwickler von Schadsoftware werden die aber bestimmt einen Weg finden. (Fast) geschlossene Systeme wie z.B. AVM, pfSense oder auch Apple sind da schon schwerer zu knacken.
Aber auch z.B. die pfSense kann per Softwaremodule erweitert werden. Diese kommen meist von Drittherstellern und nicht direkt vom pfSense Projekt. Da sollte man dann doch aufpassen, dass diese nicht irgendwie infiltriert wurden (Zertifikate, Checksumme, etc.)
Gruß
Frank
@Looser27,
Hoffnung war noch nie ein Garant für Sicherheit
Microsoft sollte, wie Linux und BSD (Mac, pfSense, etc.) die Microcode Updates per Kernel und nicht per Bios/UEFI machen. Erst dann wären alles Systeme abgesichert. Ist mir ein Rätsel warum die das aktuell nicht machen/wollen? Sie schieben die Verantwortung einfach auf die Board-Hersteller.
Technisch kann Microsoft die Microcode Updates selbst machen. Ihr Surface Pro 3 und 4 haben so ein Microcode Update bereits per Software bekommen und auch in der Vergangenheit gab es schon Microcode Updates für die Windows Server-Version. Gerade der Serverbereich wird durch die lange Laufzeit der Hardware garantiert keine Bios-Updates bekommen.
Wie sieht es denn real bei den meisten Usern aus? Wer hat denn ein Bios-Update für seine Maschine bekommen?
Gruß
Frank
Natürlich nicht, aber der Artikel gibt zumindest noch einen Funken Hoffnung
Hoffnung war noch nie ein Garant für Sicherheit
Microsoft sollte, wie Linux und BSD (Mac, pfSense, etc.) die Microcode Updates per Kernel und nicht per Bios/UEFI machen. Erst dann wären alles Systeme abgesichert. Ist mir ein Rätsel warum die das aktuell nicht machen/wollen? Sie schieben die Verantwortung einfach auf die Board-Hersteller.
Technisch kann Microsoft die Microcode Updates selbst machen. Ihr Surface Pro 3 und 4 haben so ein Microcode Update bereits per Software bekommen und auch in der Vergangenheit gab es schon Microcode Updates für die Windows Server-Version. Gerade der Serverbereich wird durch die lange Laufzeit der Hardware garantiert keine Bios-Updates bekommen.
Wie sieht es denn real bei den meisten Usern aus? Wer hat denn ein Bios-Update für seine Maschine bekommen?
Gruß
Frank
Hi Uwe,
LG, Thomas
Dann lies das mal.
da kann man auch langsam wieder dazu übergehen, seine Büchsen selbst zusammen zu schrauben LG, Thomas
Moin Frank,
LG, Thomas
Gerade der Serverbereich wird durch die lange Laufzeit der Hardware garantiert keine Bios-Updates bekommen.
da hakt es gerade bei mir definitiv mit dem Verstehbären ... ??LG, Thomas
Zitat von @Frank:
Gerade der Serverbereich wird durch die lange Laufzeit der Hardware garantiert keine Bios-Updates bekommen.
Gerade der Serverbereich wird durch die lange Laufzeit der Hardware garantiert keine Bios-Updates bekommen.
Hm, irgendwie ist das ein Widerspruch. Unternehmen, welche Ihre Hardware leasen, verwenden diese in der Regel 3 bis 5 Jahre. Um einigermaßen aktuelle Systeme zu haben. Für diese Systeme sollte man davon ausgehen, daß es BIOS / UEFI bzw. Microcodeupdates der Hersteller geben sollte. Ich weiß noch von IBM Servern bzw. HPE Servern, daß man die BIOS/ UEFI bzw. Microcodes selbst aktualisieren konnte / kann. Die meisten Unternehmen, welche ich kenne, lassen die durch Techniker machen. Dafür sind Wartungsverträge da. Und außerdem, wenn der Techniker das Update versemmelt, dann muß dieser dafür sorgen , dass der Server / die Hardware wieder funktioniert. Ich habe dies des öfteren schon erlebt, daß nach einen Update (BIOS / UEFI / Microcode) das System danach unbrauchbar war.
Es ist die Frage, ob und wis die großen Serverhersteller reagieren werden. Im Mainframebereich, weiß ich, daß die IBM sehr zügig reagiert. Denn hier geht es um sehr teure Wartungsverträge.
Gruß
Frank
Frank
Gruss Penny
Ja, das ist die Frage.
Es ist im Prinzip so wie mit Diesel Euro 4.
Wenn alle Großstädte am 01.02.17 die Einfahrt im Großbereich von allen Diesel Euro 4 verbieten würden.
Was ja durchaus noch kommen kann.
Alle Fahrzeuge mit Euro Diesel 4 und weniger wären auf einen Schlag wertlos.
Diesel-Filter nachrüsten = BIOS Update.
Lustige parallelen.
Nur das, das "Fahrverbot" für die CPUs schon in Kraft ist.
Eigentlich müßten AWS und Hetzner doch alle Root-Server sofort ausschalten.
Stefan
Es ist im Prinzip so wie mit Diesel Euro 4.
Wenn alle Großstädte am 01.02.17 die Einfahrt im Großbereich von allen Diesel Euro 4 verbieten würden.
Was ja durchaus noch kommen kann.
Alle Fahrzeuge mit Euro Diesel 4 und weniger wären auf einen Schlag wertlos.
Diesel-Filter nachrüsten = BIOS Update.
Lustige parallelen.
Nur das, das "Fahrverbot" für die CPUs schon in Kraft ist.
Eigentlich müßten AWS und Hetzner doch alle Root-Server sofort ausschalten.
Stefan
Hi,
Ich kann natürlich nur aus meiner Erfahrung sprechen, ich habe ein wenig Einsicht in ein Rechenzentrum in Frankfurt. Hier geht es nicht um ein RZ für eine Firma, sondern für sehr viele Firmen inkl. Hosting und Colocation für 24/7. Die wenigsten Server sind hier geleast. Große Firmen haben zwar einen Supportvertrag, aber wenn die Kisten nicht gerade von Dell, Fujitsu und Co. kommen, ist dieser nur mit einem Dienstleister und nicht mit dem Hersteller selbst abgeschlossen.
Diese Dienstleiter (darunter auch meist das RZ) müssen die Leistung eines Microcode Updates beim jeweiligen Hersteller der Hardware anfragen. Microcode Updates für die Server gehören in der Regel aber nicht zum Dienstleistungsvertrag und werden extra bezahlt (wenn überhaupt verfügbar). Dazu kommt noch, das z.B. einige Server-Hardwarehersteller Microcode Updates gar nicht als ihren Support ansehen (z.B. Fujitsu).
Da manche Server locker mehr als 4 bis 5 Jahre im RZ laufen, ist es fast unmöglich, hier neue Bios Updates für die Hardware zu bekommen. Von der Ausfallzeit und der Unsicherheit, ob das Bios Microcode Update überhaupt sauber läuft, einmal abgesehen. Das sind fast alles 24/7 Dienste, da bedeutet jeder Ausfall viel Geld.
Die meisten Server im RZ laufen aber unter Linux/BSD/Unix (95%), daher ist die Hoffnung groß, dass man es mit einem zukünftigen Kernel-Update beheben kann.
Gruß
Frank
Gerade der Serverbereich wird durch die lange Laufzeit der Hardware garantiert keine Bios-Updates bekommen.
da hakt es gerade bei mir definitiv mit dem Verstehbären ... ??Ich kann natürlich nur aus meiner Erfahrung sprechen, ich habe ein wenig Einsicht in ein Rechenzentrum in Frankfurt. Hier geht es nicht um ein RZ für eine Firma, sondern für sehr viele Firmen inkl. Hosting und Colocation für 24/7. Die wenigsten Server sind hier geleast. Große Firmen haben zwar einen Supportvertrag, aber wenn die Kisten nicht gerade von Dell, Fujitsu und Co. kommen, ist dieser nur mit einem Dienstleister und nicht mit dem Hersteller selbst abgeschlossen.
Diese Dienstleiter (darunter auch meist das RZ) müssen die Leistung eines Microcode Updates beim jeweiligen Hersteller der Hardware anfragen. Microcode Updates für die Server gehören in der Regel aber nicht zum Dienstleistungsvertrag und werden extra bezahlt (wenn überhaupt verfügbar). Dazu kommt noch, das z.B. einige Server-Hardwarehersteller Microcode Updates gar nicht als ihren Support ansehen (z.B. Fujitsu).
Da manche Server locker mehr als 4 bis 5 Jahre im RZ laufen, ist es fast unmöglich, hier neue Bios Updates für die Hardware zu bekommen. Von der Ausfallzeit und der Unsicherheit, ob das Bios Microcode Update überhaupt sauber läuft, einmal abgesehen. Das sind fast alles 24/7 Dienste, da bedeutet jeder Ausfall viel Geld.
Die meisten Server im RZ laufen aber unter Linux/BSD/Unix (95%), daher ist die Hoffnung groß, dass man es mit einem zukünftigen Kernel-Update beheben kann.
Gruß
Frank
Ich möchte hier gerne auf ein Tool von VMware hinweisen: vmware-microcode-update-driver.
Installation ist problemlos und man kann damit zur Laufzeit von Windows eine AMD- oder Intel-CPU mit Microcode-Patches behandeln. Ist ein Treiber, beim nächsten Starten werden die Updates also wieder eingespielt. Das ist für mich, wenn auch nicht wirklich eine Lösung, so doch eine Krücke um schnell alle Windows-PCs in Sicherheit zu bringen, auch wenn noch keine BIOS-Updates draußen sind.
Aber: auf einigen nicht zu alten Systemen reichten auch die aktuell von Intel geladenen µc-Patches vom 8. Januar NICHT aus, der Mikrocode wird immer noch als nicht gepatcht angesehen. Intel hat also nicht nicht geliefert, wie sollen es das die OEM tun? Bei mir konnte ich von 65 Clients und 20 Servern immerhin 5 Clients und 5 Server absichern
Gruß,
Jens
Installation ist problemlos und man kann damit zur Laufzeit von Windows eine AMD- oder Intel-CPU mit Microcode-Patches behandeln. Ist ein Treiber, beim nächsten Starten werden die Updates also wieder eingespielt. Das ist für mich, wenn auch nicht wirklich eine Lösung, so doch eine Krücke um schnell alle Windows-PCs in Sicherheit zu bringen, auch wenn noch keine BIOS-Updates draußen sind.
Aber: auf einigen nicht zu alten Systemen reichten auch die aktuell von Intel geladenen µc-Patches vom 8. Januar NICHT aus, der Mikrocode wird immer noch als nicht gepatcht angesehen. Intel hat also nicht nicht geliefert, wie sollen es das die OEM tun? Bei mir konnte ich von 65 Clients und 20 Servern immerhin 5 Clients und 5 Server absichern
Gruß,
Jens
1
es wird immer wieder vergessen, daß der Spectre und Meltdown Angriff von einem aktven Prozeß auf dem betroffenen Rechner heraus gestartet werden muß und daß beide Angriffsarten SEHR LANGSAM sind, die zu extrahierende Datenmenge aus dem (geschützten und angegriffenen) Arbeitsspeicher beträgt wenige KB pro Sekunde.
Der Angreifer muß sehr genau wissen, was er wo sucht und den Angriff vor dem Virenscanner verschleiern und an der Firewall vorbei die gewonnenen Daten ausschleusen. Quelle : ix
Da wird meiner Meinung nach viel zuviel Wind um einen relativ schwer auszunutzenden Bug gemacht, zuaml hier dann maßgeschniederte Tools für ganz bestimmte Angriffe gebaut werden müssen... den Arbeitsspeicher komplett nach Mustern zu scannen dauert mit einem Spectre Angriff schlichtweg zu lange.
Der Angreifer muß sehr genau wissen, was er wo sucht und den Angriff vor dem Virenscanner verschleiern und an der Firewall vorbei die gewonnenen Daten ausschleusen. Quelle : ix
Da wird meiner Meinung nach viel zuviel Wind um einen relativ schwer auszunutzenden Bug gemacht, zuaml hier dann maßgeschniederte Tools für ganz bestimmte Angriffe gebaut werden müssen... den Arbeitsspeicher komplett nach Mustern zu scannen dauert mit einem Spectre Angriff schlichtweg zu lange.
