ZeroZerp schrieb:
@All
Gut analysiert- Die Frage die sich mir als nächstes stellen würde ist eben, ob sich das Szenario für Mulitlayer- Angriffe eignet. Man also z.B. durch diesen "Flaw" in einem Zweitangriffsszenario zu einem schnelleren/konistenteren Ergebnis kommt.
Die weitere Analyse wird nach Veröffentlichung eines PoCs kommen. Bin schon gespannt....
LG
Zero
Die haben auch einen Abschnitt zu (K)ALSR drin. Den habe ich aber nur kurz ueberflogen. Dachte da waere der Multilayer Angriff. Kann aber auch was anderes sein. Aber wenn ich es richtig verstanden habe, dann reduzieren die nur die Entropie was Angriffe "einfacher" macht, weil weniger Kombinationen, aber eben nicht garantiert.
jackii schrieb:
Warum Intel nicht perfekt damit umgehen könnte, lag zu einem großen Teil auch daran dass es vom Linux Umfeld ausgeplaudert wurde bevor man Lösungen evaluieren, für sämtliche Plattformen und Chips entwickeln, testen, verteilen und optimieren konnte. Es wurde sofort weit über die IT Welt hinaus als Weltuntergang aufgeblasen obwohl die technischen Gegebenheiten und das tatsächliche Risiko das überhaupt nicht hergab.
Das spaete bekannt geben an die Kernel Community die daraufhin in kuerzester Zeit einen Fix entwickeln musste und fragwuerdige Lizenzaenderungen mit Patch-Commits sollte man nicht ganz unter den Tisch fallen lassen. Intel hat da genug selbst schuld.
ghecko schrieb:
Teils teils. Lieber Wissen streuen als Unwissen stehen lassen. Auch wenn es vllt nur für ein paar andere danach aussieht.
Um die ganze Funktionskette der Lücke zu unterbrechen muss man die decodierten Speicheradressen im cache way predictor bei jedem Zugriffswechsel auf einen anderen Prozesses zurücksetzen. Somit verliert man etwas Performance, weil in dem Fall die Daten aus dem L2D Cache nachgeladen werden müssen, aber es lässt sich durch die Zugriffszeit nicht mehr nachvollziehen, auf welche Adressen der andere Prozess zugegriffen hat. Da auf dieses Mapping alles weitere aufbaut wäre die Lücke gestopft.
Und für die nächsten Architekturen sollte AMD wohl verhindern, das ein invalider Zugriff auf einen Speicherbereich außerhalb des virtuellen Adressraumes überhaupt im cache way predictor den pointer auslöst. Invalid access = pointer rücksetzen. Letzteres muss aber wohl in Hardware implementiert werden.
Das ist aber nur eine moegliche Mitigation. Die Forscher schlagen auch andere vor.
Was, so weit ich das verstanden habe, nicht ganz stimmt ist der Zugriff auf den Speicherbereich. Das passiert eben nicht. Der Angreiferthread kann nicht darauf zugreifen, sondern es nur aendern und dann messen. Dadurch, dass die Hashfunktion aber bekannt ist, kann er rausfinden welche Adresse der andere Thread nutzt und theoretisch dort versuchen nachzuschauen. Das heisst nicht, dass er auf den Speicherbereich zugreifen kann.
Gewuerzwiesel schrieb:
Ich schlage vor du informierst dich etwas bevor du Personen diffamierst. Meltdown ist damals kurz vor der Deadline durch einen Thread im Linuxentwicklerforum aufgeflogen. Afaik hatte sogar CB darüber berichtet, dass eben dort über den Fix für eine unbekannte Sicherheitslücke in Intel CPUs geredet wurde. Daraufhin haben die Forscher ihre Ergebnisse kurz vor Ablauf der Deadline veröffentlicht um für Klarheit zu sorgen. Hatte Intel natürlich nicht geschmeckt weshalb ein Paar unglückliche PR Entscheidungen fielen.
Um die abzumildern spendierte Intel einen "Research Grant". Den abzulehnen wäre aus Sicht des Institutes unklug. Ist in Bereich Forschung und Entwicklung auch völlig normal, dass Unternehmen Universitäten beauftragen. Ich habe das in diesem Bereich auf beiden Seiten mitbekommen.
Uhm, ja, so kann man das durchaus ausdruecken wenn man gutmuetig ist. Intel hat schon vor der Bekanntwerdung ordentlich daneben gegriffen und zu spaet informiert. Die PR Entscheidungen waren auch nicht ungluecklich, sondern sagen ziemlich viel ueber ein Unternehmen aus. Vorallem wenn man als erstes mit Dreck um sich schmeisst und hofft, dass er irgendwo haengen bleibt.
Wenn das allerdings ein Research Grant ist soll er als solcher acknowledged werden. Es ist aber als Geschenk gelistet und auf Twitter reden sie von Doktoranten finanziert. Das passt nicht ganz zusammen. Es ist wichtig, dass gelistet wird wie genau die Forschung finanziert wird und da sollte man dann auch etwas aufpassen.
PPPP schrieb:
Das sind lediglich die gefundenen Sicherheitslücken, die interessieren nur leider keinen.
Interessant für Hacker sind Zerodays die nicht bereits veröffentlicht und damit noch nutzbar sind.
Der einzige Grund für das Mehr an gefundenen Sicherheitslücken bei Intel liegt am Bug Bounty Program.
Intel zahlt für jede gefundene Sicherheitslücke bis zu 250.000$ was ein großer Anreiz für Sicherheitsforscher weltweit ist. Weder AMD noch ARM zahlen auch nur einen einzigen Cent bei gefundenen Sicherheitslücken, was die aktuelle Lage erklärt.
Da AMD aber nun einen ordentlichen Sprung von Ihren 8% Marktanteil 2018 im Desktop Segment hingelegt haben, dürfte für Sicherheitsforscher auch ohne Prämie zumindest etwas Interesse bestehen, da die mediale Aufmerksamkeit wie man sieht nicht ohne ist.
Aber netter Versuch, von dem Nutzer aldaric hätte ich auch nichts anderes erwartet ehrlich gesagt.
Nein, der Grund warum Intel dran war ist schlichtweg, dass sie schon zur Einfuehrung der Core Architektur gewarnt wurden, dass das Design unsicher ist. Es hat sich nur mal jemand trauen muessen da rumzustochern. Als das passiert ist hat es natuerlich gekracht. Das Bug Bounty Programm ist jetzt eher Schadensbegrenzung weil sie genau wissen, dass durch leichte Abaenderungen immer wieder Luecken auftauchen bis sie endlich die Architektur aendern. Und natuerlich gibt es tolle PR: "Schaut mal wie vorbildlich wir sind." Die 250k sind Peanuts fuer Intel im Gegensatz dazu, dass jemand eine neue Abaenderung finden und sie ausnutzt. Der Schaden waere immens. Dass die PR funktioniert sieht man an deinem Beitrag.
@new Account() Fehler koennen passieren, ja, allerdings auf Warnungen zur Unsicherheit nicht zu reagieren und es in Kauf nehmen sind aktive Entscheidungen. Genau das muss sich Intel vorwerfen lassen.
@zEtTlAh Intel hatte Jahre Zeit es zu verbessern, da sie schon am Anfang von der Core Architektur gewarnt wurden. Sie haben es in Kauf genommen und muessen jetzt mit den Konsequenzen leben. Das ist hausgemacht.
![[wege]mini](https://pics.computerbase.de/forum/avatars/m/778/778975.jpg?1575883542){kind=avatar}
