Spectre und Meltdown: Intels Sicherheitsteam arbeitet noch immer an Lösungen

20
News Valentin Sattler Als bevorzugte Quelle auf Google hinzufügen
Meltdown und Spectre: Intels Sicherheitsteam arbeitet immer noch an Lösungen
Quelle: Intel

Laut einem Bericht von Wired ist Intel auch weiterhin mit den Auswirkungen der Sicherheitslücken Spectre und Meltdown beschäftigt. In der Vergangenheit wurden Prozessoren demnach lediglich auf Performance optimiert, die inzwischen entdeckten Hardware-Sicherheitslücken erfordern hingegen auch einen Fokus auf die Sicherheit von CPU-Architekturen - das lässt sich nicht immer vereinbaren.

Ein Jahr nach dem Aufkommen der Hardware-Sicherheitslücken Spectre und Meltdown arbeitet Intel als eines der am stärksten betroffenen Unternehmen noch immer an einer Lösung für diese und die danach entdeckten, vergleichbaren Sicherheitslücken. Spectre und Meltdown werden durch Optimierungstechniken von Prozessoren ermöglicht, nämlich die spekulativen Ausführung und die "Out-of-order execution".

Änderungen am Team für eine bessere Herangehensweise

Da es sich um Hardware- und keine Software-Lücken handelt, sind nachträgliche Updates nur bedingt möglich und kosten zum Teil Rechenleistung. Wie aus einem Bericht von Wired hervorgeht, ist bei Intel für die Untersuchung und Problemlösung zum Thema Meltdown/Spectre vor allem ein Team namens STORM (Strategic offensive research and mitigation) verantwortlich.

Intels Sicherheits-Forschungsabteilung besteht aus rund 60 Leuten, rund ein Dutzend davon ist für die Untergruppe STORM tätig. Diese versuchen die Auswirkungen von Sicherheitslücken zu erfassen, wobei Spectre und Meltdown aufgrund der Vielzahl der betroffenen Systeme ein besonderer Fall sind. Zur Behebung arbeitet STORM mit den verschiedenen Produktteams zusammen. Eine vollständige Implementierung der für Spectre und Meltdown erforderlichen Schutzmaßnahmen dauert schätzungsweise vier bis fünf Jahre, erste Anpassungen gibt es aber bereits in den aktuellen Modellen.

Passend dazu: Spectre v5 alias SpectreRSB: Neue CPU-Sicherheitslücke entdeckt

Als Reaktion auf die Sicherheitslücken wurde Intels STORM-Team um mehrere Mitarbeiter erweitert, die von Sicherheits-Beratungsfirmen und Forschungseinrichtungen stammen. Die neuen Mitarbeiter sollten dabei helfen, mit den Problemen besser umzugehen. Das Team arbeitet dabei laut dem Bericht ohnehin sehr frei, was aber auch mit den Anforderungen zusammenhängt: Die betrachteten Sicherheitslücken sind meist noch unbekannt und erfordern dementsprechend neue Herangehensweisen.

Ein besonderes Problem bei Spectre und Meltdown ist laut Jon Masters, Architektur-Fachmann bei Red Hat, dass die Lücken im Kontrast zur Leistung stehen. Eine effektive Behebung kostet ebendiese. Trotzdem hofft er, dass Intel das Thema Sicherheit in Zukunft höher priorisiert. Klar ist aber auch, dass man aller Wahrscheinlichkeit nach auch in Zukunft noch zahlreiche Sicherheitslücken entdecken wird.

20

    • Kommentare (20)

      Zur Diskussion im Forum
      • Von PCGH_Torsten Kokü-Junkie (m/w)
        AW: Spectre und Meltdown: Intels Sicherheitsteam arbeitet noch immer an Lösungen

        Zitat von fotoman
        Es geht nur um JS über de Browser. Oder wer hat heute noch Flash, Silverlight oder gar Java im Browser aktiviet?

        Alle lokalen Angriffe muss der Heimanwender als Einzel-Anwender genauso manuell ausführen wie einen normalen Trojaner. Dass man mittels JS aus dem Adressbereich des Browsers ausbrechen kann, lese ich erstmalig.
        Ich bin mir nicht ganz sicher, wie weit die PoC für JS fortgeschritten sind. Spectre-Angriffe in JS zu schreiben ist deutlich schwerer wegen der zwischengeschalteten Interpreter. Aber wenn wir eins aus Spectre gelernt haben, dann: Nur weil man etwas noch nicht weiß oder es aufwendig erscheint, heißt das noch lange nicht, dass es unmöglich ist und es noch niemand versucht hat.
        Prinzipiell greifen primäre Spectre-Angriffe jedenfalls mit missbrauchtem Target-Code aus dem Adressraum des Targets auf den Adressraum des Targets zu. Solange eine Anwendung nicht geschützt ist, ist ihr Adressraum also in Gefahr – unabhängig davon, in welchem Adressraum der Code des Angreifers läuft. Der Browser selbst ist natürlich eines der attraktivsten Ziele überhaupt und für JS-Angriffe das naheliegenste. Aber wenn man ein Return-Gadget kennt, mit dem man auch via Javascript einen Rückkanal aufbauen kann, dann kann man prinzipiell alles angreifen.

        Zitat
        Hier hat zwar jemand eine "Umgehungslösung" gefunden, die mit ca. einem Bit/Sekunde nun wirklich nicht praxisrelevant ist.
        Overcoming (some) Spectre browser mitigations

        Außerdem ist man dort (wie auch Heise im damaligen Artikel) der Meinung, dass man mit Spectre und JS im Browser nur den Adressbereich des Browsers auslesen kann.
        Dieser Angriff ist in der Tat zu langsam für nennenswerten Nutzen und er beschäftigt sich nur mit Angriffen auf den Adressraum des Browsers. Aber wie kann man ausschließen, dass es weitere Möglichkeiten gibt?

        Zitat
        Früher zu Vaters Zeiten hatten aber allenfalls Großrechner 32 GB Ram und mehr. Wenn ich mit den 500 KByte/s rechne, die ich auf die Schnelle gefunden habe (falls die Zahlen von einem JS-Angriff auf einem großen Xeon stammen und nicht vom C-Code) sind das rund 18 Stunden. Das ganze sicherlich nicht ohne dabei eine direkt sichtbare, hohe Browserauslastung zu generieren, die mir recht schnell auffällt.
        Der physische RAM spielt keine Rolle. Durchsucht werden muss der gesamte virtuelle Adressraum, der war auch schon früher zu groß für einen Komplett-Downland. Aber sobald man ein Element gefunden hat, dass man kennt und dass eine feste Position relativ zu interessanten Daten einnimmt (zum Beispiel weil die angegeriffene Anwendung ihre Programmbestandteile in einer bestimmten Reihenfolge lädt) muss nur noch dieser potenziell interessante Bereich durchsucht werden. So werden aus TiB KiB. Ein großer physischer RAM kann hier sogar von Vorteil sein, wenn er auch intensiv genutzt wird – einen Speer im Heuhaufen findet man schneller als eine Nadel.

        Regelmäßiges schließen und öffnen des Browsers ist übrigens tatsächlich eine gute Sicherheitsmaßnahme gegen Javascript-basierte Angriffe und Reboots gegen alle anderen Formen (wenn die Angreiferanwendung nicht im Autostart steht). Die Beobachtung der Browser-Auslastung ist in Zeiten fordernder erwünschter Scripte und vor allem Werbemittel dagegen ein Balance-Spiel. Technisch versierte und aufmerksame Anwender könnten einen starken Angriff erkennen. Aber die meisten Anwender bemerken es nachweislich nicht einmal, wenn der Browser im Hintergrund Kryptowährungen für jemand anderen schürft. Diese Nutzer würden auch bei einem Spectre-Angriff nicht misstrauisch werden.

        Zitat
        Jetzt glaube ich einfach mal, dass JS mittels Spectre aus dem Adressbereich des Browser ausbrechen kann. Dann liest es also die Liste der unter Windwos gerade laufenden (oder vorher mal gelaufenen) Tasks aus dem Speicher (scheint Windows dann ja immer an einer festen Stelle zu verlinken, u.U. liegt der Pointer an einer festen Speicheradresse), von dort kommt man dann an den Speicherbereich der Applikation und sucht sich dort Usernamen und ein Passwort. Das alles für Programme, die der Angreifer kennt, und zwar u.U. auch noch in der Version, die er kennt und nicht in einer alten, die ich zufällig nutze.
        Die hohe Spezifizität von Spectre-Attacken ist tatsächlich der stärkste Schutz vor diesen, aber sie erspart dem Angreifer auch die meisten der genannten Schritte. Wer einen Angriff auf zum Beispiel Steam, Itunes oder andere beliebte, oft im Hintergrund laufende Programme mit Account-Verknüpfung ausführen möchte, der trainiert die CPU explizit für deren Code. Wenn das Programm tatsächlich läuft, ergeben sich daraus Informationen – wenn nicht, dann war der Rechner halt kein geeignetes Ziel. Der Angreifer muss aber nicht wissen, wo im physischen Speicher das Opfer tatsächlich liegt, weil er dieses selbst dazu bringt, seine Geheimnisse zu verraten. Und ihren eigenen Adressraum kennen Anwendungen naturgemäß gut; der Angreifer wiederum kennt den verwendeten Hidden Channel und damit die Strukturen, aus denen er die Informationen rekonstruiert, weil er sie selbst definiert hat. Schutz gibt es also nur, wenn man allen anfälligen Code aus allen potenziellen Opfern entfernt hat oder wenn man alle Rückkanäle in allen potenziellen Ausführumgebungen (z.B. JS) für Angreifer-Code schließt. Da werden aber immer wieder neue gefunden und dritte, beispielsweise Sicherheitstools, Firewalls, Viren-Scanner, Sandboxen und ähnliche können sonst nur nach verdächtigen Aktivitätsmustern Ausschau halten und Alarm schlagen. Zur Schadensbegrenzung helfen sie in etwas so gut wie eine physische Mauer gegen einen Hubschrauber.
        Zitieren
      • Von PCGH_Torsten Kokü-Junkie (m/w)
        AW: Spectre und Meltdown: Intels Sicherheitsteam arbeitet noch immer an Lösungen

        Zitat von fotoman
        Es geht nur um JS über de Browser. Oder wer hat heute noch Flash, Silverlight oder gar Java im Browser aktiviet?

        Alle lokalen Angriffe muss der Heimanwender als Einzel-Anwender genauso manuell ausführen wie einen normalen Trojaner. Dass man mittels JS aus dem Adressbereich des Browsers ausbrechen kann, lese ich erstmalig.
        Ich bin mir nicht ganz sicher, wie weit die PoC für JS fortgeschritten sind. Spectre-Angriffe in JS zu schreiben ist deutlich schwerer wegen der zwischengeschalteten Interpreter. Aber wenn wir eins aus Spectre gelernt haben, dann: Nur weil man etwas noch nicht weiß oder es aufwendig erscheint, heißt das noch lange nicht, dass es unmöglich ist und es noch niemand versucht hat.
        Prinzipiell greifen primäre Spectre-Angriffe jedenfalls mit missbrauchtem Target-Code aus dem Adressraum des Targets auf den Adressraum des Targets zu. Solange eine Anwendung nicht geschützt ist, ist ihr Adressraum also in Gefahr – unabhängig davon, in welchem Adressraum der Code des Angreifers läuft. Der Browser selbst ist natürlich eines der attraktivsten Ziele überhaupt und für JS-Angriffe das naheliegenste. Aber wenn man ein Return-Gadget kennt, mit dem man auch via Javascript einen Rückkanal aufbauen kann, dann kann man prinzipiell alles angreifen.

        Zitat
        Hier hat zwar jemand eine "Umgehungslösung" gefunden, die mit ca. einem Bit/Sekunde nun wirklich nicht praxisrelevant ist.
        Overcoming (some) Spectre browser mitigations

        Außerdem ist man dort (wie auch Heise im damaligen Artikel) der Meinung, dass man mit Spectre und JS im Browser nur den Adressbereich des Browsers auslesen kann.
        Dieser Angriff ist in der Tat zu langsam für nennenswerten Nutzen und er beschäftigt sich nur mit Angriffen auf den Adressraum des Browsers. Aber wie kann man ausschließen, dass es weitere Möglichkeiten gibt?

        Zitat
        Früher zu Vaters Zeiten hatten aber allenfalls Großrechner 32 GB Ram und mehr. Wenn ich mit den 500 KByte/s rechne, die ich auf die Schnelle gefunden habe (falls die Zahlen von einem JS-Angriff auf einem großen Xeon stammen und nicht vom C-Code) sind das rund 18 Stunden. Das ganze sicherlich nicht ohne dabei eine direkt sichtbare, hohe Browserauslastung zu generieren, die mir recht schnell auffällt.
        Der physische RAM spielt keine Rolle. Durchsucht werden muss der gesamte virtuelle Adressraum, der war auch schon früher zu groß für einen Komplett-Downland. Aber sobald man ein Element gefunden hat, dass man kennt und dass eine feste Position relativ zu interessanten Daten einnimmt (zum Beispiel weil die angegeriffene Anwendung ihre Programmbestandteile in einer bestimmten Reihenfolge lädt) muss nur noch dieser potenziell interessante Bereich durchsucht werden. So werden aus TiB KiB. Ein großer physischer RAM kann hier sogar von Vorteil sein, wenn er auch intensiv genutzt wird – einen Speer im Heuhaufen findet man schneller als eine Nadel.

        Regelmäßiges schließen und öffnen des Browsers ist übrigens tatsächlich eine gute Sicherheitsmaßnahme gegen Javascript-basierte Angriffe und Reboots gegen alle anderen Formen (wenn die Angreiferanwendung nicht im Autostart steht). Die Beobachtung der Browser-Auslastung ist in Zeiten fordernder erwünschter Scripte und vor allem Werbemittel dagegen ein Balance-Spiel. Technisch versierte und aufmerksame Anwender könnten einen starken Angriff erkennen. Aber die meisten Anwender bemerken es nachweislich nicht einmal, wenn der Browser im Hintergrund Kryptowährungen für jemand anderen schürft. Diese Nutzer würden auch bei einem Spectre-Angriff nicht misstrauisch werden.

        Zitat
        Jetzt glaube ich einfach mal, dass JS mittels Spectre aus dem Adressbereich des Browser ausbrechen kann. Dann liest es also die Liste der unter Windwos gerade laufenden (oder vorher mal gelaufenen) Tasks aus dem Speicher (scheint Windows dann ja immer an einer festen Stelle zu verlinken, u.U. liegt der Pointer an einer festen Speicheradresse), von dort kommt man dann an den Speicherbereich der Applikation und sucht sich dort Usernamen und ein Passwort. Das alles für Programme, die der Angreifer kennt, und zwar u.U. auch noch in der Version, die er kennt und nicht in einer alten, die ich zufällig nutze.
        Die hohe Spezifizität von Spectre-Attacken ist tatsächlich der stärkste Schutz vor diesen, aber sie erspart dem Angreifer auch die meisten der genannten Schritte. Wer einen Angriff auf zum Beispiel Steam, Itunes oder andere beliebte, oft im Hintergrund laufende Programme mit Account-Verknüpfung ausführen möchte, der trainiert die CPU explizit für deren Code. Wenn das Programm tatsächlich läuft, ergeben sich daraus Informationen – wenn nicht, dann war der Rechner halt kein geeignetes Ziel. Der Angreifer muss aber nicht wissen, wo im physischen Speicher das Opfer tatsächlich liegt, weil er dieses selbst dazu bringt, seine Geheimnisse zu verraten. Und ihren eigenen Adressraum kennen Anwendungen naturgemäß gut; der Angreifer wiederum kennt den verwendeten Hidden Channel und damit die Strukturen, aus denen er die Informationen rekonstruiert, weil er sie selbst definiert hat. Schutz gibt es also nur, wenn man allen anfälligen Code aus allen potenziellen Opfern entfernt hat oder wenn man alle Rückkanäle in allen potenziellen Ausführumgebungen (z.B. JS) für Angreifer-Code schließt. Da werden aber immer wieder neue gefunden und dritte, beispielsweise Sicherheitstools, Firewalls, Viren-Scanner, Sandboxen und ähnliche können sonst nur nach verdächtigen Aktivitätsmustern Ausschau halten und Alarm schlagen. Zur Schadensbegrenzung helfen sie in etwas so gut wie eine physische Mauer gegen einen Hubschrauber.
        Zitieren
      • Von Gamer090 Lötkolbengott/-göttin
        AW: Spectre und Meltdown: Intels Sicherheitsteam arbeitet noch immer an Lösungen

        Immer noch an Lösungen arbeiten? Dachte das ganze wäre schon längst erledigt Da habe ich aber mal was verpasst, zukünftig werde ich wohl lieber bei AMD bleiben, wie schon seit dem Phenom II
        Zitieren
      • Von fotoman Volt-Modder(in)
        AW: Spectre und Meltdown: Intels Sicherheitsteam arbeitet noch immer an Lösungen

        Zitat von PCGH_Torsten
        Vorsicht: Spectre überspringt Adressbereiche. Wem es trotz der Abwehrmaßnahmen gelingt, einen Spectre-Angriff beispielsweiser via Javascript zu starten, der kann damit die Adressbereiche aller ungepatchten Prozesse des System auslesen.
        Es geht nur um JS über de Browser. Oder wer hat heute noch Flash, Silverlight oder gar Java im Browser aktiviet?

        Alle lokalen Angriffe muss der Heimanwender als Einzel-Anwender genauso manuell ausführen wie einen normalen Trojaner. Dass man mittels JS aus dem Adressbereich des Browsers ausbrechen kann, lese ich erstmalig.

        Hier hat zwar jemand eine "Umgehungslösung" gefunden, die mit ca. einem Bit/Sekunde nun wirklich nicht praxisrelevant ist.
        Overcoming (some) Spectre browser mitigations

        Außerdem ist man dort (wie auch Heise im damaligen Artikel) der Meinung, dass man mit Spectre und JS im Browser nur den Adressbereich des Browsers auslesen kann.

        Zitat von PCGH_Torsten
        Und wenige kB/s mögen langsam klingen, entsprechen aber immer noch einer Geschwindigkeit, mit der führer ganze Rechner arbeiteten.
        Früher zu Vaters Zeiten hatten aber allenfalls Großrechner 32 GB Ram und mehr. Wenn ich mit den 500 KByte/s rechne, die ich auf die Schnelle gefunden habe (falls die Zahlen von einem JS-Angriff auf einem großen Xeon stammen und nicht vom C-Code) sind das rund 18 Stunden. Das ganze sicherlich nicht ohne dabei eine direkt sichtbare, hohe Browserauslastung zu generieren, die mir recht schnell auffällt.

        Zitat von PCGH_Torsten
        Da der Angriff automatisch innerhalb einer bekannten Datenstruktur statffindet, nämlich der des angegriffenen Prozesses, muss der Angreifer keine bulk-Zugriffe durchführen und hinterher auswerten
        Welcher angegriffenen Prozess? Der Angreifer weiss zunächst nur, welchen Browser und welches OS ich nutze.

        Also kann er im Browser-Speicher nach Daten in einer bekannten Struktur suchen. Das mögen Cookies, gespeichertePasswörter und Eingaben sein (falls der Browser die alle beim Start in den Speicher liest). Konto- und KK-Daten kann ich auf den Seiten, wo ich sie ab und zu mal eingebe, nicht als Eingabe im Browser speichern. Daran kommt man also nur, wenn ich die Daten mit der aktuell angegriffenen Browserinstanz eingegeben habe.

        Bleibe ich bei der simpelen, von mir seit >15 Jahren angewendeten Methode, nach der Eingabe solcher Daten (während denen sowieso keine anderen Tabs bei mir offen sind) den Browser mal kurz zu schließen und neu zu öffnen, wären die zuvor eingegebenen Daten nach obiger Seite per Browser und JS schon nicht mehr auslesbar.

        Zitat von PCGH_Torsten
        sondern kann systematisch nach den Speicherabschnitten mit interessanten Bereichen suchen, beispielsweise Passwörtern. Die sind nur wenige Byte groß und in Zeiten intensiver Cloud-Nutzung (IMAP, Steam, Bitcoin) oft interessanter als die lokal gespeicherten Daten.
        Jetzt glaube ich einfach mal, dass JS mittels Spectre aus dem Adressbereich des Browser ausbrechen kann. Dann liest es also die Liste der unter Windwos gerade laufenden (oder vorher mal gelaufenen) Tasks aus dem Speicher (scheint Windows dann ja immer an einer festen Stelle zu verlinken, u.U. liegt der Pointer an einer festen Speicheradresse), von dort kommt man dann an den Speicherbereich der Applikation und sucht sich dort Usernamen und ein Passwort. Das alles für Programme, die der Angreifer kennt, und zwar u.U. auch noch in der Version, die er kennt und nicht in einer alten, die ich zufällig nutze.

        In Form von Stuxnet war das mehr wie denkbar, aber da kannte der Angreifer auch das angegriffene System und musste die Angriffe nicht für dutzende von Prorgammen realisieren.

        Bei Keypass funktioniert das schonmal nur mit dem Master-Passwort und max. noch mit denen, die ich aus Keypass kopiert habe. Mache ich Keypass nach der Nutzung zu und öffne es danach wieder, muss der Angreifer schon Glück haben, sowohl die Referenz zum alten wie den neuen Eintrag der Applikation im Speicher zu finden.

        Ob das Vorgehen auch noch für Programme möglich ist, die vor dem letzten Reboot von Windows gestartet waren, bleibt wohl zu testen. Die Programmnamen der alten Tasts findet man im Memory-Dump, aber welchen Grund sollte Windows haben, die Taskliste immer an einer festen physikalischen Stelle im Ram abzulegen?

        Wer extreme Panik vor einer solchen Spionage hat, bootet halt nach kritischen Operationen seinen PC einmal und schaltete ihn dabei für 2-3 Minuten komplett aus.

        Aber klar, genauso wie es Krankenhäuser gibt, die ihre Patientendaten offen ins Internet stellen und Krafwerke, die jeder fernsteuern kann, gibt mit Sicherheit auch Privatanwender, die in einem solchen Szenario eine reale Bedrohung sehen.

        Glaubt man obigem Link, dann genügt es schon für kritische und unkritische Dinge im Internet unterschiedliche Browser zu nutzen.
        Zitieren
      • Von PCGH_Torsten Kokü-Junkie (m/w)
        AW: Spectre und Meltdown: Intels Sicherheitsteam arbeitet noch immer an Lösungen

        Zitat von Pu244
        Das Problem wird uns wohl noch Jahrzehnte verfolgen, bis irgendwann eine völlig neue Computertechnologie erfunden wird und sich durchsetzt (falls es dazu überhaupt kommt).

        Man war sich dessen immer bewußt, bzw. es gab immer schon Leute, die vermutet haben dass die Neuerungen des Cache (in den 80ern) und des Out of Order Verfahrens (in den 90ern) sich so ausnutzen lassen, dass man Daten auslesen kann, an die man mit einer dummen CPU nicht herankommt. Bis Spectre gab es dafür jedoch keinen Beweiß, es war nur eine Vermutung, dass man es wohl irgendwie könnte.
        Daten aus Caches auslesen kann man spätestens seit dem letzten Jahrzehnt. Bis Spectre war man aber darauf angewiesen, dass eine Anwendung von sich aus die gewünschten Daten in den Cache liest und in einer Art und Weise bearbeitet, die das Auslesen erleichtert. Mit Spectre braucht man nur noch irgend eine Anwendung, die prinzipiell Zugriffsrechte auf die Daten hat.

        Zitat von fotoman
        Im Privatbereich bin ich bei Dir. Wer Spaß daran hat, meinen Speicher am gehärteten Browser vorbei mit ein paar KB/s auszulesen, soll es halt versuchen. Da dürfte es viel einfacher und zielführender sein, mir ein Tool zum Memory-Dump oder einen Keylogger unter zu schieben.

        Da aber nunmal CPUs nicht nur privat genutzt werden (Epyc ist auch nicht grundlegend anders wie ZEN, genauso entsrpechen Xeons dem normalen Intel-CPU Design) sind davon nunmal auch Cloud/Shared Server Anbieter betroffen. Und schon hat es keiner mehr in der Hand, was der andere Kunde auf der gleichn HW (mit Pech sogar auf dem gleichen CPU-Kern) so treibt.

        Und einzig wegen Cloud-Diensten gab/gibt es die berechtigte Aufmerksamkeit.

        Dann muss er noch hoffen, dass der angegriffene Privatanwender seinen Rechner ein paar Tage nahezu unverändert laufen lässt, damit wenigstens die theoretische Change besteht, mit ein paar KB/s 8-32 GB Ram auszulesen. Macht der Angreifer das ganze nur im Browser, so kommt der Angreifer auch nur an den Adressbereich des Brwosers. Mal abgesehen davon, dass ich schon lange nichts mehr über erfolgreiche POCs für gehärtetete Browser gelesen habe, könnte sich der Anwender vor den Auswirkungen problemlos mit etwas Aufwand schützen.

        Abhängig von der Defintion von "günstiger" und den Anwendungen des Users stimmt es oder auch nicht. Nicht jeder rechnet nur die Anschaffungskosten für die CPU.

        Aber gut, Freizeit wird nicht eingerechnet. Einen Stromkostenvergleich beim Spielen (um nichts anderes scheint es hier im Forum ja zu gehen) bei identischen FPS habe ich online auch noch keinen gesehen. Wenn ich meinen Rechner wieder 7-8 Jahre nutze, kommt da u.U. einiges an Stromkosten zusammen. Das könnte (ohne Betrachtung der Freizeit) durchaus zu Gunsten des AMD ausgehen,
        Vorsicht: Spectre überspringt Adressbereiche. Wem es trotz der Abwehrmaßnahmen gelingt, einen Spectre-Angriff beispielsweiser via Javascript zu starten, der kann damit die Adressbereiche aller ungepatchten Prozesse des System auslesen. Und wenige kB/s mögen langsam klingen, entsprechen aber immer noch einer Geschwindigkeit, mit der führer ganze Rechner arbeiteten. Da der Angriff automatisch innerhalb einer bekannten Datenstruktur statffindet, nämlich der des angegriffenen Prozesses, muss der Angreifer keine bulk-Zugriffe durchführen und hinterher auswerten, sondern kann systematisch nach den Speicherabschnitten mit interessanten Bereichen suchen, beispielsweise Passwörtern. Die sind nur wenige Byte groß und in Zeiten intensiver Cloud-Nutzung (IMAP, Steam, Bitcoin) oft interessanter als die lokal gespeicherten Daten.
        Zitieren
      • Von der_petling
        AW: Spectre und Meltdown: Intels Sicherheitsteam arbeitet noch immer an Lösungen

        Zitat von Plasmadampfer
        Aber weil Bill Gates ja das stockschwule BASIC erfunden hat und sagte 640 Megabyte werden immer reichen ....
        Du bist genau so ahnungslos wie die Leute denen du vorwirfst sie würden keine Ahnung über die Betriebsmodi einer CPU zu haben.
        BASIC – Wikipedia

        The '640K' quote won't go away -- but did Gates really say it? | Computerworld

        [Ins Forum, um diesen Inhalt zu sehen]
        Zitieren
      Direkt zum Diskussionsende
Hoch
  • Print / Abo
    Apps
    PCGH Magazin 07/2026 PC Games 06/2026 play5 07/2026 N-Zone 06/2026 Linux Magazin 06/2026 LinuxUser 06/2026 Raspberry Pi Geek 07/2026
    PC Games Hardware PC Games Linux Magazin Raspberry Pi Geek Computec Kiosk
Die Redaktion Datenschutz Artikel-Archiv Datenschutz-Optionen Mediadaten Impressum Utiq verwalten Abo kündigen AGB Inhalt melden Newsletter