Spectre/Meltdown Spec store bypass: vulnerable
Re: Spectre/Meltdown Spec store bypass: vulnerable
[CERT-EU#2022071242000096] Incidence Report | Various cloud providers
Dear researcher,
Thank you for your report. The reported vulnerability has been received and it is being analysed. Please read the current CERT-EU Responsible Disclosure Policy: https://cert.europa.eu/cert/newsletter/ ... CERTpolicy
--
CERT-EU (https://cert.europa.eu)
Phone: +32.2.2990005 / e-mail: services@cert.europa.eu
PGP KeyID 0x5DDA8E13
FP: C9B2 0BAB 2C37 35AD FF79 7949 AFBD 579A 5DDA 8E13
Privacy statement: https://cert.europa.eu/cert/plaineditio ... ivacy.html
Dear researcher,
Thank you for your report. The reported vulnerability has been received and it is being analysed. Please read the current CERT-EU Responsible Disclosure Policy: https://cert.europa.eu/cert/newsletter/ ... CERTpolicy
--
CERT-EU (https://cert.europa.eu)
Phone: +32.2.2990005 / e-mail: services@cert.europa.eu
PGP KeyID 0x5DDA8E13
FP: C9B2 0BAB 2C37 35AD FF79 7949 AFBD 579A 5DDA 8E13
Privacy statement: https://cert.europa.eu/cert/plaineditio ... ivacy.html
- Blackbox
- Beiträge: 4289
- Registriert: 17.09.2008 17:01:20
- Lizenz eigener Beiträge: GNU Free Documentation License
Re: Spectre/Meltdown Spec store bypass: vulnerable
Damit kannst du nun zum Support deines Hosters rennen, hoffen, dass dieser, deine Befürchtungen teilt und fixt.
Das ändert natürlich nichts an deiner Fehlentscheidung des Servermodells und schützt dich auch nicht vor weiteren Bugs dieser Klasse.
Aber du hast hoffentlich trotzdem etwas für die Zukunft mitgenommen?
Und nun kannst du gern diesen Thread als [erledigt] markieren.
Das ändert natürlich nichts an deiner Fehlentscheidung des Servermodells und schützt dich auch nicht vor weiteren Bugs dieser Klasse.
Aber du hast hoffentlich trotzdem etwas für die Zukunft mitgenommen?
Und nun kannst du gern diesen Thread als [erledigt] markieren.
Eigenbau PC: Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Desktop PC: Dell Inspiron 530 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Notebook: TUXEDO BU1406 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Alles Minimalinstallationen und ohne sudo/PA/PW.
Rootserver: Rocky Linux 9.3 - Kernel: 5.14
Freie Software unterstützen, Grundrechte stärken!
Desktop PC: Dell Inspiron 530 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Notebook: TUXEDO BU1406 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Alles Minimalinstallationen und ohne sudo/PA/PW.
Rootserver: Rocky Linux 9.3 - Kernel: 5.14
Freie Software unterstützen, Grundrechte stärken!
Re: Spectre/Meltdown Spec store bypass: vulnerable
Ein weiterer Beitrag, der dieser ernsten Angelegenheit wenig dient und auch wenig Sinn im Kontext macht. Wie das bessere Serverkonzept aussieht, ist bekannt. Die Fragestellung aber eine andere.
Lies doch einfach noch einmal meine Wortbeitraege durch. Ich helfe noch mal... Selbst das Modell des virtuellen Servers kann eine preiswerte Alternative sein. Nach Schliessen der von mir benannten Sicherheitsluecke sogar eine gute preiswerte Alternative.
Wie waere es denn mal mit einem konstruktiven fachlichen Vorschlag zur Fragestellung?
Lies doch einfach noch einmal meine Wortbeitraege durch. Ich helfe noch mal... Selbst das Modell des virtuellen Servers kann eine preiswerte Alternative sein. Nach Schliessen der von mir benannten Sicherheitsluecke sogar eine gute preiswerte Alternative.
Wie waere es denn mal mit einem konstruktiven fachlichen Vorschlag zur Fragestellung?
Re: Spectre/Meltdown Spec store bypass: vulnerable
Um was geht es dir in dem Thread nun eigentlich?
Am ehesten scheint es mir dieser Post auf den Punkt zu bringen:
Auf mich wirkt das alles wie sich den Frust von der Seele zu schreiben und auf Personen zu hoffen, die einstimmen. Das hast du nun ja ausreichend getan und es hat halt niemand eingestimmt. Jetzt kannst du damit aufhoeren; mehr davon bringt nicht mehr.
Konstruktive Vorschlaege fuer weiteres konkretes Vorgehen sind dir gemacht worden. Die kannst du aufgreifen wenn du etwas aendern willst. Das gehoert dann aber nicht mehr hier ins Forum.
Am ehesten scheint es mir dieser Post auf den Punkt zu bringen:
... und ich frage mich wen du in dem letzten Satz adressierst? Ich verstehe nicht warum du das *uns* schreibst.Xela69 hat geschrieben:04.07.2022 23:39:30Warum hat die Industrie wohl solch einen riesengroßen Aufwand fuer die Mitigationen gegen Spectre/Meltdown in den vergangenen 5 Jahren erbracht? For nothing? Und warum artet das ueberhaupt so aus? Es geht um einen einzelnen Kernelparameter, welcher auf den Hosts richtig gesetzt werden muss, was definitiv moeglich ist, damit die Virtuellen Privaten Server auch mitigiert werden koennen. Wo liegt denn da das Problem? Wir stecken in den Anfaengen einer neuen Industriellen Revolution - Industrie 4.0. Da kommen soviele neue Sachen in den naechsten Jahrzehnten. Macht es doch einfach mal richtig!
Auf mich wirkt das alles wie sich den Frust von der Seele zu schreiben und auf Personen zu hoffen, die einstimmen. Das hast du nun ja ausreichend getan und es hat halt niemand eingestimmt. Jetzt kannst du damit aufhoeren; mehr davon bringt nicht mehr.
Konstruktive Vorschlaege fuer weiteres konkretes Vorgehen sind dir gemacht worden. Die kannst du aufgreifen wenn du etwas aendern willst. Das gehoert dann aber nicht mehr hier ins Forum.
Use ed once in a while!
Re: Spectre/Meltdown Spec store bypass: vulnerable
Nein, ich brauche weder jemanden zum Reden, noch muss ich Frust ablassen.
Mein Problem ist doch glasklar umschrieben.
Preiswerte virtuelle Server, die sicherer sein koennten, wenn diese eine Luecke geschlossen ist, was offensichtlich machbar ist.
Natuerlich kann man das alles umgehen, wenn man einen sehr viel teureren dedizierten Server kauft.
Mir geht es aber gerade um eine breite Loesung, die sich viele leisten koennen. Wieso das dann bei Dir oder auch bei Blackbox dazu fuehrt alle moeglichen Gruende anzufuehren, warum mein Beitrag mit meinen Gefuehlen oder meinem Qualitaetsniveau zu tun hat, entschliesst sich mir.
Dass du nun in die gleiche Kerbe haust "Loesungen sind angeboten worden" wundert mich schon sehr.
Aber vielleicht habe ich etwas uebersehen...
Bitte setz mir doch einen Link, wo tatsaechlich Loesungen angeboten worden sind.
Ansonsten kann man bei der zunehmenden Anzahl von Views ja nicht davon ausgehen, dass das Thema sich totgelaufen hat.
Leider hat nur noch niemand eine Loesung fuer die Fragestellung angeboten. Wenn Dir Threats gut gefallen, wo sich Leute mal richtig aussprechen wollen, dann steht es Dir natuerlich frei diese zu nutzen. Aus meiner Sicht, mit meinem absolut legitimen Anliegen macht es absolut Sinn diesen Threat offenzuhalten.
Mein Problem ist doch glasklar umschrieben.
Preiswerte virtuelle Server, die sicherer sein koennten, wenn diese eine Luecke geschlossen ist, was offensichtlich machbar ist.
Natuerlich kann man das alles umgehen, wenn man einen sehr viel teureren dedizierten Server kauft.
Mir geht es aber gerade um eine breite Loesung, die sich viele leisten koennen. Wieso das dann bei Dir oder auch bei Blackbox dazu fuehrt alle moeglichen Gruende anzufuehren, warum mein Beitrag mit meinen Gefuehlen oder meinem Qualitaetsniveau zu tun hat, entschliesst sich mir.
Dass du nun in die gleiche Kerbe haust "Loesungen sind angeboten worden" wundert mich schon sehr.
Aber vielleicht habe ich etwas uebersehen...
Bitte setz mir doch einen Link, wo tatsaechlich Loesungen angeboten worden sind.
Ansonsten kann man bei der zunehmenden Anzahl von Views ja nicht davon ausgehen, dass das Thema sich totgelaufen hat.
Leider hat nur noch niemand eine Loesung fuer die Fragestellung angeboten. Wenn Dir Threats gut gefallen, wo sich Leute mal richtig aussprechen wollen, dann steht es Dir natuerlich frei diese zu nutzen. Aus meiner Sicht, mit meinem absolut legitimen Anliegen macht es absolut Sinn diesen Threat offenzuhalten.
Re: Spectre/Meltdown Spec store bypass: vulnerable
An wen wendest du dich damit? Ist das eine politische Forderung deinerseits?Xela69 hat geschrieben:14.07.2022 13:04:12Mein Problem ist doch glasklar umschrieben.
Preiswerte virtuelle Server, die sicherer sein koennten, wenn diese eine Luecke geschlossen ist, was offensichtlich machbar ist.
Natuerlich kann man das alles umgehen, wenn man einen sehr viel teureren dedizierten Server kauft.
Mir geht es aber gerade um eine breite Loesung, die sich viele leisten koennen. [...]
Aber warum schreibst du *uns* das? -- Darauf finde ich in deinen Posts bisher noch keine Antwort (wenn es nicht aus Mitteilungsbeduerfnis ist).
Use ed once in a while!
- Livingston
- Beiträge: 1813
- Registriert: 04.02.2007 22:52:25
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: 127.0.0.1
Re: Spectre/Meltdown Spec store bypass: vulnerable
Mal aus dem Nähkästchen geplaudert: Eine Menge meiner Kunden äußern den Wunsch, allen möglichen Krempel "in einer Cloud" oder "auf so 'nem Server im Rechenzentrum" zu verstauen.
Regelmäßig gibt's dann von mir den Crashkurs, wer wann wo wie Zugriff auf die ausgelagerten Daten hat. Nach wie vor gilt der alte Grundsatz: Wer physischen Zugriff hat, beherrscht das Gerät. Bspw. schützt mich eine LUKS-Verschlüsselung nicht, wenn die Kiste läuft und alle LUKS-Platten für das installierte System offen wie Scheunentore sind.
Das Ganze potenziert sich auf virtuellen Servern, nicht nur in Bezug auf Meltdown und Co, sondern ganz allgemein wegen kritischer Bugs, die immer mal auftauchen können, insbesondere auf dem Host-System, auf das man als Nutzer eines V-Servers gar keinen Einfluss hat.
Und da sind wir dann beim Thema Verantwortung und Haftbarkeit: Wenn auf meinem Server was schief geht, kann ich die Sache selbstverantwortet fixen, nicht jedoch wenn der Betreiber eines Host seinen Job nicht ordentlich macht. In dem Fall hafte auch ich für Fehler des Hosters. Versicherungen haben da eine ganz klare Haltung, und sie gewinnen auch gerichtliche Auseinandersetzungen in 95% der Fälle, denn es ist allgemein anerkannt, dass das V-Hosten für kritische Daten aus oben genannten Gründen mindestens als "fahrlässig" - wenn nicht sogar als "grob fahrlässig" - gilt.
Wenn ein Kunde darauf besteht, kritische Infrastruktur auf einen V-Server auszulagern, habe ich einen Kunden weniger. Sowas betreue ich nicht, für absehbare Unfälle gehe ich nicht in den Schuldturm.
In dem hier diskutierten Fall komme ich zu folgendem Schluss: Wenn die Daten personenbezogen oder sonstwie kritisch sind: Finger weg von virtuellen Servern. Wenn die Daten unkritisch sind, richten weder Meltdown&Co noch andere Sicherheitsbugs bösartige Schäden an und sind schlimmstenfall ärgerlich, lästig und führen u.U. zum Totalausfall. Zumindest wird aber niemand persönlich oder geschäftlich geschädigt.
Regelmäßig gibt's dann von mir den Crashkurs, wer wann wo wie Zugriff auf die ausgelagerten Daten hat. Nach wie vor gilt der alte Grundsatz: Wer physischen Zugriff hat, beherrscht das Gerät. Bspw. schützt mich eine LUKS-Verschlüsselung nicht, wenn die Kiste läuft und alle LUKS-Platten für das installierte System offen wie Scheunentore sind.
Das Ganze potenziert sich auf virtuellen Servern, nicht nur in Bezug auf Meltdown und Co, sondern ganz allgemein wegen kritischer Bugs, die immer mal auftauchen können, insbesondere auf dem Host-System, auf das man als Nutzer eines V-Servers gar keinen Einfluss hat.
Und da sind wir dann beim Thema Verantwortung und Haftbarkeit: Wenn auf meinem Server was schief geht, kann ich die Sache selbstverantwortet fixen, nicht jedoch wenn der Betreiber eines Host seinen Job nicht ordentlich macht. In dem Fall hafte auch ich für Fehler des Hosters. Versicherungen haben da eine ganz klare Haltung, und sie gewinnen auch gerichtliche Auseinandersetzungen in 95% der Fälle, denn es ist allgemein anerkannt, dass das V-Hosten für kritische Daten aus oben genannten Gründen mindestens als "fahrlässig" - wenn nicht sogar als "grob fahrlässig" - gilt.
Wenn ein Kunde darauf besteht, kritische Infrastruktur auf einen V-Server auszulagern, habe ich einen Kunden weniger. Sowas betreue ich nicht, für absehbare Unfälle gehe ich nicht in den Schuldturm.
In dem hier diskutierten Fall komme ich zu folgendem Schluss: Wenn die Daten personenbezogen oder sonstwie kritisch sind: Finger weg von virtuellen Servern. Wenn die Daten unkritisch sind, richten weder Meltdown&Co noch andere Sicherheitsbugs bösartige Schäden an und sind schlimmstenfall ärgerlich, lästig und führen u.U. zum Totalausfall. Zumindest wird aber niemand persönlich oder geschäftlich geschädigt.
Der Hauptunterschied zwischen etwas, was möglicherweise kaputtgehen könnte und etwas, was unmöglich kaputtgehen kann, besteht darin, dass sich bei allem, was unmöglich kaputtgehen kann, falls es doch kaputtgeht, normalerweise herausstellt, dass es unmöglich zerlegt oder repariert werden kann.
Douglas Adams
Douglas Adams
- Blackbox
- Beiträge: 4289
- Registriert: 17.09.2008 17:01:20
- Lizenz eigener Beiträge: GNU Free Documentation License
Re: Spectre/Meltdown Spec store bypass: vulnerable
Und es bestätigt meine Annahme, dass diese Situation hausgemacht ist und die Versäumnisse selbst anzurechnen sind.Xela69 hat geschrieben:14.07.2022 13:04:12Preiswerte virtuelle Server, die sicherer sein koennten, wenn diese eine Luecke geschlossen ist, was offensichtlich machbar ist.
Es gäbe nun mindestens 3 Möglichkeiten, wie zu reagieren ist.
Aber anstatt dies zu machen, versuchst du hier zwanghaft eine Diskussion belebt zu halten, obwohl klar ist, dass dir hier niemand helfen können wird.
Deswegen halte ich diese Aktion immer noch für eine Scheindiskussion.
Und was hindert dich, eine Lösung im Sinne deiner Kunden und deines erhöhten Sicherheitsbedürfnisses umzusetzen, anstatt hier davon überzeugen zu wollen, dass du und dein Thema wirklich wichtig (b)ist?Xela69 hat geschrieben:14.07.2022 13:04:12Natuerlich kann man das alles umgehen, wenn man einen sehr viel teureren dedizierten Server kauft.
Es zwingt dich doch niemand (außer vielleicht extremer Geiz) deinen Service bei einem Billighoster bereit zu stellen, um dich dann zu beschweren, dass dieser einen schlechten Job macht.Xela69 hat geschrieben:14.07.2022 13:04:12Mir geht es aber gerade um eine breite Loesung, die sich viele leisten koennen.
Auch aus dieser Misere gäbe es einen sehr einfachen Weg, aber du willst lieber ein Thema welches erschöpfend besprochen wurde, mit aller Gewalt künstlich weiter diskutieren, obwohl dir hier niemand wirklich helfen können wird.
Dann sollte es doch ein Leichtes für dich sein, zu erklären, wie eine Diskussion in einem Distributionsforum dazu führt, dass a) dieses Problem aus der Welt geschafft wird und b) damit deine Fehlentscheidungen rückgängig gemacht werden?Xela69 hat geschrieben:14.07.2022 13:04:12Wieso das dann bei Dir oder auch bei Blackbox dazu fuehrt alle moeglichen Gruende anzufuehren, warum mein Beitrag mit meinen Gefuehlen oder meinem Qualitaetsniveau zu tun hat, entschliesst sich mir.
So unterschiedlich können Perspektiven sein, ich verstehe seine Haltung sehr gut!Xela69 hat geschrieben:14.07.2022 13:04:12Dass du nun in die gleiche Kerbe haust "Loesungen sind angeboten worden" wundert mich schon sehr.
Vielleicht sollte das Verständnisnissystem nachjustiert werden?
Nicht nur vielleicht, sondern auch noch die falsche Community angesprochen.
Wieso sollten wir deinem schlechten Beispiel folgen und damit die Scheindiskussion weiter befeuern?Xela69 hat geschrieben:14.07.2022 13:04:12Bitte setz mir doch einen Link, wo tatsaechlich Loesungen angeboten worden sind.
Sollte das der erste wahre Gedanke dieser Scheindiskussion sein? - Diskussion ist also wichtiger, als endlich zu handeln!Xela69 hat geschrieben:14.07.2022 13:04:12Ansonsten kann man bei der zunehmenden Anzahl von Views ja nicht davon ausgehen, dass das Thema sich totgelaufen hat.
Merkst du eigentlich, dass du dieses Thema immer noch im falschen Kanal groß machen möchtest?Xela69 hat geschrieben:14.07.2022 13:04:12Aus meiner Sicht, mit meinem absolut legitimen Anliegen macht es absolut Sinn diesen Threat offenzuhalten.
Eigenbau PC: Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Desktop PC: Dell Inspiron 530 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Notebook: TUXEDO BU1406 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Alles Minimalinstallationen und ohne sudo/PA/PW.
Rootserver: Rocky Linux 9.3 - Kernel: 5.14
Freie Software unterstützen, Grundrechte stärken!
Desktop PC: Dell Inspiron 530 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Notebook: TUXEDO BU1406 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Alles Minimalinstallationen und ohne sudo/PA/PW.
Rootserver: Rocky Linux 9.3 - Kernel: 5.14
Freie Software unterstützen, Grundrechte stärken!
Re: Spectre/Meltdown Spec store bypass: vulnerable
Und da sind wir wieder... Ist ja bei den Populisten unserer Zeit sehr beliebt...
Herabsetzen des Anderen durch abstruse Behauptungen.
Ist doch ein wenig zu durchsichtig.
Wieso wird anstellezuhelfen und die Datensicherheit zu erhoehen, so viel, auch die Zuhilfenahme dieser rhetorischen Populisten Argumentationstricks, versucht, anstelle bei einer Loesung mitzuhelfen?
Sinnfreier Beitrag!
Hoert sich an wie ein Sprachrohr derer, die auch für kleinere Unternehmen gute Sicherheitsloesungen verhindern wollen oder nur die teuren Loesungen realisiert sehen wollen.
Jeder sicherer Server, auch die preiswerten, unterstuetzt das Recht auf Sicherheit der Daten.
Da es technisch moeglich ist, sollten auch die virtuellen preiswerten Sever vollstaendig sicher sein. Bereits BEKANNTE Luecken muessen geschlossen werden, und nicht bewusst ignoriert werden.
Und nochmal...
Ich habe den Threat eroeffnet, um Loesungsvorschlaege zu erhalten.
Wer nichts beizutragen hat, darf sich gerne in vornehmer Zurueckhaltung ueben.
Und ich weiss ja nicht was Du mit Deinem Beitrag zum "uns" meinst.
Fuehl Dich doch einfach nicht angesprochen.
@Livingston: Super vielen Dank für diesen konstruktiven und guten Beitrag!
Du schreibst, dass wer physischen Zugriff auf die Maschinen hat, beherrscht das Geraet. Stehen denn die dedizierten Server nicht auch im Datacenter? Sicherlich doch (bis auf ein paar Ausnahmen). Eventuell auch im gleichen Rack, wo die Server fuer die virtuellen Instanzen stehen. Oder man leistet sich gleich ein ganzes Rack fuer sich selbst. Dann ist es halt das Rack daneben.
Bei der Festplattenverschluesselung hat sich nun TCG Opal 2.0 zum Industriestandard durchgesetzt (https://teejeetech-com.translate.goog/2 ... r_pto=wapp), welches die Hardwareverschluesselung beherrschbar macht und dauerhaft aktiv ist ("always on").
Bei der Haftbarkeit, Versicherungen, haben auch hier sich die Zeiten zum positiven veraendert. Mittlerweile bieten Versicherungen Policen fuer ISP's an, die ihre Daten auch auf virtuellen Instanzen ablegen, sprich in der Cloud, und gegen Verlust versichert sind.
Kommen wir zu den kritischen Daten. Was als kritische Daten definiert wird, dass muss jedes Unternehmen fuer sich selbst abstimmen. Sicherlich, da gebe ich Dir auch Recht, bei Behoerden/Organisationen mit sehr sensiblen PII (Persönlich identifizierbare Informationen) sollten die Daten besonders geschuetzt werden und auf ihren eigenen Maschinen abgelegt werden. Allerdings bei KMU (kleine oder mittlere Unternehmen), die Webseiten mit eCommerce, normalem E-Mailverkehr arbeiten, warum sollten diese keine Virtuellen Privaten Server benutzen koennen? Und warum sollten diese dann nicht vor bekannte Schwachstellen mitigiert werden?
Wenn ein Cloud-Provider damit wirbt, dass er ISO 27001 zertifiziert ist, dann sollte man davon ausgehen, dass die Server vollstaendig gegen alle bekannten Schwachstellen mitigiert sind.
Beispiel:
Einer der groessten Cloud-Anbieter, welcher auch ISO 27001 zertifiziert ist und damit wirbt, bietet Virtuelle Private Server an. Die Hosts wurden seinerseits offensichtlich mitigiert, da die meisten Kernelparameter gegen Spectre/Meltdown richtig gesetzt wurden. Allerdings nicht gegen Spec store bypass. Er wurde darauf hingewiesen, weigert sich allerdings diesen einen einzigen Kernelparameter richtig zu setzen. Was wuerdest Du tun?
Herabsetzen des Anderen durch abstruse Behauptungen.
Ist doch ein wenig zu durchsichtig.
Wieso wird anstellezuhelfen und die Datensicherheit zu erhoehen, so viel, auch die Zuhilfenahme dieser rhetorischen Populisten Argumentationstricks, versucht, anstelle bei einer Loesung mitzuhelfen?
Sinnfreier Beitrag!
Hoert sich an wie ein Sprachrohr derer, die auch für kleinere Unternehmen gute Sicherheitsloesungen verhindern wollen oder nur die teuren Loesungen realisiert sehen wollen.
Jeder sicherer Server, auch die preiswerten, unterstuetzt das Recht auf Sicherheit der Daten.
Da es technisch moeglich ist, sollten auch die virtuellen preiswerten Sever vollstaendig sicher sein. Bereits BEKANNTE Luecken muessen geschlossen werden, und nicht bewusst ignoriert werden.
Und nochmal...
Ich habe den Threat eroeffnet, um Loesungsvorschlaege zu erhalten.
Wer nichts beizutragen hat, darf sich gerne in vornehmer Zurueckhaltung ueben.
Und ich weiss ja nicht was Du mit Deinem Beitrag zum "uns" meinst.
Fuehl Dich doch einfach nicht angesprochen.
@Livingston: Super vielen Dank für diesen konstruktiven und guten Beitrag!
Du schreibst, dass wer physischen Zugriff auf die Maschinen hat, beherrscht das Geraet. Stehen denn die dedizierten Server nicht auch im Datacenter? Sicherlich doch (bis auf ein paar Ausnahmen). Eventuell auch im gleichen Rack, wo die Server fuer die virtuellen Instanzen stehen. Oder man leistet sich gleich ein ganzes Rack fuer sich selbst. Dann ist es halt das Rack daneben.
Bei der Festplattenverschluesselung hat sich nun TCG Opal 2.0 zum Industriestandard durchgesetzt (https://teejeetech-com.translate.goog/2 ... r_pto=wapp), welches die Hardwareverschluesselung beherrschbar macht und dauerhaft aktiv ist ("always on").
Bei der Haftbarkeit, Versicherungen, haben auch hier sich die Zeiten zum positiven veraendert. Mittlerweile bieten Versicherungen Policen fuer ISP's an, die ihre Daten auch auf virtuellen Instanzen ablegen, sprich in der Cloud, und gegen Verlust versichert sind.
Kommen wir zu den kritischen Daten. Was als kritische Daten definiert wird, dass muss jedes Unternehmen fuer sich selbst abstimmen. Sicherlich, da gebe ich Dir auch Recht, bei Behoerden/Organisationen mit sehr sensiblen PII (Persönlich identifizierbare Informationen) sollten die Daten besonders geschuetzt werden und auf ihren eigenen Maschinen abgelegt werden. Allerdings bei KMU (kleine oder mittlere Unternehmen), die Webseiten mit eCommerce, normalem E-Mailverkehr arbeiten, warum sollten diese keine Virtuellen Privaten Server benutzen koennen? Und warum sollten diese dann nicht vor bekannte Schwachstellen mitigiert werden?
Wenn ein Cloud-Provider damit wirbt, dass er ISO 27001 zertifiziert ist, dann sollte man davon ausgehen, dass die Server vollstaendig gegen alle bekannten Schwachstellen mitigiert sind.
Beispiel:
Einer der groessten Cloud-Anbieter, welcher auch ISO 27001 zertifiziert ist und damit wirbt, bietet Virtuelle Private Server an. Die Hosts wurden seinerseits offensichtlich mitigiert, da die meisten Kernelparameter gegen Spectre/Meltdown richtig gesetzt wurden. Allerdings nicht gegen Spec store bypass. Er wurde darauf hingewiesen, weigert sich allerdings diesen einen einzigen Kernelparameter richtig zu setzen. Was wuerdest Du tun?
Zuletzt geändert von Xela69 am 05.11.2022 14:00:07, insgesamt 1-mal geändert.
- Livingston
- Beiträge: 1813
- Registriert: 04.02.2007 22:52:25
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: 127.0.0.1
Re: Spectre/Meltdown Spec store bypass: vulnerable
Das sind eine Menge Fragen. Zunächst mal möchte ich klarstellen, dass ich nicht pauschal externe Dienste ablehne. Im Gegenteil: Gute Hoster schützen z.B. wirksam vor (D)DOS-Attacken, stecken generell Netzwerkprobleme besser weg, als ein eigener Büro-Server, der durch Buddelarbeiten auf der Straße vor der Haustür mal eben abgenabelt wird.
Um das Ganze mal einzugrenzen: Ich spreche hier von kleinen und mittelgroßen Betrieben: Arztpraxen, mittelständische Produzenten, manche mit, manche ohne "Straßenverkauf", dazu noch ein paar soziale Einrichtungen. Mit anderen Worten Leute und Einrichtungen, die sich nicht das volle Programm leisten können oder wollen. D.h. es geht in den Szenarien nicht um die vollen, dicken Verträge, wo Hoster für den Alltagsbetrieb per Vertrag haftbar sind, sondern um die gemeinsame Entscheidung meiner Kunden und mir, einen Teil der Abläufe auszulagern.
Einfaches Beispiel: Ein Webshop, der sich öffentlich über einen externen Server präsentiert, dessen sensible Daten aber "zu Hause" bleiben. D.h. es kommt immer zu einer technischen Trennung zwischen Außendarstellung, Weboberfläche etc. und den weitergeleiteten, zu filternden Daten im abgeschotteten Firmenumfeld.
In meinem Arbeitsumfeld bedeutet das konkret: ISO 27001 und Co. sind vielleicht ein nettes Bonmot, aber verantwortlich bin und bleibe ich - und zwar für alle Prozesse, die ablaufen. Und das ist auch gut so, denn wenn ich einen dicken Vertrag mit einem Hoster vermittel, der eine Komplettbetreuung incl. der von Dir angesprochenen Sicherheiten anbietet, dann braucht mein Kunde meine Dienstleistung künftig nicht mehr, der übernimmt dann tatsächlich alles, und wenn er gut und tatsächlich vertrauenswürdig ist, dann macht er das auch und wird werbewirksam darauf hinweisen, welche Zertifikate und Beurteilungen er gesammelt hat. Aber das ist dann eben ein völlig anderer Geschäftsbereich, mit dem ich dann auch nichts mehr zu tun habe.
Zur Frage, ob ein Cloudbetreiber "save" ist, wenn er mit Zertifizierungen wirbt, kann man nur sagen: Na hoffentlich! Da zu den oben genannten "dicken Verträgen" eben auch die volle Haftung des Cloud-Providers gehört, kann man davon ausgehen, dass dieser Geschäftsbereich relativ gut abgesichert ist.
Was das in "meinem" Preissegment bedeutet, kann ich leider daraus nicht ableiten, also gehe ich auf Nummer Sicher und arbeite so, als wäre alles Externe offen wie ein Scheunentor. Daher ist für mich die Frage von Meltdown-Mitigation & Co an dieser Stelle zweitrangig.
EDIT: Nachtrag
Ich will niemandem etwas aufzwingen, aber für mich persönlich gilt: "Prinzip Hoffnung" funktioniert nicht als Ausrede, wenn ein externer Anbieter Mist baut. Man muss bei Cloudanbietern/Hostern unterscheiden zwischen Selbstdarstellung/Waschmittelwerbung und klaren, eindeutigen Verträgen. Es geht also um den feinen Unterschied zwischen Privat- und Geschäftskundenverträgen. Wenn man sich die Preisunterschiede zwischen diesen beiden Bereichen ansieht, kommt man zu dem Schluss, dass es sich wohl nicht nur um "Kunst"-Preise handelt, sondern auch inhaltlich etwas dahintersteckt.
Um das Ganze mal einzugrenzen: Ich spreche hier von kleinen und mittelgroßen Betrieben: Arztpraxen, mittelständische Produzenten, manche mit, manche ohne "Straßenverkauf", dazu noch ein paar soziale Einrichtungen. Mit anderen Worten Leute und Einrichtungen, die sich nicht das volle Programm leisten können oder wollen. D.h. es geht in den Szenarien nicht um die vollen, dicken Verträge, wo Hoster für den Alltagsbetrieb per Vertrag haftbar sind, sondern um die gemeinsame Entscheidung meiner Kunden und mir, einen Teil der Abläufe auszulagern.
Einfaches Beispiel: Ein Webshop, der sich öffentlich über einen externen Server präsentiert, dessen sensible Daten aber "zu Hause" bleiben. D.h. es kommt immer zu einer technischen Trennung zwischen Außendarstellung, Weboberfläche etc. und den weitergeleiteten, zu filternden Daten im abgeschotteten Firmenumfeld.
In meinem Arbeitsumfeld bedeutet das konkret: ISO 27001 und Co. sind vielleicht ein nettes Bonmot, aber verantwortlich bin und bleibe ich - und zwar für alle Prozesse, die ablaufen. Und das ist auch gut so, denn wenn ich einen dicken Vertrag mit einem Hoster vermittel, der eine Komplettbetreuung incl. der von Dir angesprochenen Sicherheiten anbietet, dann braucht mein Kunde meine Dienstleistung künftig nicht mehr, der übernimmt dann tatsächlich alles, und wenn er gut und tatsächlich vertrauenswürdig ist, dann macht er das auch und wird werbewirksam darauf hinweisen, welche Zertifikate und Beurteilungen er gesammelt hat. Aber das ist dann eben ein völlig anderer Geschäftsbereich, mit dem ich dann auch nichts mehr zu tun habe.
Zur Frage, ob ein Cloudbetreiber "save" ist, wenn er mit Zertifizierungen wirbt, kann man nur sagen: Na hoffentlich! Da zu den oben genannten "dicken Verträgen" eben auch die volle Haftung des Cloud-Providers gehört, kann man davon ausgehen, dass dieser Geschäftsbereich relativ gut abgesichert ist.
Was das in "meinem" Preissegment bedeutet, kann ich leider daraus nicht ableiten, also gehe ich auf Nummer Sicher und arbeite so, als wäre alles Externe offen wie ein Scheunentor. Daher ist für mich die Frage von Meltdown-Mitigation & Co an dieser Stelle zweitrangig.
EDIT: Nachtrag
Ich will niemandem etwas aufzwingen, aber für mich persönlich gilt: "Prinzip Hoffnung" funktioniert nicht als Ausrede, wenn ein externer Anbieter Mist baut. Man muss bei Cloudanbietern/Hostern unterscheiden zwischen Selbstdarstellung/Waschmittelwerbung und klaren, eindeutigen Verträgen. Es geht also um den feinen Unterschied zwischen Privat- und Geschäftskundenverträgen. Wenn man sich die Preisunterschiede zwischen diesen beiden Bereichen ansieht, kommt man zu dem Schluss, dass es sich wohl nicht nur um "Kunst"-Preise handelt, sondern auch inhaltlich etwas dahintersteckt.
Der Hauptunterschied zwischen etwas, was möglicherweise kaputtgehen könnte und etwas, was unmöglich kaputtgehen kann, besteht darin, dass sich bei allem, was unmöglich kaputtgehen kann, falls es doch kaputtgeht, normalerweise herausstellt, dass es unmöglich zerlegt oder repariert werden kann.
Douglas Adams
Douglas Adams
Re: Spectre/Meltdown Spec store bypass: vulnerable
Du meinst Hybride Setups, bei denen die Daten getrennt von der Edge sind. Es ist sehr ratsam die Daten von der Cloud nachts auf einen Backupserver im Office oder daheim zu sichern. Dann sind diese in greifbarer Naehe und gehen nicht verloren. Wie beim Beispiel eines Brandes eines Datacenters in Europa, Strassburg, im Jahr 2021 (https://www.storage-insider.de/ovh-gros ... a-1008399/).
Und Du bist sicherlich kein Einzelfall, der Arztpraxen, mittelstaendische Produzenten, sogar soziale Einrichtungen, Anwaelten und Kanzleien mit sehr sensiblen PII diese hybriden Setups anbietet und implementiert, was ein gutes Geschaeftsmodell ist.
Diese Daten liegen nun verschluesselt auf einem Server im Buero, der Edge-Server liegt in der Cloud, auf Grund der sehr guten Abwehrtechniken, wie Anti-DDOS (Anti-Distributed Denial-of-Service), Vermeidung von Netzwerkproblehmen und sonstigen Vorteilen und holt sich die Daten vom Buero-Server ab.
Die Edge-Server, wir reden hier von zigtausenden und mehr Servern, liegen nun konsolidiert in grossen Datenzentren. Und jetzt kommt Spec store bypass zum Einsatz. All diese Daten koennen mittels Spec store bypass mit einfachen Mitteln, wenn nicht schon automatisiert, abgegriffen werden. Und schlimmstenfalls mittels einer KI (Kuenstliche Intelligenz) ausgewertet werden, was hoch wahrscheinlich schon Realitaet ist. Betroffen sind alle Inhalte, ob privater oder geschaeftlicher Natur. Welch ein gigantischer Impact und Eingriff in die Privatsphaere!
Und hier muss der Kernelparameter von den Cloud-Providern richtig gesetzt werden, was nun seit 2019 moeglich und die einzige Loesung ist, damit Spec store bypass entschaerft ist.
Ob das mit Microsoft Produkten auf den Hosts geht, bezweifel ich sehr, da der Kernel nicht freigegeben ist. Aber mit Sicherheit im Open Stack, da hier KVM (Kernel Virtual Machine) im Einsatz und Open Source ist!
Eine weitere Herausforderung der wehrhaften Demokratie hier in Europa, diesmal im Cyberraum.
Nachtrag:
Hardware vulnerabilities (Linux Kernel): https://docs.kernel.org/admin-guide/hw-vuln/index.html
Leitfaden zum Schutz vor spekulativen ausführungsseitigen Channelsicherheitsanfälligkeiten bei Windows: https://support.microsoft.com/de-de/top ... 47a0ab3385
Und Du bist sicherlich kein Einzelfall, der Arztpraxen, mittelstaendische Produzenten, sogar soziale Einrichtungen, Anwaelten und Kanzleien mit sehr sensiblen PII diese hybriden Setups anbietet und implementiert, was ein gutes Geschaeftsmodell ist.
Diese Daten liegen nun verschluesselt auf einem Server im Buero, der Edge-Server liegt in der Cloud, auf Grund der sehr guten Abwehrtechniken, wie Anti-DDOS (Anti-Distributed Denial-of-Service), Vermeidung von Netzwerkproblehmen und sonstigen Vorteilen und holt sich die Daten vom Buero-Server ab.
Die Edge-Server, wir reden hier von zigtausenden und mehr Servern, liegen nun konsolidiert in grossen Datenzentren. Und jetzt kommt Spec store bypass zum Einsatz. All diese Daten koennen mittels Spec store bypass mit einfachen Mitteln, wenn nicht schon automatisiert, abgegriffen werden. Und schlimmstenfalls mittels einer KI (Kuenstliche Intelligenz) ausgewertet werden, was hoch wahrscheinlich schon Realitaet ist. Betroffen sind alle Inhalte, ob privater oder geschaeftlicher Natur. Welch ein gigantischer Impact und Eingriff in die Privatsphaere!
Und hier muss der Kernelparameter von den Cloud-Providern richtig gesetzt werden, was nun seit 2019 moeglich und die einzige Loesung ist, damit Spec store bypass entschaerft ist.
Ob das mit Microsoft Produkten auf den Hosts geht, bezweifel ich sehr, da der Kernel nicht freigegeben ist. Aber mit Sicherheit im Open Stack, da hier KVM (Kernel Virtual Machine) im Einsatz und Open Source ist!
Eine weitere Herausforderung der wehrhaften Demokratie hier in Europa, diesmal im Cyberraum.
Nachtrag:
Hardware vulnerabilities (Linux Kernel): https://docs.kernel.org/admin-guide/hw-vuln/index.html
Leitfaden zum Schutz vor spekulativen ausführungsseitigen Channelsicherheitsanfälligkeiten bei Windows: https://support.microsoft.com/de-de/top ... 47a0ab3385
Zuletzt geändert von Xela69 am 26.07.2022 14:10:31, insgesamt 1-mal geändert.
- Blackbox
- Beiträge: 4289
- Registriert: 17.09.2008 17:01:20
- Lizenz eigener Beiträge: GNU Free Documentation License
Re: Spectre/Meltdown Spec store bypass: vulnerable
Mich würde ja immer noch interessieren, was dein Hoster gesagt hat, als du an diesen mit deinem Anliegen zum 2. Mal herangetreten bist?
Genügend Ratschläge hast du schließlich hier im Forum erhalten.
Genügend Ratschläge hast du schließlich hier im Forum erhalten.
Eigenbau PC: Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Desktop PC: Dell Inspiron 530 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Notebook: TUXEDO BU1406 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Alles Minimalinstallationen und ohne sudo/PA/PW.
Rootserver: Rocky Linux 9.3 - Kernel: 5.14
Freie Software unterstützen, Grundrechte stärken!
Desktop PC: Dell Inspiron 530 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Notebook: TUXEDO BU1406 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Alles Minimalinstallationen und ohne sudo/PA/PW.
Rootserver: Rocky Linux 9.3 - Kernel: 5.14
Freie Software unterstützen, Grundrechte stärken!
Re: Spectre/Meltdown Spec store bypass: vulnerable
Der Support wurde mehrfach von mir darauf hingewiesen, spaeter dann zusammen mit den Ingenieuren vom Plesk Support, welche sich dann zurueckgezogen haben, wie im Inzidenz-Report beschrieben.
- Blackbox
- Beiträge: 4289
- Registriert: 17.09.2008 17:01:20
- Lizenz eigener Beiträge: GNU Free Documentation License
Re: Spectre/Meltdown Spec store bypass: vulnerable
JaNee iss klar ...
Dieses Manöver ist so durchschaubar und war vorherzusehen!
Dieses Manöver ist so durchschaubar und war vorherzusehen!
Eigenbau PC: Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Desktop PC: Dell Inspiron 530 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Notebook: TUXEDO BU1406 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Alles Minimalinstallationen und ohne sudo/PA/PW.
Rootserver: Rocky Linux 9.3 - Kernel: 5.14
Freie Software unterstützen, Grundrechte stärken!
Desktop PC: Dell Inspiron 530 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Notebook: TUXEDO BU1406 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Alles Minimalinstallationen und ohne sudo/PA/PW.
Rootserver: Rocky Linux 9.3 - Kernel: 5.14
Freie Software unterstützen, Grundrechte stärken!
Re: Spectre/Meltdown Spec store bypass: vulnerable
Dear CERT-EU Team
Thank you for the information.
Kindly be informed that the BIOS of the hosts @cloud-providers is set to 'Legacy mode'. Correct would be 'UEFI mode'. There is an SMBIOS 2.8 in use and UEFI is possible according to the specifications (https://uefi.org/specifications). The UEFI mode excludes a rootkit in the MBR. When the kernel parameters are set correctly and UEFI BIOS is enabled, I don't see any more problems regarding the cloud-providers.
I hope you can still bring that into the discussion.
I am looking forward.
Best regards
https://nvlpubs.nist.gov/nistpubs/Legac ... 00-147.pdf
https://nvlpubs.nist.gov/nistpubs/Speci ... 00-193.pdf
On 2022-07-25 16:53, CERT-EU Services wrote:
Dear xxx,
Thank you for the information.
We need some time to discuss the issue internally and we will come
back to you as soon as we have news or questions.
Kind regards,
--
CERT-EU (https://cert.europa.eu)
Phone: +32.2.2990005 / e-mail: services@cert.europa.eu
PGP KeyID 0x5DDA8E13
FP: C9B2 0BAB 2C37 35AD FF79 7949 AFBD 579A 5DDA 8E13
Privacy statement:
https://cert.europa.eu/cert/plaineditio ... ivacy.html
Thank you for the information.
Kindly be informed that the BIOS of the hosts @cloud-providers is set to 'Legacy mode'. Correct would be 'UEFI mode'. There is an SMBIOS 2.8 in use and UEFI is possible according to the specifications (https://uefi.org/specifications). The UEFI mode excludes a rootkit in the MBR. When the kernel parameters are set correctly and UEFI BIOS is enabled, I don't see any more problems regarding the cloud-providers.
I hope you can still bring that into the discussion.
I am looking forward.
Best regards
Code: Alles auswählen
Linux vps-xxx 5.15.39-2-pve #1 SMP PVE 5.15.39-2 ... x86_64
root@vps-xxx:~# dmidecode -t bios
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 2.8 present.
Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
Vendor: SeaBIOS
Version: 2:1.10.2-58953eb7
Release Date: 04/01/2014
Address: 0xE8000
Runtime Size: 96 kB
ROM Size: 64 kB
Characteristics:
BIOS characteristics not supported
Targeted content distribution is supported
BIOS Revision: 0.0
https://nvlpubs.nist.gov/nistpubs/Speci ... 00-193.pdf
On 2022-07-25 16:53, CERT-EU Services wrote:
Dear xxx,
Thank you for the information.
We need some time to discuss the issue internally and we will come
back to you as soon as we have news or questions.
Kind regards,
--
CERT-EU (https://cert.europa.eu)
Phone: +32.2.2990005 / e-mail: services@cert.europa.eu
PGP KeyID 0x5DDA8E13
FP: C9B2 0BAB 2C37 35AD FF79 7949 AFBD 579A 5DDA 8E13
Privacy statement:
https://cert.europa.eu/cert/plaineditio ... ivacy.html
Zuletzt geändert von Xela69 am 01.08.2022 12:48:58, insgesamt 2-mal geändert.
- Blackbox
- Beiträge: 4289
- Registriert: 17.09.2008 17:01:20
- Lizenz eigener Beiträge: GNU Free Documentation License
Re: Spectre/Meltdown Spec store bypass: vulnerable
Don't feed the …
Dann bist du ja bald save!
Ganz bestimmt, versprochen. - Ehrenwort!
Dann bist du ja bald save!
Ganz bestimmt, versprochen. - Ehrenwort!
Eigenbau PC: Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Desktop PC: Dell Inspiron 530 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Notebook: TUXEDO BU1406 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Alles Minimalinstallationen und ohne sudo/PA/PW.
Rootserver: Rocky Linux 9.3 - Kernel: 5.14
Freie Software unterstützen, Grundrechte stärken!
Desktop PC: Dell Inspiron 530 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Notebook: TUXEDO BU1406 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Alles Minimalinstallationen und ohne sudo/PA/PW.
Rootserver: Rocky Linux 9.3 - Kernel: 5.14
Freie Software unterstützen, Grundrechte stärken!
Re: Spectre/Meltdown Spec store bypass: vulnerable
Gaia-X
Eine Cloud für digitale Souveränität in Europa
Executive Summary
Um im digitalen Raum unabhängig und selbstbestimmt handeln und entscheiden zu können, benötigen Unternehmen digitale Souveränität. Diese ist aber nicht immer selbstverständlich, beispielsweise beim Einsatz von Clouds, deren Anbieter ihren Hauptsitz nicht innerhalb der EU haben und somit auf einer anderen Rechtsprechung im Hinblick auf Datenschutz basieren.
Das Projekt Gaia-X setzt hier an und möchte ergänzend ein europäisches Angebot für eine DSGVO-konforme Dateninfrastruktur schaffen. Da Gaia-X die Datensouveränität von Unternehmen stärken soll, ist ein zentraler Aspekt der Einsatz von Open Source Software.
https://get.plusserver.com/whitepaper-gaia-x
Eine Cloud für digitale Souveränität in Europa
Executive Summary
Um im digitalen Raum unabhängig und selbstbestimmt handeln und entscheiden zu können, benötigen Unternehmen digitale Souveränität. Diese ist aber nicht immer selbstverständlich, beispielsweise beim Einsatz von Clouds, deren Anbieter ihren Hauptsitz nicht innerhalb der EU haben und somit auf einer anderen Rechtsprechung im Hinblick auf Datenschutz basieren.
Das Projekt Gaia-X setzt hier an und möchte ergänzend ein europäisches Angebot für eine DSGVO-konforme Dateninfrastruktur schaffen. Da Gaia-X die Datensouveränität von Unternehmen stärken soll, ist ein zentraler Aspekt der Einsatz von Open Source Software.
https://get.plusserver.com/whitepaper-gaia-x
Re: Spectre/Meltdown Spec store bypass: vulnerable
Whitepaper gegen "Business E-Mail"... das ist nichts anderes als Kundenfang. Noch mehr Augenwischerei...
Jesus saves. Buddha does incremental backups.
Windows ist doof, Linux funktioniert nicht • Don't break debian! • Wie man widerspricht
Windows ist doof, Linux funktioniert nicht • Don't break debian! • Wie man widerspricht
Re: Spectre/Meltdown Spec store bypass: vulnerable
Guter Einwurf Trex! Es faengt an konstruktiv zu werden. Danke Dir!
Habe mir mal die Muehe gemacht und die virtuellen Instanzen von einem Cloud-Provider, welcher momentan dem Gaia-X Projekt angehoert und von einem Cloud-Provider, der aus dem Gaia-X Projekt im vorigen Jahr ausgestiegen ist, zu vergleichen (Stand heute):
Gaia-X Cloud-Provider:
Aus dem Gaia-X Projekt ausgestiegener Cloud-Provider:
Beim Gaia-X Projekt besteht offensichtlich Handlungsbedarf!
https://www.youtube.com/watch?v=8flz4zZ ... T&index=17
Habe mir mal die Muehe gemacht und die virtuellen Instanzen von einem Cloud-Provider, welcher momentan dem Gaia-X Projekt angehoert und von einem Cloud-Provider, der aus dem Gaia-X Projekt im vorigen Jahr ausgestiegen ist, zu vergleichen (Stand heute):
Gaia-X Cloud-Provider:
Code: Alles auswählen
Vulnerability Itlb multihit: KVM: Mitigation: VMX disabled
Vulnerability L1tf: Mitigation; PTE Inversion; VMX conditional cache flushes, SMT disabled
Vulnerability Mds: Mitigation; Clear CPU buffers; SMT Host state unknown
Vulnerability Meltdown: Mitigation; PTI
Vulnerability Mmio stale data: Not affected
Vulnerability Retbleed: Not affected
Vulnerability Spec store bypass: Vulnerable
Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2: Mitigation; Retpolines, STIBP disabled, RSB filling
Vulnerability Srbds: Unknown: Dependent on hypervisor status
Vulnerability Tsx async abort: Not affected
Code: Alles auswählen
Vulnerability Itlb multihit: Not affected
Vulnerability L1tf: Not affected
Vulnerability Mds: Not affected
Vulnerability Meltdown: Not affected
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2: Mitigation; Retpolines, IBPB conditional, IBRS_FW, STIBP disabled, RSB filling
Vulnerability Srbds: Not affected
Vulnerability Tsx async abort: Not affected
https://www.youtube.com/watch?v=8flz4zZ ... T&index=17
Zuletzt geändert von Xela69 am 01.08.2022 20:36:27, insgesamt 2-mal geändert.
Re: Spectre/Meltdown Spec store bypass: vulnerable
Es wäre nett von dir, wenn du diesen Part beim nächsten Mal übernimmst und _nicht_ Dinge verbreitest, deren Platz eigentlich die Tonne ist.Xela69 hat geschrieben:30.07.2022 13:13:11Guter Einwurf Trex! Es faengt an konstruktiv zu werden. Danke Dir!
Edit: "TÜV" und Konsorten...
Jesus saves. Buddha does incremental backups.
Windows ist doof, Linux funktioniert nicht • Don't break debian! • Wie man widerspricht
Windows ist doof, Linux funktioniert nicht • Don't break debian! • Wie man widerspricht
Re: Spectre/Meltdown Spec store bypass: vulnerable
Email from Thursday, 15.09.2022
Re: [CERT-EU#2022071242000096] Incidence Report | Various cloud providers
Dear researcher,
we would like to inform you that we contacted cloud support.
After a long discussion, we are still waiting an answer from them and final decision about the issue.
.
.
.
Kind regards,
--
CERT-EU (https://cert.europa.eu)
Phone: +32.2.2990005 / e-mail: services@cert.europa.eu
PGP KeyID 0x5DDA8E13
FP: C9B2 0BAB 2C37 35AD FF79 7949 AFBD 579A 5DDA 8E13
Privacy statement: https://cert.europa.eu/cert/plaineditio ... ivacy.html
Re: [CERT-EU#2022071242000096] Incidence Report | Various cloud providers
Dear researcher,
we would like to inform you that we contacted cloud support.
After a long discussion, we are still waiting an answer from them and final decision about the issue.
.
.
.
Kind regards,
--
CERT-EU (https://cert.europa.eu)
Phone: +32.2.2990005 / e-mail: services@cert.europa.eu
PGP KeyID 0x5DDA8E13
FP: C9B2 0BAB 2C37 35AD FF79 7949 AFBD 579A 5DDA 8E13
Privacy statement: https://cert.europa.eu/cert/plaineditio ... ivacy.html
- Blackbox
- Beiträge: 4289
- Registriert: 17.09.2008 17:01:20
- Lizenz eigener Beiträge: GNU Free Documentation License
Re: Spectre/Meltdown Spec store bypass: vulnerable
Eigenbau PC: Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Desktop PC: Dell Inspiron 530 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Notebook: TUXEDO BU1406 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Alles Minimalinstallationen und ohne sudo/PA/PW.
Rootserver: Rocky Linux 9.3 - Kernel: 5.14
Freie Software unterstützen, Grundrechte stärken!
Desktop PC: Dell Inspiron 530 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Notebook: TUXEDO BU1406 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Alles Minimalinstallationen und ohne sudo/PA/PW.
Rootserver: Rocky Linux 9.3 - Kernel: 5.14
Freie Software unterstützen, Grundrechte stärken!
Re: Spectre/Meltdown Spec store bypass: vulnerable
Oh wow, das ist ja toll - die nehmen das ja richtig ernst!
Jesus saves. Buddha does incremental backups.
Windows ist doof, Linux funktioniert nicht • Don't break debian! • Wie man widerspricht
Windows ist doof, Linux funktioniert nicht • Don't break debian! • Wie man widerspricht
Re: Spectre/Meltdown Spec store bypass: vulnerable
On 2022-09-30 14:37, CERT-EU Services wrote:
Dear Cloud User,
Finally we received an answer from the cloud support:
"xxxcloud is not concerned by CVE-2018-3639 because we do not use affected processors.
For compatibility and resiliency purposes, instances shows generic processors instead of the real processors used to provide the service.
That's why customer may have wrong or inconstant data to do their own risk assessment for that vulnerability."
Maybe you have any comments regarding the answer?
Kind regards, --
CERT-EU (https://cert.europa.eu)
Phone: +32.2.2990005 / e-mail: services@cert.europa.eu
PGP KeyID 0x5DDA8E13
FP: C9B2 0BAB 2C37 35AD FF79 7949 AFBD 579A 5DDA 8E13
Privacy statement: https://www.cert.europa.eu/privacy-policy
Dear Cloud User,
Finally we received an answer from the cloud support:
"xxxcloud is not concerned by CVE-2018-3639 because we do not use affected processors.
For compatibility and resiliency purposes, instances shows generic processors instead of the real processors used to provide the service.
That's why customer may have wrong or inconstant data to do their own risk assessment for that vulnerability."
Maybe you have any comments regarding the answer?
Kind regards, --
CERT-EU (https://cert.europa.eu)
Phone: +32.2.2990005 / e-mail: services@cert.europa.eu
PGP KeyID 0x5DDA8E13
FP: C9B2 0BAB 2C37 35AD FF79 7949 AFBD 579A 5DDA 8E13
Privacy statement: https://www.cert.europa.eu/privacy-policy
Re: Spectre/Meltdown Spec store bypass: vulnerable
This is impossible because: "KVM provides device abstraction but no processor emulation."
https://en.wikipedia.org/wiki/Kernel-ba ... al_Machine
Best regards
https://en.wikipedia.org/wiki/Kernel-ba ... al_Machine
Best regards