News Massive Sicherheitslücke in Intel-CPUs der letzten Jahre

[Complicated]

Intel Statement zu der Thematik:
https://newsroom.intel.com/news/intel-responds-to-security-research-findings/

Intel believes these exploits do not have the potential to corrupt, modify or delete data.

Hehehe - ja der Exploit selber zerstört oder ändert keine Daten - clever formuliert. Nur jemand der sich Zugriff damit verschafft kann das machen wenn er will. Sie sichern sich schon gegen die Klagen ab, da ein Hacker nun mal kein Fehler der Hardware ist. Das ist der gravierende rechtliche Unterschied zwischen einem Hardwarebug der die Daten verfälscht oder einer Sicherheitslücke die Zugang zu den Daten ermöglicht. Es wird immer noch ein Mensch benötigt, der die illegale Aktion durchführt. Ist ja nicht illegal sein Systeme nicht abzusichern, so wie es ja z.B. strafbar ist in Deutschland das Auto nicht abzuschließen.

Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect. Based on the analysis to date, many types of computing devices — with many different vendors’ processors and operating systems — are susceptible to these exploits.

Intel is committed to product and customer security and is working closely with many other technology companies, including AMD, ARM Holdings and several operating system vendors, to develop an industry-wide approach to resolve this issue promptly and constructively.

oho...die Marketing Maschine läuft schon auf vollen Touren. AMD und ARM sollen demnach ebenso betroffen sein. Nun will man sich wohl nur noch darum streiten wie stark die Auswirkungen sind bei den einzelnen Archirtekturen.

Intel believes its products are the most secure in the world and that, with the support of its partners, the current solutions to this issue provide the best possible security for its customers.

Aha, da bin ich jetzt aber gespannt. Da wird einiges für Morgen zu erwarten sein.

 

[cologne46]

vielleicht doch schon viiieeelll länger bekannt?

http://www.planet3dnow.de/vbulletin...-Intel-Inside-Kampagne?highlight=intel+inside

Ja mit dem neuen Licht kann man da schon einen Zusammenhang sehen. Zusammenstreichen was auf die schnelle geht, um Rückstellungen zu bilden.

Intel believes its products are the most secure in the world and that, with the support of its partners, the current solutions to this issue provide the best possible security for its customers.

LOL. Ohne BUG wäre die Sicherheit für die Kunden aber noch höher. Aber was weiß ich schon.

 

[Die Frage]

Guten Abend

Wo steht den in der Intel News, dass ARM und AMD ebenfalls betroffen sind.
Da steht nur, dass man mit vielen Firmen, dann werden welche aufgelistet, zusammenarbeitet, um das Problem gemeinsam zu lösen. Mehr nicht. Ist auch nicht ganz Wörtlich übersetzt, aber es sollte reichen.

Gruß
Die Frage

 

[SPINA]

Unwahrscheinlich, dass AMD von demselben Fehler betroffen ist, denn gerade auf solche Fehler klopft man eine Architektur schon bei der Entwicklung am stärksten ab und es ist bitter für Intel, dass eine bestimmte Konstellation durch das Suchraster gefallen ist. Bisher wurde nichts über einen gleichgelagerten Fehler bei Ryzen und Epyc verlautbar und dabei wird es aller Voraussicht nach bleiben. Solche Fehler sind zum Glück selten angesichts des Aufwandes der betrieben wird, um sie zu vermeiden. Dass es doch einmal geschehen musste, war nur eine Frage der Zeit und dass es gerade Intel trifft wundert mich nicht. Man muss sich nur einmal das Trauerspiel rund um TSX anschauen.

Allerdings sollte man nicht dem Irrglauben erliegen, dass dies irgendeinen Einfluss auf Marktanteile hätte. Schon wird über Verschiebungen im Serversegment zugunsten von Epyc spekuliert, aber die Vergangenheit hat gelehrt, dass die Einkäufer konservativ und nicht immer rational oder ökonomisch vorgehen. Wenn der geplante Xeon nicht mehr die erforderliche Leistung bringt, wird eben nicht Epyc gekauft, sondern stattdessen der nächstgrößere Xeon oder gar zwei an der Zahl. AMD wird keinen Nutzen aus diesem Fauxpas von Intel ziehen, sondern muss mit anderen Argumenten aufwarten.

 

[Complicated]

Wenn der geplante Xeon nicht mehr die erforderliche Leistung bringt, wird eben nicht Epyc gekauft, sondern stattdessen der nächstgrößere Xeon oder gar zwei an der Zahl. AMD wird keinen Nutzen aus diesem Fauxpas von Intel ziehen, sondern muss mit anderen Argumenten aufwarten.

Wohl kaum, wenn der zuvor gekaufte Xeon über Nacht mit einem Patch 20% weniger Leistung bringt und der auf dem Markt verfügbare Xeon ebenfalls 20% weniger leistet als bisher gedacht. Sind ja nicht nur Volldeppen im Einkauf unterwegs. Vor allem wenn das so richtig die Runde macht und bei den Entscheidern die Kosten auflaufen für die jetzt erforderlichen Patches. Und die sind enorm und bringen trotzdem weniger Leistung.

 

[Peet007]

Bei den meisten Serversystemen wird eh Linux eingesetzt und da ist das Patchen eigentlich kein Prloblem. Nur ab welchen Kernel kann man den Patch einpflegen oder muss man auf einen neueren Kernel wechseln. Was jetzt auch kein großes Problem darstellt weil Treiber für ältere Hardware wirklich spät aus dem Kernel fliegen.

Wenn die Leistung danach nicht mehr ausreicht wird Intel halt ein paar auf Kulanz hinstellen.

 

[Complicated]

Hier alle Details:
https://googleprojectzero.blogspot.de/2018/01/reading-privileged-memory-with-side.html

[FONT=&quot]So far, there are three known variants of the issue/FONT]

• [FONT=&quot]Variant 1: bounds check bypass ([/FONT][FONT=&quot]CVE-2017-5753)[/FONT]
  
• [FONT=&quot]Variant 2: branch target injection ([/FONT][FONT=&quot]CVE-2017-5715)[/FONT]
  
• [FONT=&quot]Variant 3: rogue data cache load ([/FONT][FONT=&quot]CVE-2017-5754)[/FONT]

Before the issues described here were publicly disclosed, Daniel Gruss, Moritz Lipp, Yuval Yarom, Paul Kocher, Daniel Genkin, Michael Schwarz, Mike Hamburg, Stefan Mangard, Thomas Prescher and Werner Haas also reported them; their [writeups/blogposts/paper drafts] are at:

• Spectre (variants 1 and 2)
  
• Meltdown (variant 3)

[FONT=&quot]During the course of our research, we developed the following proofs of concept (PoCs)/FONT]

1. [FONT=&quot]A PoC that demonstrates the basic principles behind variant 1 in userspace on the tested Intel Haswell Xeon CPU, the AMD FX CPU, the AMD PRO CPU and an ARM Cortex A57 [2].[/FONT][FONT=&quot] This PoC only tests for the ability to read data inside mis-speculated execution within the same process, without crossing any privilege boundaries.[/FONT]
   
2. [FONT=&quot]A PoC for variant 1 that, when running with normal user privileges under a modern Linux kernel with a distro-standard config, can perform arbitrary reads in a 4GiB range [3][/FONT][FONT=&quot] in kernel virtual memory on the Intel Haswell Xeon CPU. If the kernel's BPF JIT is enabled (non-default configuration), it also works on the AMD PRO CPU. On the Intel Haswell Xeon CPU, kernel virtual memory can be read at a rate of around 2000 bytes per second after around 4 seconds of startup time. [4][/FONT]
   
3. [FONT=&quot]A PoC for variant 2 that, when running with root privileges inside a KVM guest created using virt-manager on the Intel Haswell Xeon CPU, with a specific (now outdated) version of Debian's distro kernel[/FONT][FONT=&quot] [5] running on the host, can read host kernel memory at a rate of around 1500 bytes/second, with room for optimization. Before the attack can be performed, some initialization has to be performed that takes roughly between 10 and 30 minutes for a machine with 64GiB of RAM; the needed time should scale roughly linearly with the amount of host RAM. (If 2MB hugepages are available to the guest, the initialization should be much faster, but that hasn't been tested.)[/FONT]
   
4. [FONT=&quot]A PoC for variant 3 that, when running with normal user privileges, can read kernel memory on the Intel Haswell Xeon CPU under some precondition. We believe that this precondition is that the targeted kernel memory is present in the L1D cache.[/FONT]

https://twitter.com/ryanshrout/status/948683677244018689

 

[mibo]

*Stopuhr drück*

Wie lange Intel nun braucht, um eine CPU ohne dieses Problem zu veröffentlichen?
Das könnte echt existenzbedrohend sein.
Ich bin auf die Quartalsberichte gespannt.

PS: Irgendwo hatte ich was von "Rowhammer-like" Angriffen auf diesen Bug gelesen. Und Rowhammer wurde ja auch schon in Javascript gezeigt. Das könnte im schlimmsten Fall bedeuten, dass eine aufgerufene Webseite per Javascript beliebige Speicherbereiche auslesen kann. Da würde ich dann doch lieber nen Patch einspielen...

 

[Nero24]

Wenn's blöd läuft, trifft der Bug AMD performanceseitig am Ende stärker als Intel. Wenn die OS-Hersteller auch nur den kleinsten Zweifel daran haben, dass AMD-Prozessoren nicht von dem Angriffsszenario betroffen sind, dann werden sie den leistungsmindernden Fix auf ALLE x86-64-Systeme anwenden. Und dann kann's im dümmsten Fall für AMD schlechter aussehen, als für Intel:

<blockquote class="twitter-tweet" data-lang="de"><p lang="en" dir="ltr">This is bad: performance hit from PTI on the du -s benchmark on an AMD EPYC 7601 is 49%. <a href="https://t.co/TT2aQpsb5U">https://t.co/TT2aQpsb5U</a> <a href="https://t.co/Y12B1SIUMd">https://t.co/Y12B1SIUMd</a></p>&mdash; grsecurity (@grsecurity) <a href="https://twitter.com/grsecurity/status/947439275460702208?ref_src=twsrc%5Etfw">31. Dezember 2017</a></blockquote>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

 

[Peet007]

Der Patch ist momentan auf einem Ryzen mit Linux Kernel 4,15 nicht aktiv. Ist im Normalfall kein Problem den wenn wirklch auch abzuschalten.

 

[OBrian]

Wie lange Intel nun braucht, um eine CPU ohne dieses Problem zu veröffentlichen?
Das könnte echt existenzbedrohend sein.

wohl ca. ein Jahr. Mußt ja das Problem erstmal vernünftig lösen (nur "irgendwie" wäre ja Mist, soll ja auch schneller sein als der Software-Fix), den Fix in Hardware implementieren, und die geänderte Hardware dann testen, ob es sich mit dem Rest des Chips verträgt, dann Chips in der neuen Revision bauen. Beiden üblichen Vorlaufzeiten wartet man ggf. auch auf die sowieso nächste Stufe in der Produktpflege, statt extra für den Fix was neues zu backen.

Immerhin kann man den Fix dann später als Performance-Verbesserung vermarkten

Das könnte echt existenzbedrohend sein.
Ich bin auf die Quartalsberichte gespannt.

so schnell wird sich das nicht niederschlagen. Wäre zwar schön für AMD, wenn jetzt kurzfristig alle Computerkäufer auf AMD setzen statt Intel, aber das wird kaum passieren. Die meisten kaufen ja komplette Systeme, und wenn dann z.B. HP oder wer auch immer die Gewähr übernimmt, daß das Ding funktioniert, dann reicht den Kunden das. Es hat auch kaum einer Lust, die ganze Produktpalette umzustellen.

Mit Fix und ein paar Prozent Einbußen dürfte es auch nicht so schlimm sein, denn die meisten Rechner laufen ja nicht am Anschlag bzgl. CPU-Last. PCs werden eh nur teilbelastet und bei Servern hängt es meist an der RAM-Menge, weniger an der rohen CPU-Kraft. Insofern wird es wahrscheinlich gar nicht so riesige Auswirkungen haben.

 

[Complicated]

Normale User Systeme sind hier auch nicht betroffen - es sind die Server die unter dem Patch am meisten Performance verlieren.
Folgender Ablauf:
1. Eine riesige Patch-Welle kommt auf alle Serverbetreiber zu. Das kostet Unmengen an Geld und muss auch dem Management erläutert werden wozu das nötig ist.
2. Nach dem Patch werden relevante Anwendungen für Datenbanken und Virtualisierung 20-40% Performance Einbußen haben. Bei dem einen oder anderen wird ein nachrüsten erforderlich sein um die konzeptionierten Lasten bieten zu können.
3. Aktuell geplante Käufe in 2018 werden keine Intel CPUs mehr berücksichtigen, da diese auch alle mit dem Performance Malus schon ankommen.
4. Intel verliert den Status "damit funktioniert es stressfrei" sowohl bei den ITlern als auch bei den Entscheidern. Der gebrochene Mythos wird vielleicht am teuersten zu stehen kommen.

 

[AMD_Flo]

Ich habe mich mal ein wenig informiert:

Es gibt anscheinend zwei Exploits.
Einmal Meltdown und einmal Spectre.

Hier bin ich auf eine gute Infoseite dazu gestoßen: https://spectreattack.com/

Anscheinend betrifft Meltdown nach aktuellem Erkenntnisstand ausschließlich Intel-Prozessoren und ein Software-Patch für Meltdown kostet Performance.
Die Attacke soll Zugriff auf eigentlich geschützten Systemspeicher ermöglichen: "Consequently, applications can access system memory."

Spectre soll so gut wie alle CPUs betreffen (Intel, ARM, AMD): "Almost every system is affected by Spectre".
Es soll noch keine Aussicht auf einen Patch geben: "The name is based on the root cause, speculative execution. As it is not easy to fix, it will haunt us for quite some time."

Hier habe ich ein Repo mit einem angeblichen Beispielcode für Spectre gefunden: https://github.com/Eugnis/spectre-attack
Jedoch lässt sicher der Code nur für Windows kompilieren und ich habe nur Linux.

Und wie ich das verstanden habe soll der zweite Exploit es ermöglichen, dass ansonsten fehlerfrei programmierte Anwendungen ihre eigentlich geschützten Daten freigeben. Siehe Github: "Spectre breaks the isolation between different applications. It allows an attacker to trick error-free programs, which follow best practices, into leaking their secrets."

=> Intel hat insofern Recht, dass alle CPU-Hersteller an einer Lösung des Problems arbeiten. Jedoch betrifft nur Spectre alle Hersteller.

Die immer komplexeren HW-Optimierungen, trotz moderner HW-Sicherheitsfeatures, öffnen anscheinend gravierende Sicherheitslücken.
Trotz Besitzer einer Ryzen-CPU sind das sehr schlechte Neuigkeiten für mich.

 

[Complicated]

Da gibt es einen gravierenden Unterschied, der auch in diesem Dokument zu finden ist:
AMD ist im Auslieferungszustand nicht verwundbar. Das Dokument https://spectreattack.com/spectre.pdf beschreibt das folgendermaßen:

We have empirically verified the vulnerability of several Intel processors to Spectre attacks, including Ivy Bridge, Haswell and Skylake based processors. We have also verified the attack’s applicability to AMD Ryzen CPUs.

​

Der Unterschied zwischen Verwundbarkeit und Anwendbarkeit liegt darin begründet, dass man bei AMD den eBF JIT aktivieren muss.
Siehe: https://googleprojectzero.blogspot.de/2018/01/reading-privileged-memory-with-side.html

Variant 1: Bounds check bypass
This section explains the common theory behind all three variants and the theory behind our PoC for variant 1 that, when running in userspace under a Debian distro kernel, can perform arbitrary reads in a 4GiB region of kernel memory in at least the following configurations:

Intel Haswell Xeon CPU, eBPF JIT is off (default state)
Intel Haswell Xeon CPU, eBPF JIT is on (non-default state)
AMD PRO CPU, eBPF JIT is on (non-default state)

The state of the eBPF JIT can be toggled using the net.core.bpf_jit_enable sysctl.

​

Daher kann AMD zurecht behaupten, dass ihre CPUs nicht verwundbar sind. Denn wenn der User ersteinmal eine Sicherheitslücke aktivieren muss gibt es unzählige Möglichkeiten.

 

[Muku-Muku]

So, Intels Marketingabteilung wirkt, die Mainstream- Medien berichten, dass alle Prozessorhersteller betroffen sind.
Der von Intel eingereichte Linux Patch für die Meltdown Attacke bremst alle Prozessoren aus, nicht nur Intels...
Da zeigt sich einmal mehr was für ein Kotzverein Intel ist.
Der CEO hat wohl im November seine Aktien verkauft...

--- Update ---

Wie wäre es wenn alle AMD-Prozessor-Benutzer vor und nach dem (sicher erscheinenden) Windows-Patch mal ein paar Benchmarks laufen lassen- mir schwant da böses.

 

[Peet007]

Mich würde interessieren in wieweit das UEFI mini OS das ja unter dem Haupt OS liegt, davon betroffen ist. Wäre meiner Meinung nach recht Haarig wenn ein Angreifer quasi Vollzugriff erlangen würde und im Bios allerand verändern könnte, so das die Hardware schaden nimmt.

Je komplexer Systeme werden um so anfälliger werden sie, Secure Boot ist da anscheinend voll ausgehebelt.

 

[el-mujo]

Mein Tablet kann ich dann wohl wegwerfen.
Hat nen Celeron und vom Hersteller gibts keine Android-Updates mehr. Denke auch nicht, dass da dann noch ein Sicherheitsupdate kommt.
Und mein Sohn wird sich auch freuen mit seinem Xeon. Wenn die nötigen Patches wirklich Leistung sprübar kosten, das wäre schon ein Hammer.

MEIN Tablet wird nicht weggeworfen: Fujitsu ST5112, Modelljahr 2007 (BJ 2008), Core2Duo U7600
Mein I7-920 genausowenig *megagrins*

Womöglich geht es um die "PCID"-Funktion, welche angeblich erst ab 2011 in den CPUs verbaut wurde. Ne offizielle Info zu den betroffenen Prozessoren wäre ja mal ganz nett.

@ Peet007
So wie es sich für mich derzeit darstellt, hat das UEFI den annähernd gleichen 'Rang' wie das Haupt-OS und bedarf selbstverständlich eines Patches.

Ich möchte aber zu dem rechtlichen Aspekt der Geschichte noch etwas sagen:
Wiedermal bade ich als Kunde die Fehler von Hardware-und Softwareherstellern aus. Wie immer wird sich darauf berufen, dass man sich der Verantwortung für das Nichtfunktionieren der verkauften Produkte entzieht, indem einfach behauptet wird, das ist halt so. Fehler können immer im System sein.

Dazu habe ich eine ganz konkrete Meinung, die wohl auch einigen Programmierern hier nicht sonderlich gefallen dürfte.

Natürlich hat der Hardware-Designer/Programmierer wenn er ein Produkt verkauft, die Verantwortung dafür zu tragen, dass von dieser Software /Hardware kein Schaden ausgeht. In so ziemlich jedem Bereich der Wirtschaft ist Derjenige für die Folgen seiner Fahrlässigkeit haftbar zu machen. Es kann sich nicht rausgeredet werden,d ass man Fehler früher nicht erkannt hat. Wenn nicht sichergestellt werden kann, dass von einem Produkt kein Schaden ausgeht, darf es auch nicht in den Handel. Die Hersteller haben ihre Sorgfaltspflicht verletzt.

Selbst wenn unter Zuhilfenahme aller technischen und menschlichen Analyseverfahren zum damaligen Zeitpunkt die vorherrschende Meinung war, dass das so OK und sicher ist, es sich aber im Nachhinein als falsch herausstellt, dann hat der Hersteller dafür zu sorgen, dass der Fehler behoben wird und zwar OHNE zeitliches Limit!


Ich will das auch begründen. Diese Systeme laufen im Produktivbetrieb, laufen in Sicherheitsrelevanten Umgebungen, laufen in kritischen Umgebungen und laufen iauch in finanzkritischen Umgebungen (Börse, Unternehmen, Steuerverwaltung, ...). Unter diesen Umständen der Durchdringung und Wichtigkeit dieser Systeme für das Funktionieren der Wirtschaft, des Staatsapperates und unserer persönlichen Sicherheitsinteressen, würde ich den Anpruch darauf erheben, dass damit auch eine lebenslange Verpflichtung einhergeht, später entdeckte Fehler zu beheben, so sie denn Schaden anrichten können.

Ein öffentlich bestellter Vermessungsingenieur haftet auch zeit seines Lebens für die korrekte Umsetzung der hoheitlichen Vermessungsaufgaben, wie z.B. Grundstücksgrenzen. Taucht da Jahrzehnte später ein Fehler auf, der dem Vermesser nachgewiesen kann ist er bzw. der Rechtsnachfolger von ihm in der Pflicht den Fehler zu beheben. Für Fehler die z.B. im Bau geschehen ("konnte ja vorher auch keiner wissen ...") ist man nicht nur zu einer Korrektur verpflichtet, sondern auch zum Schadenersatz.

Für den aktuellen Fall - da sollte es möglich sein alle verbauten Prozessoren austauschen zu können (zur Not durch Neuproduktion alter Designs).

 

[Stefan Payne]

Der TLB-Bug war nur eine kurze Sache, aber das, was bei den Intel CPUs falsch läuft, läuft schon seit 10 Jahren falsch.

20...

Die Leute sprechen von allen Intel CPUs mit Out of Order bzw Speculative Excecution...
Aber bei Win9x und 2k/XP ist das eh Latte, da man eh als Admin arbeitet...

Erst ab VISTA ists wichtig/interessant...

--- Update ---

auch wenn ich mich wiederhole ... je nachdem wie groß der impact am ende sein wird, kann ich mir sehr gut vorstellen, dass es in den usa diverse sammelklagen geben wird.

Für Datenbanken und ggF HPC ist das wohl vernichtend. Da wird man wohl so schnell wie möglich auf AMD umsteigen (müssen).

--- Update ---

Die Atoms werden auch interessant sein ob sie betroffen sind. Man denke an die ganzen Modelle in den NAS-Geräten.

Die werden überwiegend nicht betroffen sein.
Bzw erst die 3k Generation, da alles davor schrottige In Order CPUs waren.

 

[TAL9000]

Nach dem etwas mehr Infos heraus sind (2 Sicherheitslücken in 3 Varianten), frage ich mich wie schlimm es doch um die Lesekompetenz der User und auch einiger Nachrichtenschreiber steht. Meine Englisch Kenntnisse sind unterdurchschnittlich nMm., aber das was daraus gemacht wird, ist erschreckend. Ich hätte vielleicht nicht vor kurzen "Der Aufmacher" lesen sollen...

Links zu eigenen Meinungsbildung (technisch komplexer):

Spectre (variants 1 and 2)
Meltdown (variant 3)

Zusammen mit den meisten andern mir bekannten Sicherheitsproblemen/HW Fehlern, sind Meltdown und der Intel ME die eher schlimmeren in der letzten Zeit, wo bei ich auch sagen muss das ich nicht einmal bis her mit meinen Ryzen ein Kernel compiliert habe (SegFault-Bug).
Spectre ist aber nach meiner Erinnerung nicht die erste Sideband attacke basierende Sicherheitslücke und damit eigentlich nur wegen der breiten Basis (praktisch alle Out-of-order execution CPUs) so "schlimm".
Also alles auch Betrachtungssache, was aber für den nicht Informierten User schwierig ist. Mir fällt es aber schwer in den heutigen Zeiten und den damit verbunden Möglichkeiten, das noch zu entschuldigen.

Schade ist die immer noch geringe Datenlage betreffend der Performanceverluste für Serversysteme. Da wird sich wahrscheinlich auch erst mal nicht viel ändern...

 

[Stefan Payne]

ich glaube nicht, dass gamer & normalanwender allzu sehr davon betroffen sein werden oder dass da irgendwer gleich zum anwalt rennt und eine klage anstrebt. jetzt irgendwelche spiele zu benchmarken ...

Durch die Sicherheitslücke ist jeder betroffen.
Und wenn die Exploiter daran bisserl arbeiten, könnte man befürchten, dass wir hier von einer Möglichkeit einen ungepatchten Rechner zum Botnetmitglied zu machen.

Und für Games würde ich das nicht so positiv sehen.
Denn bei einigen Games wird ja was dynamisch nachgeladen ggF geströmt.
Das kann dann zu rucklern führen, wo früher keine waren.

Wie damals beim Phenom TLB-Bug werden die Endanwender/Gamer wohl hauptsächlich vom leistungsmindernden Fix betroffen sein, weniger direkt vom Bug.

Apfel - Birnen Vergleich.
Beim Phenom TLB Bug gings um Stabilität. Das ist für Endanwender in der Tat ralle.
Hier geht es aber um Sicherheit und die Möglichkeit aus dem Userspace auszubrechen und auf den Kernelspace zuzugreifen.
DAS ist eine ganz andere Baustelle...

Was mich an der Sache verwundert ist, dass man erst durch einen Patch im Linux-Kernel auf den Bug aufmerksam wurde. Der aber über die Feiertage quasi übernommen wurde, was sonst viel länger dauert und selbst MS schon einen Patch entwickelt. Da muss schon echt was happiges sein, wenn alle so lange dichthalten

Ja, Zugriff auf den Kernelspeicher ohne Rechte ist schon was richtig übles.
Das geht bald nicht schlechter...

Wie lange Intel nun braucht, um eine CPU ohne dieses Problem zu veröffentlichen?
Das könnte echt existenzbedrohend sein.
Ich bin auf die Quartalsberichte gespannt.

Jahre!
Die müssen die gesamte Sprungvorhersage neu entwickeln und die Out of Order Excecution ebenso anpassen...

Also das das alsbald in Hardware gefixt wird, kannst vergessen. Dafür ist der Schaden zu groß. Und das ganze zu tief in der Architektur.

PS: Irgendwo hatte ich was von "Rowhammer-like" Angriffen auf diesen Bug gelesen. Und Rowhammer wurde ja auch schon in Javascript gezeigt. Das könnte im schlimmsten Fall bedeuten, dass eine aufgerufene Webseite per Javascript beliebige Speicherbereiche auslesen kann. Da würde ich dann doch lieber nen Patch einspielen...

Ja, die Möglichkeit besteht durch diesen Bug...

--- Update ---

Schade ist die immer noch geringe Datenlage betreffend der Performanceverluste für Serversysteme. Da wird sich wahrscheinlich auch erst mal nicht viel ändern...

Phoronix hat bisserl was gebencht.
Das geht in dem Bench bis zu 30%, anderswo hab ich von 50% gesehen.

Also das ist schon im Bereich von katastrophal, so dass man hier von einem Fukushima oder Tschernobil Ausmaß sprechen kann und auch sollte.

 

[TAL9000]

Hier für Windows(10/Server 2016) User die Updates/HotFixes:
http://www.catalog.update.microsoft.com/Search.aspx?q=KB4056890

EDIT: und 7 http://www.catalog.update.microsoft.com/Search.aspx?q=KB4056897

 

[Shinzon]

@Complicated
lt. deinem Zitat ist ja auch bei Intel eBPF JIT is off per default gesetzt (wie bei AMD). Somit ist von Haus aus das Ausnutzen dieser Sicherheitslücke bei Intel und AMD nicht möglich. Oder sehe ich da was falsch?
Was ist mit Spectre (Variante 2). Betrifft das alle Prozessoren? In der pdf wird speziell auf die Sprungvorhersage von Haswell eingegangen.

 

[cruger]

für welche android-versionen werden die security-fixes denn ausgerollt?

wenn google nur die aktuell noch supporteten versionen patched, wird das für die millionen anwender, die noch mit einem alten android unterwegs sind, lustig werden. schmeißt mal bitte eure geräte weg oder lebt mit dem risiko. updates? ne, ist uns zu anstrengend. das dürfte auch bei den exoten interessant werden, die mal intel-soc's verbaut hatten. denn effektiv sind diese geräte so oder so tot.

 

[MacroWelle]

@Shinzon
Default off bei Intel heißt nur, dass der eBPF JIT dort eben auch standardmäßig aus ist, so wie bei AMD, die CPU ist aber bei Intel in beiden Fällen verwundbar, bei AMD nur im Sonderfall. Google hat natürlich beides getestet, daher stehen beide Fälle bei Intel drin.
In dem Test wird als Intel-CPU ein Haswell verwendet, es sind aber alle Intel-CPUs letzten Jahre betroffen, nicht nur Haswell.

Meine Linux-Distribution hat letzte Nacht Kernel-Patches für 4.14.11 ausgerollt, jetzt zählen wir die Wochen bis MS soweit ist...

Mittlerweile greifen Mainstream-Medien das Thema auf: http://www.zeit.de/digital/datensch...icherheitsluecken-gefaehrden-geraete-weltweit

Interessant finde ich, dass (mal wieder) Googles Project Zero das Problem gefunden hat und kein Hardwarehersteller. Und so wie es aussieht kommen die Zen-CPUs bei dem Thema insgesamt am besten raus.

 

[eratte]

jetzt zählen wir die Wochen bis MS soweit ist...

Da ist wohl nichts zu zählen, Update wird seid heute verteilt.

Windows 7 KB4056897
Windows 8.1 KB4056898
Windows 10 KB4056892

Aufpassen wer andere AntiVirus Software einsetzt:

Important information regarding the Windows security updates released on January 3, 2018 and anti-virus software (Microsoft)