Intel CPUs Bug: Twitter Proof of Concept Exploit: Allgemeines Verstaendnisproblem

[fork(Agent Smith)]

Hallo Community,

Seit gestern kursieren in den Medien diverse Hiobsbotschaften bezueglich eines Fehlers in Intel CPUs.

Hier zum Nachlesen:
HEISE.DE: Massive Luecke in Intel CPUs erfordert umfassende Patches
oder
STANDARD.AT: Intel-CPUs Verheerende Luecke Fix resultiert in Performance Verlust

Unter anderem hat ein Poster bei STANDARD.AT auch einen Twitter-Link zu einem Exploit gepostet, auf den
ich gerne naeher eingehen moechte. Hier habe ich das Verstaendnisproblem:

Den Exploit finde ich jetzt etwas unpassend, da das Sicherheitsleck nicht wirklich ersichtlich wird.
Weil, wenn ich jetzt als Nicht-root User die Adresse in der Datei /proc/kallsyms nicht auslesen
kann (habe ich bei meiner Distribution versucht), dann sehe ich nicht wirklich ein grosses Problem bei
diesem Fehler. Und wenn ich als Angreifer schon root-Rechte habe, dann kann ich schon andere "boese"
Sachen anstellen, fuer die ich keine Exploits benoetige. Allerdings muss ich sagen, dass es etwas
schwierig ist das Problem genauer zu betrachten, da leider der Autor des Exploites den Quellcode für
die Datei speculative_table_lookup.c und sidechannel.S nicht veroeffentlicht hat. Somit
kann ich nur mutmassen.

Also irgendwie, finde ich, wird das Problem kuenstlich aufgebauscht. Sollte ich falsch liegen, dann lasse
ich mich gerne eines Besseren belehren. Was meint ihr?

PS: Zugegeben, ich habe nur diese Artikel gelesen. Nicht die Original-Quellen, die vielleicht das Problem
genauer erklären.

Edit: /proc/kallsyms nicht /etc/kallsyms

Edit (Nummer Zwei):
Ich glaube, ich muss diese zwei Seiten noch genauer durchlesen:
Meltdown and Spectre
https://googleprojectzero.blogspot.co.at/2018/01/reading-privileged-memory-with-side.html

Edit (Nummer Drei):
Kurz und bündig erklärt:
http://blog.cyberus-technology.de/posts/2018-01-03-meltdown.html
Werde ich ausprobieren...wenns funktioniert (sofern es in der VM möglich ist, und der Kernel noch nicht
gepatcht ist - habe derzeit nichts anderes zur Verfügung), dann dumm gelaufen...

 

[bitmuncher]

Aufgebauscht ist das Problem nicht wirklich, da auch unauthorisierte Prozesse in den Kernel-Mode wechseln um bestimmte systemseitige Vorgänge (Erstellen von Sockets u.ä.) auszuführen.

 

[fork(Agent Smith)]

Aufgebauscht ist das Problem nicht wirklich, da auch unauthorisierte Prozesse in den Kernel-Mode wechseln um bestimmte systemseitige Vorgänge (Erstellen von Sockets u.ä.) auszuführen.

Okay, meine Einschätzung hat sich bei der genaueren Betrachtung des Fehlers mittlerweile geändert. Die Verwendung des Wortes "aufgebauscht" war etwas zu vorschnell und überspitzt.

 

[Chromatin]

Aufgebauscht ist das Problem nicht wirklich, da auch unauthorisierte Prozesse in den Kernel-Mode wechseln um bestimmte systemseitige Vorgänge (Erstellen von Sockets u.ä.) auszuführen.

Normalerweise überlässt man sowas Prozessen, die mit entsprechenden Rechten laufen und holt sich dort das benötigte Material via API(Sys)Calls.

Okay, meine Einschätzung hat sich bei der genaueren Betrachtung des Fehlers mittlerweile geändert. Die Verwendung des Wortes "aufgebauscht" war etwas zu vorschnell und überspitzt.

Definitiv - dieses Teil geht wirklich "tief".


Und auch sonst...
Response to the "Meltdown" Vulnerability
Für Intel und Google gibt's nur Windows, MacOs und Android...

Und für etwas Geschichte:
'Intel Core 2' - MARC
VS.
Kernel-memory-leaking Intel processor design flaw forces Linux, Windows redesign • The Register


hrhr...

 

[fork(Agent Smith)]

[...] Und auch sonst...
Response to the "Meltdown" Vulnerability
Für Intel und Google gibt's nur Windows, MacOs und Android...

Gut zu wissen, dass auch bekannte (zwar eventuell nicht so verbreitete Betriebssysteme) keine Hinweise über
mögliche Sicherheitslücken von den zuständigen Stellen erhalten. Tja, das schiebe es auf den Kapitalismus...
Keine weiteren Kommentare dazu.

Und für etwas Geschichte:
'Intel Core 2' - MARC VS. Kernel-memory-leaking Intel processor design flaw forces Linux, Windows redesign • The Register hrhr...

Danke, kannte ich nicht. Werde ich mir durchlesen.

Aber, was ich mir wünschen würde...ist meine Meinung als hauptsächlich Hardware'ler...dass die Medien
die gleiche Sprache wie "Sicherheits Super GAU...wie Heise schreibt" auch zukünftig bei Software-Sicherheitslücken
verwenden. Weil die meisten Sicherheitsprobleme/Spionagefunktionen waren in der Vergangenheit hauptsächlich
in so mancher Software zu finden. Und hier kann die Hardware nichts dafür.

Wie auch immer. Eines zeigt dieses Problem auch auf. Auch die Hardware wird immer komplexer, dazu kommt noch
der Zeitdruck an die Entwickler von den ach so geliebten Managern, sodass für bestimmte Tests keine Zeit mehr ist.
Leidtragende ist halt wieder der Kunde, der zum Beta-Tester wird.

 

[SchwarzeBeere]

Aufgebauscht ist das Problem nicht wirklich, da auch unauthorisierte Prozesse in den Kernel-Mode wechseln um bestimmte systemseitige Vorgänge (Erstellen von Sockets u.ä.) auszuführen.

Es ist
a. eine lokal auszunutzende
b. hochgradig komplexe und schwer auszunutzende
Sicherheitslücke, die darüber hinaus nicht in der Praxis ausgenutzt oder durch einen der üblichen Verdächtigen bekannt gemacht wurde, sondern primär akademischer Natur ist. Ich halte das Problem derzeit daher für sehr aufgebauscht, was sich auch im CVSS Rating zeigt.

@Fork: Das Problem auf die Manager zu schieben ist kurzsichtig und naiv. Hardware ist wie Software fehleranfällig. Bekanntlich ist nichts ist 100% sicher. Da hilft auch mehr Zeit und Geld nicht.

Wichtiger ist vielmehr ein adäquater Prozess zum Umgang mit solchen Schwachstellen, insbesondere bei „Closed Source“ Produkten, zu denen ich auch die meiste Hardware zähle. Hier zeigt sich das eigentliche Problem hinter Meltdown und Spectre: Das Patching ist schwierig, wenn nicht unmöglich. Hardware besitzt viele Abhängigkeiten, z.B. zu Mainboards zur Speicherung des CPU Microcodes. Nur gibt es deren Hersteller schlicht aufgrund der hohen Fluktuation im Markt oftmals nicht mehr. Was soll man hier also tun, insbesondere wenn sich das Problem nicht mehr in Software lösen lassen sollte? Sollte man den Markt sich hier wirklich selbst regulieren lassen? Ich denke nicht.

Solange wir diesen Umgang nicht hinbekommen, solange werden uns Meltdown, Rowhammer, aber auch Heartbleed und wie sie noch alle heißen werden (Namen scheinen eh eher im Trend zu liegen, als anständige Lösungen...) noch lange beschäftigen.

 

[fork(Agent Smith)]

[...] @Fork: Das Problem auf die Manager zu schieben ist kurzsichtig und naiv. Hardware ist wie Software fehleranfällig. Bekanntlich ist nichts ist 100% sicher. Da hilft auch mehr Zeit und Geld nicht.

Du kannst mich ruhig naiv und kurzsichtig nennen, nur habe ich eben das bei den letzten Firmen, bei denen ich gearbeitet habe. am eigenen Leib mitbekommen. Meine Aussage
ist sicher nicht lupenrein und auch eine Pauschalierung, vor allem da es auch hoffentlich andere Firmen gibt, die so nicht verfahren. Es war zu-mindestens bei einer Firma
am Anfang auch besser, nur hat sich das leider mit den Jahren geändert. Wenn es aber einen guten Grund gibt, warum manche Firmen so verfahren, dann würde ich diesen
Grund gerne wissen. Vielleicht verstehe ich es ja.

Mehr Zeit für ausführlichere Tests hilft aber schon, Auch wenn nicht alle Fehler abgedeckt werden können. Es gibt durchaus Bereiche in der Elektronikentwicklung, die solche
Test erfordern. Solche Elektronik ist aber hauptsächlich in der Medizintechnik und z.B. Raumfahrt zu finden. Also da wo bei einer Fehlfunktion ein Menschenleben gefährdet ist.
Weiß jetzt aber nicht die betreffende ISO-Nummer (Norm).

 

[SchwarzeBeere]

Mehr Zeit für ausführlichere Tests hilft aber schon, Auch wenn nicht alle Fehler abgedeckt werden können.

Wie viel Zeit brauchst du denn? In der Praxis kann dir das in der Regel niemand beantworten, meistens heißt es nur „Je mehr, desto besser.“. Mit dieser Aussage kann man weder kalkulieren, noch irgendwie anders weiterarbeiten. Und selbst wenn du Monate ins Testing versenkst, kannst du immernoch nicht behaupten, dass etwas vollkommen sicher ist. Du kannst bei der heutigen Komplexität nicht jeden Testfall abdecken und als Unternehmen willst du das auch garnicht. Schlussendlich bleibt das Pareto-Prinzip, wenn überhaupt.

Ein kürzlich erschiener Artikel eines Microsoft-Insiders beschreibt viele der zugrunde liegenden Probleme auch sehr schön: What Really Happened with Vista: An Insider’s Retrospective
Insbesondere der letzte Satz ist zentral: The err is human.

Am Ende müssen Gehälter bezahlt und Rechnungen beglichen werden. Du kannst die Produkte schließlich auch nicht unendlich teuer machen, insbesondere wenn es sich um einen Consumer-Markt handelt, bei dem die Preise eh schon hart umkämpft sind. Ich kann den Spruch „Ship it first, fix It later“ in diesem Kontext durchaus verstehen.

Man kann, wie oben beschrieben, die Policy-Seite weiter zum Handeln auffordern, Strafen bei unterlassenem Patching fordern, Transparenz forcieren, usw. Kurz- und Mittelfristig bringt das eher nichts. Hier würde es vielmehr anbieten anstatt Shaming und Blaming Themen wie Security By Design, DevSecOps, Bug Bounty Programme, usw. weiter pushen. Wir haben so viele schöne Technologien und Ideen, die es wert sind, eingesetzt zu werden.

 

[Shalec]

Ich habe mich noch nicht wirklich ausführlich mit diesem neuen Angriff befassen können, aber auf dem ersten Blick hat man durch diese "Lücke" softwareseitig Zugriff auf gesperrte Bereiche der CPU. Sehe ich das richtig?

 

[Chromatin]

Am Ende müssen Gehälter bezahlt und Rechnungen beglichen werden. Du kannst die Produkte schließlich auch nicht unendlich teuer machen, insbesondere wenn es sich um einen Consumer-Markt handelt, bei dem die Preise eh schon hart umkämpft sind. Ich kann den Spruch „Ship it first, fix It later“ in diesem Kontext durchaus verstehen.

You made my day: Bist du wirklich der Meinung dass bei einem Konzern, der 2016 einen Nettogewinn von über 10 Milliarden USD einfährt (oder 10-tausend Millionen), keine Ressourcen hat um eine Errata-Kultur aufzubauen, die bis zu einem vertretbaren Punkt die Community involviert und damit zur Sicherheit ALLER beiträgt?

Du tust so als müsse man für ökonomische Platzhirsche eine gewisses Verständnis aufbringen. Ist das einer Money-First Agenda geschuldet oder liegt das am neuerlichen Relativismus, der es euch zur Gewohnheit macht Verantwortung stets als Abstrakte Form über Systeme zu legen und dann feierlich zu erklären dass dem ganzen nunmehr eine prinzipielle personale un-verantwortbarkeit zugrunde liegt?

*edit*

Ich habe mich noch nicht wirklich ausführlich mit diesem neuen Angriff befassen können, aber auf dem ersten Blick hat man durch diese "Lücke" softwareseitig Zugriff auf gesperrte Bereiche der CPU. Sehe ich das richtig?

Gesperrt nicht grundsätzlich. Salopp gesagt sollten diese Bereiche nicht für Userlandprozesse direkt einzusehen sein, also z.b. für den Prozess eines Texteditors oder Browsers.

 

[SchwarzeBeere]

You made my day: Bist du wirklich der Meinung dass bei einem Konzern, der 2016 einen Nettogewinn von über 10 Milliarden USD einfährt (oder 10-tausend Millionen), keine Ressourcen hat um eine Errata-Kultur aufzubauen, die bis zu einem vertretbaren Punkt die Community involviert und damit zur Sicherheit ALLER beiträgt?

Intel ist erstmal nur seinen eigenen Aktionären verpflichtet, nicht der Community oder allen anderen. Das heißt erstmal ganz kapitalistisch Gewinnmaximierung. Etwas anderes zu erwarten wäre dumm.

Wenn du dir die Zahlen anschaust, gibt Intel für die Produktentwicklung (R&D) auch etwa den Betrag aus, den sie im Vorjahr eingenommen haben. In den letzten Jahren sogar mehr, vergleichen mit den den Nettoeinnahmen. Das Geld wird also größenteils in neue Produkte und Entwicklungen reinvestiert.

Nicht weniger meinte ich mit Rechnungen und Gehälter: Wenn Intel bestehen bleiben will, sprich wenn Intel die Markterwartungen, zu denen auch kurze Release-Zyklen und alle Monate eine neue Prozessortechnologie gehören, erfüllen will, dann müssen Sie diese Umsätze heute erwirtschaften, um nicht in Zukunft gegen die vielen Konkurrenten an Boden zu verlieren.

Ich will Intel die Verantwortung für die Bugs nicht absprechen, genauso wenig will ich ihnen aber auch nicht ihren Gewinn absprechen, den Intel wortwörtlich verdient und höchstwahrscheinlich inzwischen wieder ausgegeben hat. Fakt ist dennoch, dass auch die Erwartung des Marktes mit Schuld an dieser Entwicklung ist. Speculative Execution ist primär ein Mechanismus zur Steigerung der Ausführgeschwindkeit. Das erwarten wir von Intel und das hat Intel, das zeigt der Gewinn, liefern können. Security erwartet man auch, aber dafür will man eben nicht zahlen, weder mit Zeit, noch mit Geld. Und beides braucht will man scheinbar in einer Zeit, in der wir über Stromproduktion streiten und nebenbei fleißig bitcoins minen.

Gesperrt nicht grundsätzlich. Salopp gesagt sollten diese Bereiche nicht für Userlandprozesse direkt einzusehen sein, also z.b. für den Prozess eines Texteditors oder Browsers.

Eine sehr gute und verständliche Erklärung liefert Matt „pwnallthethings“ Tait in Risky Business #482 -- Meltdown and Spectre coverage without the flappy arms - Risky Business . Scheinbar gibt es keinen direkten Lesezugriff. Stattdessen wird vom Timing der Operation auf den Wert im Cache gesichtlosen.

 

[Chromatin]

Intel ist erstmal nur seinen eigenen Aktionären verpflichtet, nicht der Community oder allen anderen. Das heißt erstmal ganz kapitalistisch Gewinnmaximierung. Etwas anderes zu erwarten wäre dumm.

Das ist eine Aussage die sehr vom Standpunkt abhängt.
Man würde annehmen dass Intel auch seinen Kunden gegenüber verpflichtet ist und idR ist das auch so, wenn jemand ein Produkt verkauft.

Wenn du dir die Zahlen anschaust, gibt Intel für die Produktentwicklung (R&D) auch etwa den Betrag aus, den sie im Vorjahr eingenommen haben. In den letzten Jahren sogar mehr, vergleichen mit den den Nettoeinnahmen. Das Geld wird also größenteils in neue Produkte und Entwicklungen reinvestiert.

Ich rede nicht vom Umsatz sondern von Gewinnen. Investitionen zahlt man vom Umsatz und vor Steuer
Aber selbst bei nur 1.000 Millionen USD Gewinn, waere noch was drin...

Ich will Intel die Verantwortung für die Bugs nicht absprechen, genauso wenig will ich ihnen aber auch nicht ihren Gewinn absprechen, den Intel wortwörtlich verdient und höchstwahrscheinlich inzwischen wieder ausgegeben hat. Fakt ist dennoch, dass auch die Erwartung des Marktes mit Schuld an dieser Entwicklung ist.

Das ist eine interessante Interpretation des Schuldbegriffes. Oder besser, eine interessante Wandlung.
Als Kunde wurde ich nie vor die Wahl gestellt, bzw. gefragt ob ich prinzipielle Unsicherheit gegen Performance eintausche.
D.h. weil sich die Player im Markt auf Performance eingeschossen haben und das das wesentliche Element ihrer eindimensionalen Marketingausrichtung war, ist der Kunde (der wohl gemerkt, nie eine Wahl hatte)
also jetzt der (Mit)Schuldige?

Würden Kunden 1. davon Kenntnis haben und 2. die Wahl, dann könnte man ihnen unterstellen, dass sie ein Risiko billigend in Kauf nehmen. Beides ist aber nicht der Fall und deswegen ist es grotesk hier von Schuld zu sprechen.

Weiterhin ist "Schuld" nicht etwas, was sich auf abstrakte Größen anwenden lässt. Schuld braucht Verantwortlichkeit.
Der Markt ist ein System und in dem System agieren und entscheiden Menschen. Und sehr wenige Menschen haben sehr viel Einfluss.
Ist VW "Schuld" am aktuellen Skandal? Nein - es sind einzelne Individuen.

Das erwarten wir von Intel und das hat Intel, das zeigt der Gewinn, liefern können. Security erwartet man auch, aber dafür will man eben nicht zahlen, weder mit Zeit, noch mit Geld. Und beides braucht will man scheinbar in einer Zeit, in der wir über Stromproduktion streiten und nebenbei fleißig bitcoins minen.

Sorry, aber designtechnischen Unzulänglichkeiten der Prozessorarchitektur werden seit Dekaden diskutiert. Und das auch bereits zu Zeiten wo es eine derartige Massenanwendung wie heute noch gar nicht gab.
Ich kritisiere auch gar nicht primär das Streben nach Marktanteilen oder die Naturgemäße Gewinnorientierung eines Unternehmens. Und ich unterstelle Intel auch nicht Absicht oder Böswilligkeit.

Ich kritisiere den Umgang mit derartigen Fehlern und die mangelnde Transparenz gegenüber denjenigen, die Teil der entwickelnden Community sind: Offene Foren für den Austausch von Errata Publikationen wo jeder gleichgestellt verfolgen kann um was es geht.
Und es ist ja nicht so dass Intel nicht auch Informationen bekommt und verarbeitet...
Und Intel kann mit seiner Marktmacht durchaus für einen (sic!) Paradigmenwechsel beitragen...

 

[Togen]

Hallo,

ich will mich ungern einmischen, aber ich glaube eure Diskussion geh in Richtung Off-Topic. Ich verstehe beide Seiten und eure Meinungen,
aber im Endeffekt können wir einfach nichts daran ändern. Intel hat bislang nach ihren Vorstellungen gehandelt und wird es auch weiterhin
tun.

 

[Chromatin]

ich will mich ungern einmischen, aber ich glaube eure Diskussion geh in Richtung Off-Topic.

Das kommt in Diskussionsforen schon mal vor

Intel hat bislang nach ihren Vorstellungen gehandelt und wird es auch weiterhin tun.

Wir sind ja auch nicht das Intel-Fanboard...

 

[Pik-9]

Hier noch mal was zur Aufheiterung. :wink:
Für die, die die Seite CommitStrip | The blog relating the daily life of web agency developers noch nicht kennen...

Viele Grüße,
Pik-9