News Sicherheitslücken: Kernel-Entwickler empfiehlt Intel SMT zu deaktivieren

[.Sentinel.]

Er redet von einer Spectre Lücker über Javascript, du entgegnest daraufhin "nur weil Java eine Lücke hat" (und damit merkt man wenn das kein Versehen war

Womit ändert Deine Differenzierung jetzt die Umstände? Was macht das jetzt besser oder anders?
Es würde auch keinen Unterschied machen ob da Silverlight, ActiveX, HTML, PHP oder was weiss ich noch immer als Platzhalter dahinterstehen würde.

dass du im Webbereich offensichtlich weniger Ahnung hast, wenn du Java mit Javascript gleichsetzt).

Weil ich flapsig nicht zwischen Java und Javascript unterschieden habe?
Was tut das zum Thema?

LG
Zero

 

[L1TerminalFault]

Ich wurde nach meiner Theorie dazu gefragt. Ich habe ledigleich wiedergegeben, was man in diesen Kreisen so munkelt.

Welche Kreise, wohl eher Deine!

Der rest Deines Posts verbietet eine ernsthafte Einlassung.
LG
Zero

Für die Zukunft, das solltest Du Dir lieber zu Herzen nehmen, Hanebüchene Äußerungen ohne jeglichen Beweis.

Wie Anmaßen, DU glaubst doch nicht wirklich, dass Du mehr drauf hättest, als die Google Entwickler, Linus Torvalds und OpenBSD Entwickler!

 

[L0g4n]

Weil ich flapsig nicht zwischen Java und Javascript unterschieden habe?
Was tut das zum Thema?

Weil man meinen könnte, dass du dir der Umstände nicht bewusst bist, dass Javascript nur soviel mit Java zu tun hat, dass die Javascript Entwickler damals diesen Namen gewählt haben, weil Java gerade eine neue Sprache und somit "angesagt war", zudem dass ohne Javascript heute die meisten Websites nicht mehr funktionen und somit einen "Bulk" von JS Code bei jedem Besuch laden und du somit beim Ansteuern jeder Website fremden, unbekannten Code ausführst (ohne es selbst vielleicht bewusst zu merken) und somit der Angriffsvektor viel, viel höher ist als man meinen mag.

 

[.Sentinel.]

Welche Kreise, wohl eher Deine!

Exakt.

Für die Zukunft, das solltest Du Dir lieber zu Herzen nehmen, Hanebüchene Äußerungen ohne jeglichen Beweis.

Für Dich noch einmal, nachdem Du es beim ersten Mal wohl nicht wahrgenommen hast.
Ned Flanders Fragte mich, was MEINE MEINUNG bzw. Standpunkt zu der Sache ist.
Und wenn Du aufmerksam lesen würdest, schreibe ich, dass sich das keiner wirklich erklären kann, der sich näher mit der Materie beschäftigt.
Ein mögliches Szenario habe ich rein spekulativ mit in den Post geworfen.

Wenn Du das aus Deinem Blickwinkel anders auffassen willst, nämlich, dass ich hier haltlos mit Anschuldigungen um mich werfe, dann ist das DEIN Empfinden und nichts weiter, da es nämlich jeder logischen Grundlage entbeert.

Ich bin mir der Gefahren von Java- Script durchaus bewust.
Wer das unkontrolliert auf unternehmenskritischen Systemen zulässt, ist sowieso nicht ernstzunehmen.

LG
Zero

 

[Ned Flanders]

Also es ist nicht so, das ich keine Ahnung von Sicherheitskonzepten hätte. Auch wenns eine andere Fachrichtung hat. Also zumindest bei uns werden halt Warnungen von Leuten die tiefe Einsicht haben (Kernel Entwickler schließe ich als außenstehender da jetzt mal ein) dann doch eher ernst genommen. Denen dann Eitelkeiten anzudichten find ich schon auch etwas gewagt. Gut möglich das die ja wesentlich mehr wissen als in der Presse steht.

Aber wie gesagt, das Betreiben einer gentechnischen Anlage und das betreiben eines Servers sind eventuell zwei paar Schuhe.

Trotzdem bleibe ich dabei: Wenn das BSI eine Infrastruktur als kritisch einstuft, würde ich auch Dinge umsetzen deren Ausnutzung ich für unwahrscheinlich halte. Genau deswegen, weil es immer die Verkettungen von Unwahrscheinlichkeiten sind, die zur Katastrophe führen können.

Aber just my 2C

 

[.Sentinel.]

Genau deswegen, weil es immer die Verkettung von Unwahrscheinlichkeiten sind die zur Katastrophe führen können.

Exakt- Deswegen liest Du auch bei JEDEM öffentlich erhältlichen Betriebssystem, dass Du Dich bei Nutzung damit einverstanden erklärst, dass es nur in nicht- kritischen Umgebungen eingesetzt werden darf, nichts auf Geräten mit lebenserhaltenden Maßnahmen, dass das System sowieso nur ein Hobbyprojekt ist (könnte man meinen, wenn man das teilweise durchliest) und und und.....

Insofern ist man ja sowieso immer der gelackmeierte, wenn irgendwas schief läuft.
Nochmals- Die Lücken sind (waren) da. Einige sind weg, einige (noch) weiter abgeschwächt.
Was die Zukunft bringt weiss niemand, was aber nicht allein auf diese Thematik zu beziehen ist.

Fakt ist auch, dass dediziert gesicherte Server dadurch nicht exploited werden können. Als Einfallstor muss immer die Software dienen, also eine zweite Instanz misbraucht werden.
Das macht den Umstand der Schwachstelle nicht besser, die Praxisrelevanz aber sehr wohl.

LG
Zero

 

[jemandanders]

@L1TerminalFault

Aber ich warte noch drauf dass einer AMD als Verschwörer enttarnt

Warum Enttarnen? Das liegt doch auf der Hand!

AMD hat sich vor der Implementierung von SMT die Berichterstattung und das pdf von Colin Percival zum ersten Seitenkanalangriff beim P4 aus 2005 durchgelesen und anschließend absichtlich weniger Fehler als der Wettbewerb eingebaut, um sich einen ungerechtfertigten Wettbewerbsvorteil zu verschaffen. Nach dem Release der Ryzen CPUs haben sie Projekt Zero und insbesondere Daniel Gruß einen heißen Tipp gegeben, wo sie am besten mal suchen sollten.
Um keinen Verdacht aufkommen zu lassen, haben sie nicht Perfekt gearbeitet, so das sie noch einige Fehler zum Finden übrig gelassen haben. Spectre haben sie aber wohl falsch eingeschätzt.


Falls jmd Ironie oder unbewiesene Behauptungen/Spekulationen finden sollte, darf er diese gerne für sich behalten.

 

[Ned Flanders]

Bleibt halt der Punkt, dass eine nicht ganz kleine Gruppe von Kernelentwickler sagen, mal solle es besser abschalten (und dies bei einigen Produkten auch proaktiv tun - BSD/ChromeOS).

Du stehst da halt gegen deren Auffassung - was man durchaus machen kann - und musst dir deswegen halt hier anderweilige Meinungen anhören. Kann ich schon auch nachvollziehen.

 

[L1TerminalFault]

Theo de Raadt (BSD Entwickler) rät von Intel CPUs ab!

Greg Kroah-Hartman warnt vor Hyper-Threading (SMT). Dieses Hardware Problem seitens Intel ist brandgefährlich. Das immer und immer wieder Leute auf 9 Seiten versuchen INTELS Hardwarefehler zu relativieren ist schon grenzwertig. Sehr kluge Leute, die richtig Ahnung haben, weisen auf das Problem hin und einige haben nichts anderes zu tun, als Software aufzuführen, die angeblich noch mehr Lücken hätten.

Dieser HARDWARE-Fehler ist Betriebssystemunabhängig! Daher Hyper-Threading (SMT) abschalten!

 

[.Sentinel.]

Theo de Raadt (BSD Entwickler) rät von Intel CPUs ab!

Sehr schön, dass Du den Ball für mich ins eigene Tor versenkst. Da lagen wir mit der Theorie und meiner möglichen Erklärung (wenn man tiefer gräbt) doch garnicht so schlecht. ->Gekränkte Eitelkeit

OpenBSD-Mastermind Theo de Raadt ist für klare Worte bekannt und hat Intels Umgang mit Meltdown, Spectre und Spectre-NG bereits deutlich kritisiert. Auf der Konferenz BSDCan 2018 in Kanada hatte de Raadt am vergangenen Samstag abermals Intel beschuldigt, mit Informationen zu Spectre-NG hinterm Berg zu halten. Dabei erwähnte er Details zu dem Bug Lazy FP State Restore (CVE-2018-3665), die letztlich dazu führten, dass dieser Fehler vorzeitig veröffentlicht wurde. De Raadt kritisiert auch, dass die Frist bis zur Veröffentlichung des Bugs viel zu lange angesetzt worden sei.

https://www.heise.de/security/meldu...OpenBSD-Entwickler-Theo-de-Raadt-4078903.html

Wenn man sich die Historie ein wenig weiter ansieht, ist er einfach nur beleidigt, dass ihm keiner eine Krone auf den Kopf gesetzt hat bzw. sich nicht entsprechend seiner eigenen wahrgenommenen Wichtigkeit geschätzt und auf ihn reagiert hat.

The situation is very complex, continually evolving, and is taking too
much manpower away from other tasks. Furthermore, Intel isn't telling
us what is coming next, and are doing a terrible job by not publically
documenting what operating systems must do to resolve the problems.
...
So please try take responsibility for your own machines: Disable SMT in
the BIOS menu, and upgrade your BIOS if you can.

https://marc.info/?l=openbsd-tech&m=153504937925732

Da hat ihn die Angst getrieben, dass er mit seinem als besonders sicher geltendem Betriebssystem was um die Ohren fliegt, von dem er noch keine Ahnung hat. Offensichtlich wusste/weiss er auch nicht, wie die Lücke funktioniert. Ansonsten müsste er nicht auf Aussagen von Intel warten oder andere Betriebssysteme ausschnüffeln, wie diese gehärtet werden.

Punkt 2:

Greg Kroah-Hartman warnt vor Hyper-Threading (SMT). Dieses Hardware Problem seitens Intel ist brandgefährlich. ... Sehr kluge Leute, die richtig Ahnung haben, weisen auf das Problem hin und einige haben nichts anderes zu tun, als Software aufzuführen, die angeblich noch mehr Lücken hätten.

Da hast Du Dir ja wieder einen von sich selbst überzeugte, wenn auch in manchen Gebieten (zufälligerweise gerade zu unserem Thema) unfähige Person rausgesucht. Nächster Ball, den Du mir direkt vors Tor spielst:

Ich zitiere (zu seinem mehr als peinlichen Spectre Patch- Versuch, der genau das Gegenteil bewirkt hat):

Vielmehr hat der für die meisten stabile Zweige zuständige Entwickler Greg Kroah-Hartman nicht nur den fehlerhaften Patch übernommen, sondern offenbar auch versucht, die Compiler-Warnung durch ein Vertauschen von Codezeilen zu beheben.

https://www.golem.de/news/linux-kernel-entwickler-verhauen-einfachen-spectre-fix-1909-143628.html

Der scheint ja gerde diesbezüglich wirklich sehr viel Ahnung zu haben. Und solchen Leuten vertraust Du und hebst Du auf ein goldenes Podest? Must Du selbst wissen...

Alles in allem ist es unter Anderem mein Job, diese Systeme auf Anfälligkeiten zu testen.
Insofern können wir gerne einen fachlich sauberen Diskurs zum Thema führen.
Diesbezüglich bist aber zumindest Du meilenweit von einer sachbasierten Diskussion weg, der machst hier in irgendeiner Art und Weise klar, welche Expertise Du vorzuweisen hast.
Esseidenn Du nimmst den von Dir selbst gewählten Namen als "Visitenkarte".
In mir löst Dein Username und der Argumentationsstil aber eine Assozation von Hähme aus, denn von ernsthafter Auseinandersetzung mit diesem Thema.
Ich habe hier im Gegensatz zu Dir schon handfestes Material geliefert, welches belegt WARUM ich (inkl. diverser Teams) zu den Risiko- Einschätzungen gekommen bin (sind).

Und ich geb Dir einen Tipp- Sei nicht so Obrigkeitshörig.
Linux, BSD (und was weiss ich was für Entwickler) sind auch nur Menschen - Und hinter den Personen stecken erstaunlich oft Leute mit offensichtlicher Profilierungssucht, Profilneurosen und einem bedingungslose Kampf gegen konkurrenz- Betriebssysteme oder Hersteller, wenn die nicht sofort auf jedes Quaken eines Entwicklers reagieren (NVIDIA Fuck you! Sag ich da nur).
Wieviel Politik und Konkurrenz da oft auch manchmal dahintersteckt, kannst Du in jedem Entwicklerforum erleben.

Und mein Job ist es unter Anderem genau den Mist, den sie mit ihren Systemen verzapfen zu prüfen und den Firmen, die das einsetzen eine Risikobewertung zukommen zu lassen.

So gesehen stehe ich also auf DEINER Seite! und sorge dafür, dass auf Gefahren aufmerksam gemacht wird.
ich stehe nur nicht drauf, wenn man aufgrund von Presse und einigen Lautstarken ein verschrobenes Bild von "Risiken" bei der Nutzung von Computern erhält.
Jedes OS stellt ein 1000x größeres und schwerwiegenderes Risiko in unendlich vielen Modulen, Bibliotheken, Treibern etc. zur Angriffsfläche nach außen, als die Schwachstellen, von welchen wir hier reden.

Grüße
Zero

 

[Naru]

Dass ZombiLoad und Spectre Next Generation die Leistung des Thread-Level Parallelism und Instruction-Level Parallelism (patentiert bei der Parallel Architectures and Compilation Techniques) von Intel, aka Hyper-Threading Technology, und von schnellen Memories erheblich einschränken gilt seit der Windows 10 Build 1903 praktisch als erwiesen an, weil die Cache- und Speicherhierarchien, diese davon betroffen sind, den Takt angeben.

 

[.Sentinel.]

@Naru
Natürlich wird das eingeschränkt. Und wie hoch ist der real- world- Impact dieser Einschränkung?
Mit aktuellen Hard-/Softwaremitigations lt. aktuellen Tests 1,8% mehr als bei den Konkurrenz CPUs.
Soll das jetzt irgendwen beunruhigen, der nicht nur synthetische Benchmarks auf seinen Maschinen fahren will, die gezielt die Funktion dieser Schwachstelle penetrieren?

Die gesamte Debatte wird viel zu aufgeregt geführt... Wie gesagt- Es ist nicht schön.
Und ja- Im Extremfall kann man damit mit wahnsinnig viel Glück mal einen konsistenten Datenfetzen extrahieren. Mit noch mehr Glück gibts in dem Datenfetzen ein zusammenhängendes Passwort und mit dem Glück des Glück des Glücks befinden sich Headermuster in dem Datenfetzen, der die Suchroutine darauf aufmerksam macht, dass es ein Passwort der Anwendung XY sein könnte.

Und nein- Als Hacker hole ich mir das Passwort nicht durch diese Schwachstellen, sondern durch etliche ungepatchte Schwachstellen über eine im Netz exponierte Applikation, social hacking, eine Kernel-/Treiberschwachstelle oder Sonstigen viel einfachere/Erfolgsversprechendere Methoden.
An die wichtigen internen Backend- Server der Unternehmen kommst Du mit den hier besprochenen Schwachstellen und den verfügbaren Exploits nicht ran. Ausgeschlossen.

Dort wird so manch vorsichtiger Admin dann wohl auch HT deaktivieren.
Rein auf Verdacht - Unabhängig ob sinnvoll oder nicht.

LG
Zero

 

[Naru]

@ZeroZerp
Leider habe ich SKL-S, von daher sind die von offizieller Seite her ermittelten Leistungsverluste von in mindestens 20% merklich sehr real. Insbesondere HT verliert in den meisten Games, diese damit sehr stark bedingen. Ein Viertel bis ein Drittel sind real.

Hier mal einige Benchmarks zur Build 1903 im Vergleich zur Build 1809 mit den von davor schon bestandenen Leistungsverlusten in den Instructions per second (IPS).

https://abload.de/gallery.php?key=kFyD6btg