News „Spectre Next Generation“: Acht neue CPU-Lücken sollen gefunden worden sein

MK one schrieb:
@donend
Man kann AMD doch jetzt wirklich nicht vorwerfen sie hätten nichts getan , oder ? Schneller als Intel war AMD damit ...

Eben weil es Typen wie dich gibt , die ein theroetisches Angriffsrisiko bereits als praktisch umgesetzt betrachten hat AMD nachgebessert , schon allein um mit Intel gleichzuziehn
AMD schrieb:
IBPB
Indirect branch prediction barrier (IBPB) exists at MSR 0x49 (PRED_CMD) bit 0. This is a write only MSR that both GP faults when software reads it or if software tries to write any of the bits in 63:1. When bit zero is written, the processor guarantees that older indirect branches cannot influence predictions of indirect branches in the future. This applies to jmp indirects, call indirects and returns. As this restricts the processor from using all previous indirect branch information, it is intended to only be used by software when switching from one user context to another user context that requires protection, or from one guest to another guest.
• IBPB is the AMD recommended setting for Windows mitigation of Google Project Zero Variant 2 (Spectre).
• IBPB combined with Reptoline software support is the AMD recommended setting for Linux mitigation
of Google Project Zero Variant 2 (Spectre).

"Minimierung" schreiben sie, nicht = nicht möglich oder Verhinderung! Stand 12. Januar 2018! Ob mich das privat betrifft, ist wieder ein anderes Thema. Wahrscheinlich ist es ihnen selbst in Testphasen gelungen etwas zu simulieren, ehrlicherweise sollte man sich dann auf AMD verlassen nicht auf Foren (-meinungen).

Schönen Tag noch.:D
 
du krallst dich wirklich an dem Begriff Mitigation fest , was , hier haste noch n paar Mitigation https://developer.amd.com/wp-content/resources/Managing-Speculation-on-AMD-Processors.pdf
ganze 11 x Mitigation ...

warum Milderung und nicht Verhinderung ? weil das ne komplett neue Hardware brauchen würde ...
Spectre ist ne komplett neue Sicherheitslücken Klasse , primär für Intel CPU s , da wird s nicht nur einen Fix für geben https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)
Since Spectre represents a whole class of attacks, most likely, there cannot be a single patch for it.
 
MK one schrieb:
du krallst dich wirklich an dem Begriff Mitigation fest ...
Falls du mich meinst:
Ja.
Mitigation != Fix
Mitigation != Verhinderung
Mitigation != Nicht betroffen

... warum Milderung und nicht Verhinderung ? weil das ne komplett neue Hardware brauchen würde ...
Genau!
 
Zuletzt bearbeitet:
Sun_set_1 schrieb:
@donend

Was mir zu Dir nur einfällt:
Ein Geisterfahrer? Hunderte!

TechNet ist öffentlich zugänglich. Einen googlebaren Link zu posten, ist völligst legal. AMD ist weniger angreifbar, da der BTB zufällig und nicht logisch bzw. mit Platzhaltern beschrieben wird. Das ist ein sehr großer Unterschied.

Insofern ist "genauso" faktisch falsch. Es sei denn, du kannst mir belegen, dass der BTB innerhalb der CPU bei AMD auch nach einer gewissen Logik befüllt wird, welche bei Intel das Ausnutzen deutlich vereinfacht. Bitte um Antwort.

Weiterhin antwortest Du ausschließlich auf selektierte Fragen. Alles bei dem du mit Links oder Quellen widerlegt wirst, übergehst Du einfach - nur um deine Thesen dann zwei Seiten weiter erneut zu verbreiten. Sollte man dich festnageln und beispielsweisen mit Quellen belegen, dass der BTB bei AMD anders befüllt wird, kommt sinngemäß "Und was ist mit anderen Lücken bei AMD, die vllt noch nicht entdeckt sind?" Das ist whataboutism der schlimmsten Sorte. Einfach mal lesen. Es hat nämlich inhaltlich nichts mit dem Argument zu tun, dass der BTB anders befüllt wird.

Nein Du ziehst dich dann daran hoch, dass AMD wahrscheinlich genauso viele Lücken hat (deine Theorie) nur um der Verbreitung wegen weniger attackiert wird. Das wird dann über drei Postings von dir weiter geredet um dann schlussendlich wieder bei deiner Aussage zu landen "AMD ist genauso betroffen" Das ist getrolle.

BTW: Erkläre mir doch bitte mal, mit deinen eigenen Worten, wofür der BTB da ist und welche Verarbeitungsaufgaben er innerhalb eines Taktzyklus übernimmt / bereithält. Weiterhin erkläre mir einmal kurz, wie genau Spectre nun Schwachstellen im selbigen ausnutzt. Nach deiner eigenen Darstellung müsstest Du über dieses Wissen verfügen. Denn ansonsten wäre deinen Theorien, Theorien von jemanden der nicht weiß aus welchen Teilen eine CPU besteht und wie diese überhaupt arbeitet.

Was bitte sind Channelsicherheitsanfälligkeiten? Das Wort habe ich noch nie gehört. Ich kenne Seitenkanalattacken.



donend schrieb:
Das brauch ich alles nicht selbst, du kannst dir einbilden was du willst. AMD teilte mit Whitepaper vom 10.04.2018 mit was wie wo warum, lesen und den Sicherheitshinweisen folgen. Seit wann ist ein Zugang im Security Tech Center eine per Google verlinkbare Informationsquelle?

Das ist wahrscheinlich genauso blöd geschrieben wie "Kanalsicherheit" in denglisch.

Quod erat demonstrandum
 
Sun_set_1 schrieb:
Weiterhin antwortest Du ausschließlich auf selektierte Fragen. Alles bei dem du mit Links oder Quellen widerlegt wirst, übergehst Du einfach - nur um deine Thesen dann zwei Seiten weiter erneut zu verbreiten. Sollte man dich festnageln und beispielsweisen mit Quellen belegen, dass der BTB bei AMD anders befüllt wird, kommt sinngemäß "Und was ist mit anderen Lücken bei AMD, die vllt noch nicht entdeckt sind?" Das ist whataboutism der schlimmsten Sorte. Einfach mal lesen. Es hat nämlich inhaltlich nichts mit dem Argument zu tun, dass der BTB anders befüllt wird.

Nein Du ziehst dich dann daran hoch, dass AMD wahrscheinlich genauso viele Lücken hat (deine Theorie) nur um der Verbreitung wegen weniger attackiert wird. Das wird dann über drei Postings von dir weiter geredet um dann schlussendlich wieder bei deiner Aussage zu landen "AMD ist genauso betroffen" Das ist getrolle.

Stimmt genau und gut beschrieben. Leider zieht sich seine Masche schon durch den ganzen Thread. Seine Beiträge werden auch nicht gelöscht, obwohl es absolut irrelevant ist, wie stark seiner Meinung nach AMD von den älteren Sicherheitslücken betroffen ist. Hier geht es um die neuen Sicherheitslücken und ich für meinen Teil scrolle nur durch die Kommentare, um durch andere User eventuell auf neue Informationen und Auswirkungen aufmerksam zu werden. Seine Beiträge behindern den Informationsaustausch (besonders durch seine bewussten Falschaussagen). Seine einzige Agenda scheint die Relativierung zu sein, schade.

MK one schrieb:
@donend
Man kann AMD doch jetzt wirklich nicht vorwerfen sie hätten nichts getan , oder ? Schneller als Intel war AMD damit ...

Eben weil es Typen wie dich gibt , die ein theroetisches Angriffsrisiko bereits als praktisch umgesetzt betrachten hat AMD nachgebessert , schon allein um mit Intel gleichzuziehn

Es wäre auch fahrlässig, dies nicht zu tun. Aktuell gibt es zwar keinen bekannten Angriff oder ein Konzept, aber was meinst du was los wäre wenn es in ein paar Jahren doch einen Angriff gibt und AMD hätte das Problem in der Zeit einfach ignoriert?

Durch den "Fix" zeigen sie nur, dass sie verantwortungsbewusst handeln, weil sie einen Angriff nicht zu 100% ausschließen können. Manche Leute hier im Forum meinen aber leider, dass man ihnen gerade daraus einen Strick drehen kann, einfach absurd.
 
Zuletzt bearbeitet:
Die Zeiten ändern sich. Früher stand bei Forenbetreibern/Mods im Vordergrund, Trolle und Beiträge mit offensichtlichem Fehlverhalten zu löschen (Beleidigungen, rechtliche Verstöße).

Heute muss auch noch geprüft werden, welche User mit bewusst angewendeten geschickten rhetorischen Mitteln Unwahrheiten in Threads verbreiten, möglicherweise mit der Absicht Unternehmen oder einzelnen Personen zu schaden und andere User davon zu überzeugen. Das hat ja bereits früher hervorragend funktioniert.
Die Unsitte, nur ausgewählte Textteile herauszupicken und die mit Quellen belegten Teile zu ignorieren ist mir bei manchen Usern schon häufiger aufgefallen, vor allem in AMD vs Intel-Threads.

Genau diese User zu filtern ist sehr schwer und bindet eine Menge Ressourcen (hier: Moderatoren), zumal die Ausprägung Richtung "Troll" fließend sein kann.
 
Prüfen diese Tools eigentlich direkt ob das System verwundbar ist anhand von kontrollierten Selbstangriffen? Oder wird wie öfter nur gescannt ob irgendwas zur Verhinderung bereits installiert wurde?

Mich interessiert der Ansatz, da überall immer erzählt wird es sei Superkompliziert oder nahezu undenkbar, dass man diese oder jene Lücke ausnutzt, andererseits aber bereits fertige Tools existieren die mit 2 Buttons sagen können ob Lücke X oder Y existiert.
 
Sie prüfen ob der Schutz installiert wurde , bei AMD exestiert zb bei Spectre nur der theroetische Ansatz , noch nich mal ein " Proof of Concept " = dh. ein Nachweis das es möglich ist , anders als bei Intel CPU s . Von Meltdown war AMD sowieso nicht betroffen , nur Intel CPU s zurück bis 1995 .

Warte mal morgen ab , am 07.05 soll sich die Google Sicherheitsexpertengruppe zu den neuen Lücken äußern , darunter soll eine sein die sich relativ leicht nutzen und über eine VM zugriff auf den Host oder andere auf dem Server laufende VM s erlangen kann um zb Passwörter auszulesen .
 
Zuletzt bearbeitet:
Interessant finde ich an der Thematik eigentlich nur das plötzlich innerhalb eines Jahres ein Flaw nach dem nächsten entdeckt wird - wie ist das möglich ? Was hat man denn die letzten 25 Jahre so gemacht ? Gepennt ? ^^
 
Kennste den Spruch " Never change a running System " ? Keiner kam auf die Idee , keiner hat gemeckert und neues Design kostet A: Geld und B: könnten sich daraus neue Lücken ergeben .... .

Bei GPZ war einer der sich fragte : Hmm , könnte man sich nicht über die spekulative Befehlsausführung einklinken ... , hat da nachgehakt und was gefunden ( bei Intel ) . Es gibt sicher noch ne viele unentdeckte Sicherheitslücken , aber jetzt , da mit Spectre schon mal die Katze aus dem Sack war , haben die Sicherheitsexperten sozusagen Blut geleckt nach dem Motto : Ah ha , so funktioniert das also , könnte man dann nicht auch noch .... und das müßte dann ja auch funktionieren , usw.usw

im übrigen gab s auch in den letzten 25 Jahren jede Menge Sicherheitslücken die nach und nach gestopft wurden , diese Lücke ist anders in dem Sinne : Wenn man die spekulative Befehlsausführung einfach abschaltet hat man massive Leistungseinbußen , deswegen ist das keine Lösung
 
Artikel-Update: Wie abermals Heise berichtet, wird aus der für heute anberaumten Veröffentlichung erster Patches gegen die neuen Lücken nichts – der neue Microcode ist noch nicht fertig. Stattdessen sollen Intel und die Partner jetzt den 21. Mai 2018 anvisieren. Aber auch das ist noch nicht sicher. Einen Patch für die von Heise als besonders gefährlich für Cloud-Anbieter eingestufte Lücke soll es sogar erst im 3. Quartal geben, derzeit stünde der 14. August im Raum.

Bis auf das von Intel bereits am vergangenen Donnerstag veröffentlichte Statement gibt es zu diesem Thema auch weiterhin keine offiziellen Verlautbarungen. Sollte Googles Project Zero an der 90-Tage-Frist bis zur Veröffentlichung neuer Sicherheitslücken festhalten, müsste sich daran zwar noch heute etwas ändern. Sollten die Lücken allerdings in der Tat mindestens so gravierende wie die ersten Spectre-Sicherheitslücken sein, dann dürfte Google auch in diesem Fall mehr Zeit gewähren, um erst dann zu informieren, wenn es potentiell Updates gibt. Im Januar war die Industrie allerdings trotz eines halben Jahres Verschwiegenheit immer noch nicht bereit.

Vielleicht lassen sich einige Lücken aber auch erneut wie bei Meltdown allein durch ein Betriebssystem-Update schließen. Dann könnte es schon am Dienstag zum Microsoft-Patchday im Mai weitere Informationen geben.
 
Autsch...Ich bezweifle das bis August die Infos unter Verschluss bleiben.
 
Einerseits richtig, dass Google Zero blabla mit dem veröffentlichen der Infos warten sollte um Cloudanbieter zu schützen, anderer Seits ist es aber ein falsches zeichen an die Hersteller! Denen muss bei solch gravierenden Lücken die Pistole auf die brust gesetzt werden. Erst die Veröffentlichung von Infos zu dieser Sicherheitslücke und der damit einhergehenden Gefahr für alle lässt den Aktienkurs sinken!
 
denke mal auch der neue Termin wird nicht halten , da Intel bereits ne Verlängerung beantragt hat ...
https://www.heise.de/security/meldung/Spectre-NG-Intel-verschiebt-die-ersten-Patches-koordinierte-Veroeffentlichung-aufgeschoben-4043790.html
Intel plant jetzt eine koordinierte Veröffentlichung am 21. Mai 2018.
....
Gemäß unseren Informationen hat Intel bereits eine weitere Fristverlängerung bis zum 10. Juli beantragt.

da steht bestimmt schon seit Monaten bei der entsprechenden Intel Programmierabteilung der Schweiß auf der Stirn :evillol: , na ja sie hatten auch auch jahrelang nen ruhiges leben ...
 
Zuletzt bearbeitet:
O-Saft-Killer schrieb:
Und wenn Intel die Lücke nicht so einfach/schnell schließen kann? Willst du wirklich die Nutzer alle damit in Gefahr bringen?
Nein natürlich nicht!
Aber wer sagt, dass sie es nicht wirklich können? Da ist halt absolutes Vertrauen gefragt. Wenn Intel sagt, dass es kostentechnisch kein Sinn ergibt doppelt so viele Ingenieure damit zu beauftragen und dadurch lieber einen Monat länger braucht und damit die Frist nicht einhält, ist das nicht in Ordnung.
 
Nachdem Intel mit "sich Zeit lassen" ja bereits vorbelastet ist, sollte ihnen diesmal keine Nachsicht gewährt werden. Irgendwann muss schluss sein, offensichtlich räumt Intel der Schließung von Lücken nicht genug Priorität ein und braucht deshalb so lange, denn fähige Leute und Ressourcen sollten sie ja genug haben.
 
Zurück
Oben