Post by Christian WeisgerberPost by Sebastian BarthelSide Channel Attack
<https://de.wikipedia.org/wiki/Seitenkanalattacke>
Es gibt viele "Seitenkanäle" die man attackieren kann, nicht nur
Ausführungszeiten, cache-timings o.ä.
Post by Christian WeisgerberPost by Sebastian BarthelIrrtum die Idee der
von-Neumann Architektur
mit der Aufhebung der Trennung von Daten und Programm
Wo legst du bei Trennung von Daten und Programm (Harvard-Architektur)
den Stack hin?
Hmm.
Wenn Rücksprung-adressen auf den Stack sollen -> Programm
Wenn Register-inhalte so gesichert/Transportiert werden -> Daten
Wenn diese Inhalte zum Adressieren nötig sind -> Programm?
Nicht so einfach oder? ;)
Post by Christian WeisgerberTatsächlich haben wir durch die Speicherschutzattribute bei modernen
Betriebssystemen längst unschreibbare Programme und zunehmend
unausführbare Daten - und als passende Angriffstechnik dazu
Wenn man es auf x86 begrenzt betrachtet dann GAB (und gibt es
"Teilweise") ja seit 80286 in der HW Verankerte Schutzkonzepte die genau
das Leisten und ein Programm bei Fehlern sofort raus kicken könnten.
Aber weil offenbar keiner mit Selektoren und eigenen Adressräumen
arbeiten will hat man das Konterkariert durch ein Flatmemory-Modell in
dem genau diese HW-Mechanismen nicht mehr wirken können weil Code wieder
überschrieben werden kann, Daten als Code interpretiert werden könnte
u.s.w. denn technisch liegen kernel, treiber, Puffer, daten, anwendungen
alle im gleichen RAM. Und als Reaktion ließ man sich ein NX-Bit ein
fallen was m.E. nur eine Teil-lösung ist. Und gegen Böswillige Programme
ASLR was den Speicher noch mehr fragmentiert. Und was nicht noch
alles... Plus eine Vertikale Schicht Schlangenöl mit Heuristik, KI,
Blockchain oder... Voodoo drauf.
Post by Christian WeisgerberIst eine Unterscheidung zwischen Daten und Programm theoretisch
überhaupt möglich? Wenn Daten die Ausführung eines Programms
beeinflussen, sind sie dann nicht auch Programm? Was sagt die
theoretische Informatik dazu?
Keine Ahnung was "Die" dazu sagen würde. Meine "2ct" dazu wären:
Wenn du Physisch getrennte Speicher für Daten und Programm hättest
brauchst du bestimmt doch wieder eine Transfermöglichkeit zwischen den
beiden. Entweder eine Bus-kreuzung um mengen schnell zu übertragen oder
CPU-Befehle mit denen man z.b. in einer Schleife blöcke transferiert.
Damit sind diese Möglichkeiten aber prinzipiell auch einem Angreifer
eröffnet. Oder willst du einen Dritten Speicher für die Trennung von
Kern und Anwender-Programmen? Die dann WIE genau dort hinein
transferiert würden??? Loop-> End Loop!
Es gabt schon zu Homecomputer-Zeiten "selbstmodifizierenden" Code und es
hat ja auch nicht jede CPU die Addressierungsmethoden eines 6502.
Und Daten können sicherlich die Ausführung eines Programms beeinflussen,
z.b. wenn das Programm auf bestimmte Datenmuster mit einem anderen
Ablauf reagiert. Das ist dann aber schon im Programm so festgelegt, die
Daten(muster) lösen es nur aus. So wie ein Pufferüberlauf auslösen
könnte die Zu-Viel-Daten als Code zu mißverstehen. Verhindere den
Pufferüberlauf und Prüfe die eingabedaten (Junger Jedi) und Crowdstrike
hätte auch nicht so ein Fiasko anrichten können. ;-)
Außerdem denke ich das heutige x86 Prozessoren sowohl schnell als auch
ausgefuchst genug sein sollten und mit Genug RAM ausgestattet in der
Lage sein sollten mit dem Ureigenen Integrierten HW-Schutzmechanismen
schnell genug zu sein - und den ganzen FlatMem, NX u. ASLR kram damit
obsolet werden lassen könnten.
ABER: Da dies ein anderes Konzept wäre das mit vorhandenen Programmen
und Konventionen bricht wäre es ein Paradigmen-Wechsel der es zu allem
existierenden inkompatibel werden ließe. Und das nur der Sicherheit
wegen... wird wohl niemand anfangen und niemand benutzen wollen und es
wird auch keiner die Wartung dafür machen wollen. Schließlich ist das
"Nix neues mehr" (TM) und darum scheint's heute eher zu gehen. :-/
Außerdem las ich neulich das AMD bei ihrer x64-implementation offenbar
einige Dinge anders machte oder weg ließ. Der Effekt soll wohl sein das
die Schutzmechanismen des Protected-Mode dort nicht mehr uneingeschränkt
funktionieren würden. Demnach hätten wir hier ein Schisma zwischen
Intel-CPUs und AMD-CPUs die faktisch nicht mehr 100% Kompatibel wären.
Ende des Ryzen-Hype's?
Ich fände es allerdings dennoch interessant über ein Gedanken-Experiment
hinaus eine 64-bit (Intel) CPU mit genug RAM im Protected-Mode und OHNE
Paging zu betreiben. Damit wären m.W. die Linearen Adressen auch die
Physischen, und der NX-Schutz damit eh raus da er IMO in der Paging-unit
(den Seitentabellen) steckt. Und dann sehen wie weit man kommt wenn man
Stück für Stück weiter baute... Ring 0, Treiber, Dateisysteme... Ring 3
u.s.w.
... hat nicht so auch Linux angefangen. Torvalds wollte einen 386
Programmieren und fing mit einem Scheduler und kern an, zuerst auf einem
Minix basierend. Und als erst binärformat und erster Dateisystemtreiber
da waren nahm das ganze doch Fahrt auf.
Aber Linux u.Co. haben wohl nie mehr als zwei Privileg-stufen von 4
genutzt weil andere HW auch nicht mehr kennt.
Wenn wir allerdings mit systemd nun schon einen linux-only Init haben,
wer weiß was (doch) noch kommen wird. ;-)
Vielleicht gibt es irgendwann ein noch größeres Weltweites IT-Desaster
weil wieder jemand etwas saudummes angestellt oder unterlassen hat, was
jemand Ambitionierten dazu brächte einfach mal alles in Frage zu stellen
und von Grund auf einen neuen sicheren Systemkern zu entwickeln - mit
den integrierten Schutzkonzepten die eine Exception werfen wenn ein
Programm etwas versucht was es nicht darf. Und weil das Programm selbst
ja seinen eigenen Linearen Arbeitsspeicher sähe kann man evtl. auch
vorhandenes importieren oder konvertieren.
Halte ich nicht für Wahrscheinlich, aber für Wünschenswert. Eher kippt
man noch mehr Schlangenöl und KI auf eine Sache und verbrennt damit Jede
Menge Geld und Ressourcen als das obige Idee im Mainstream landen würde.
Vielleicht gibt's das ja auch schon, bei der NSA, in Nordkorea oder wo
auch immer (im Geheimen) irgendwer Gründe und Geld dafür fand.
Bye/
/Kay
--
nix