Gibt es CPUs, die den alten Speicherinhalt auf den der Stapelzeiger zeigte, selbstständig löschen?

Nano schrieb:
> die alten Daten werden bei vielen CPUs nicht
> gelöscht, sondern bleiben erhalten

Ich wette eine Tüte Haribo: bei allen.

Georg

Georg schrieb:
> Nano schrieb:
>> die alten Daten werden bei vielen CPUs nicht
>> gelöscht, sondern bleiben erhalten
>
> Ich wette eine Tüte Haribo: bei allen.
>
> Georg

Wetten tue ich nicht, aber was spräche denn dagegen eine CPU zu 
entwerfen, die aus Sicherheitsgründen den Stack automatisch aufräumt?
Das wäre ja durchaus nebenläufig bzw. gleichzeitig während die CPU den 
Stapelzeiger oder andere Befehle ausführt, solange sie nicht selbst auf 
das RAM zugreift, möglich.
Nur dann, wenn sie auf das RAM zugreift, müsste das RAM für diese 
blockiert sein, bis diese nebenläufige Aufräumarbeit erledigt ist.

Ja, das kostet dann etwas Geschwindigkeit, aber erhöht dafür die 
Sicherheit.

Sollte das RAM des Stacks wie ein Cache auf dem Prozessor Die enthalten 
sein, wäre aber auch das optimierbar. Mit dem Haken, dass der Stack dann 
eine maximale Größe hätte, die nicht überschritten werden könnte.

Bei WASM gibt es einen Funktionsstack, der nicht direkt mit den anderen
Instruktionen zugreifgar ist, also aus dessen Sicht nicht im Speicher
des Programms sichtbar ist. Das ist aus gründen der JS Interoperation.
Beim Laden des Programms stehen die Einsprungspunkte fest. Man hat dann
quasi handle, statt Adressen, die man anspringt (der ist einfach ein
Index in eine Tabelle, glaub ich). Aber direkt kommt man an den nicht
ran. Er existiert aus Programmsicht quasi gar nicht.

Εrnst B. schrieb:
> Der zweite "tuwas"-Aufruf müsste dann blockiert werden, bis der
> Speicher-Aufräumer fertig ist.

Ja, bei solchen großen lokalen Arrays, die auf den Stack kommen wäre das 
dann so. Aber es gibt ja auch Funktionen, wo man nur ein paar wenige 
Werte auf dem Stack sichern muss und die nächsten Befehle nach dem 
Rücksprung ins Hauptprogramm arbeitet vielleicht erstmal nur mit den 
Registern, damit hätte man also Zeit für den nebenläufigen 
Stackaufräumer, die dieser dann nutzen kann.

DPA schrieb:
> Bei WASM gibt es einen Funktionsstack, der nicht direkt mit den
> anderen
> Instruktionen zugreifgar ist, also aus dessen Sicht nicht im Speicher
> des Programms sichtbar ist. Das ist aus gründen der JS Interoperation.
> Beim Laden des Programms stehen die Einsprungspunkte fest. Man hat dann
> quasi handle, statt Adressen, die man anspringt (der ist einfach ein
> Index in eine Tabelle, glaub ich). Aber direkt kommt man an den nicht
> ran. Er existiert aus Programmsicht quasi gar nicht.

Gut, du meinst mit WASM wohl WebAssembly. Ja, das ist dann eine 
Softwaregeschichte. Da kann man so etwas leicht umsetzen und macht bei 
Browsern auch Sinn.
Meine Frage bezieht sich aber auf echte Hardware.

Nano schrieb:
> Das Problem dabei ist nur, die alten Daten werden bei vielen CPUs nicht
> gelöscht, sondern bleiben erhalten.

Aber nur wenn der Stackpointer, bzw. sein Ersatz viel inkrementiert. Das 
macht normalerweise keiner, sondern die Programmiersprachen übertreiben 
es da ein wenig.

Parameterübergabe oder Zählhilfen kann man anderes organisieren, und 
braucht auch keinen Stack, sondern nur Speicher an sich.

Hardwarebeschleunigte Parameterübergabe, oder eben effektiveres 
Funktionenhandling bei funktionalen Sprachen wäre nicht so verkehrt.
Habe allerdings bei diesen Haskell-Tutorials noch nicht so viel zum 
Thema Alignement finden können. Dass normale Zahlen, und Hexzahlen 
durchaus unterschiedlich sind, verstehen auch nur wenige.

Aktuell müsste man mal die RISC-Experten fragen, was es diesbezüglich an 
neueren Entwicklungen auf der Hardware-Developer-Ebene gibt.
Früher, in den 60er Jahren bzw. etwas später gab es schon "Lisp" 
Maschinen.
https://de.wikipedia.org/wiki/Lisp-Maschine.

Angebahnt hatte sich aber schon ein Kompatibilitätsproblem, obwohl 
später auf vielen Kisten Basic verfügbar war - und Basic so eine eigene 
Kompatibilitätsebene hatte.

Nano schrieb:
> Gut, du meinst mit WASM wohl WebAssembly. Ja, das ist dann eine
> Softwaregeschichte. Da kann man so etwas leicht umsetzen und macht bei
> Browsern auch Sinn.
> Meine Frage bezieht sich aber auf echte Hardware.

Tomato potato: https://github.com/piranna/wasmachine

rbx schrieb:
> Nano schrieb:
>> Das Problem dabei ist nur, die alten Daten werden bei vielen CPUs nicht
>> gelöscht, sondern bleiben erhalten.
>
> Aber nur wenn der Stackpointer, bzw. sein Ersatz viel inkrementiert. Das
> macht normalerweise keiner, sondern die Programmiersprachen übertreiben
> es da ein wenig.

Es gibt ja noch die Adressen von Unterprogrammen die auf dem Stack 
landen.
Die könnte man erneut wieder aufrufen, wenn der Stack nicht aufgeräumt 
wird.

Irgend W. schrieb:
> Was jetzt "Spielzeug µC" oder "große Applikation CPU"?
>
> Bei ausgewachsenen CPU gibt es sowas wie am ende des RAM gar nicht mehr.

Ich wollte die Frage jetzt nicht eingrenzen und das einfach mal offen 
stehen lassen.

Vor ein paar Jahren wäre der 8086 ne ausgewachsene CPU gewesen und der 
legt den Stack auf das RAM ohne MMU.

Michael B. schrieb:
> Nano schrieb:
>> Gibt es CPUs, die den alten Speicherinhalt, auf den der Stapelzeiger
>> (Stackpointer) zeigte, selbstständig per Hardware löschen?
>
> Nein.
>
> ...
> Denn der Compiler weiss, ob er den Stack überschreiben darf.
>
> Zweite Methode: Segmentierte Prozessoren ...

Danke für deine Antwort. Die genannten Punkte machen Sinn. Du hast 
recht, ich habe das bisher nur unter dem Gesichtspunkt einer einfachen 
CPU, die halt nur PUSH/POP/CALL/RET nutzt/kann, betrachtet.

Nano schrieb:

> Hier wäre es doch aus Sicherheitsgründen naheliegend, wenn der
> Maschinenbefehl wie POR, RET usw. nicht nur den Stackpointer
> aktualisieren würde, sondern auch gleich noch die alten Daten, auf die
> der Stack nun nicht mehr zeigt, gleich noch nullt bevor er verändert
> wird.

Das wäre überhaupt nicht naheliegend, und ich sehe auch keinen 
Sicherheitsvorteil. Bei Buffer Overflow mit Manipulation der 
Rücksprungadresse wird das ja vor dem RET gemacht und nicht etwa danach.

Nano schrieb:
> Hier wäre es doch aus Sicherheitsgründen naheliegend, wenn der
> Maschinenbefehl wie POR, RET usw. nicht nur den Stackpointer
> aktualisieren würde,

Welche Sicherheitsgründen? Welchen Inhalt? Worin besteht das Problem? 
Dazu noch, welcher fremde Prozess lamm auf diese Faten zugreifen? Ein 
Problem suchen, wo es keins gibt.

Ben B. schrieb:
> und damit kann man nun nicht so
> besonders viel anfangen, weil die im eigenen Programm liegt.

Damit kann man sehr viel anfangen, so funktionieren viele Exploits.

Ben B. schrieb:
> Nö, nicht nach dem erfolgreichen Rücksprung.

Ich zitiere Dich mal:

Ben B. schrieb:
> bevor sie den Return ausführt.

Merkste selber, ne?

Ben B. schrieb:
> Damit ich einen Nutzen aus übriggebliebenen Daten auf dem Stack ziehen
> kann, muss mein bereits laufendes Programm das angreifende sein

Naja, eventuell denkt er an ROP nach einem Buffer Overflow auf dem 
Stack. Aber da würde das höchstens helfen, wenn der Stack nach Oben 
statt nach Unten wächst. Aber dann überschreibt man ja auch seine 
Rücksprung Adresse nicht mehr...

Ben B. schrieb:

> Oder anders: Beschreibt doch mal ein konkretes Angriffsschema, daß sich
> durch Löschen des Stacks verhindern lässt.

Eben, weil das Entscheidende nämlich nicht gelöscht werden kann, und 
zwar die Rücksprungadresse VOR dem Rücksprung. Aber Du sagtest, damit 
könne man nicht viel anfangen, und das ist falsch. Damit kann man so 
ziemlich alles anfangen:

Selbst wenn man "nur" Code anspringt, der bereits im eigenen Programm 
vorhanden ist, kann man damit z.B. libc-Fragmente beliebig verketten und 
effektiv ein neues Programm erzeugen, das das tut, was der Angreifer 
will.

https://de.wikipedia.org/wiki/Return_Oriented_Programming
https://de.wikipedia.org/wiki/Return_into_libc

> Das gleiche könnte ich machen wenn ich einfach sage hey OS, gib mir
> allen zur Verfügung stehenden Speicher. Dann kann ich diesen komplett
> durchsuchen ob ich da was Brauchbares finde.

Wenn Du mit malloc() allozierst, wird im Gegensatz zu calloc() nicht 
garantiert genullt - aber die meisten OS (wie Linux oder Windows) wird 
Dir aus Sicherheitsgründen Speicher mit ungenulltem Inhalt nur dann 
liefern, wenn dieser vorher von Deinem eigenen Prozeß benutzt und wieder 
freigegeben wurde.

Ach ja, und eine wirksame und recht einfache Abhilfe dagegen wäre nicht 
das Löschen des Stacks, sondern unabhängige Stacks für Daten und 
Return-Adressen. Also so, daß man mit Schreibzugriffen auf den 
Daten-Stack den Return-Stack gar nicht erreichen kann.

Das Problem daran wäre aber, daß das ein komplett anderes ABI wäre, d.h. 
existierende Software wäre zu diesem Mechanismus inkompatibel.

Nop schrieb:
> Wenn Du mit malloc() allozierst, wird im Gegensatz zu calloc() nicht
> garantiert genullt - aber die meisten OS (wie Linux oder Windows) wird
> Dir aus Sicherheitsgründen Speicher mit ungenulltem Inhalt nur dann
> liefern, wenn dieser vorher von Deinem eigenen Prozeß benutzt und wieder
> freigegeben wurde.

malloc ist Sache der libc implementierung. Vom OS kann man sich (unter 
linux/unix systemen) unter anderem Speicher per mmap holen (ohne file 
(MAP_ANONYMOUS)). Die Pages sind dann genullt. Die libc hat Strategien, 
effizient Speicher zu verwalten. Also kleinere Allokationen sinvoll auf 
diese Pages zu verteilen, die es sich holt. Es wird also nicht bei jedem 
malloc Speicher vom OS geholt. Context switches sind teuer, und werden 
von Programmen wenn möglich vermieden. Am ende muss also die libc 
schauen & entscheiden, ob es den Speicher auch wieder irgendwo nullt, 
beim malloc oder free.

Aber ja, die meisten sollten das heutzutage nullen.

🐧 DPA 🐧 schrieb:

> Aber ja, die meisten sollten das heutzutage nullen.

Ja, genau - was ich meinte: bei malloc wird oft genullt, aber es ist 
nicht garantiert. Im Falle, daß nicht genullt wird, bekommt man aber 
unter OS wie Linux oder Windows nur eigene alte Daten zurück.

Nop schrieb:
> Ach ja, und eine wirksame und recht einfache Abhilfe dagegen wäre nicht
> das Löschen des Stacks, sondern unabhängige Stacks für Daten und
> Return-Adressen.

100% reicht das auch noch nicht. Ich kann ja in C auch so Zeug machen:

1

int main(){

2

  int(*print)(const char*) = puts;

3

  print("Hello World");

4

}

Man denke auch an callbacks und so, die müsste man ja auch schützen. Ich 
denke, konkreter bräuchte man einen separaten Stack für alle Buffer, die 
in irgend einer weise referenziert werden, und der Compiler nicht sicher 
stellen/wissen kann, dass da immer alles in bounds ist.

🐧 DPA 🐧 schrieb:

> 100% reicht das auch noch nicht.

Autsch, guter Punkt, an Funktionszeiger hatte ich gar nicht gedacht. 
Andererseits wäre die Exploit-Nützlichkeit davon eingeschränkt, weil man 
damit keine beliebige Verkettung hinbekommt, wenn man den Return-Stack 
nicht mit Datenzugriffen manipulieren kann.

Man könnte allerdings existierende Funktionalität aufrufen, die in dem 
Zustand nicht vorgesehen ist. Beispielsweise unter Umgehung von "Wollen 
Sie wirklich XYZ machen?" direkt zur "Ja, will ich"-Stelle springen.

Nano schrieb:
> Hier wäre es doch aus Sicherheitsgründen naheliegend, wenn der
> Maschinenbefehl wie POR, RET usw. nicht nur den Stackpointer
> aktualisieren würde, sondern auch gleich noch die alten Daten, auf die
> der Stack nun nicht mehr zeigt, gleich noch nullt bevor er verändert
> wird.

Hab jetzt die Antworten nur überflogen und meine Frage ist bereits 
beantwortet worden. Aber wie sähe denn ein Angriffsvektor aus, der auf 
alte/ungültige Werte des Stacks zugreift? Man müsste dazu ja noch 
wissen, was diese Stackwerte denn gerade in diesem Moment bedeuten. Und 
selbst dann: Was könnte ich damit anfangen? Manipulieren ist ja sinnlos, 
da ohnehin nicht mehr gültig.

Viel interessanter ist doch Zugriff auf den gerade wirklich verwendeten 
Stack zu haben und dort möglichst eine Rücksprungadresse zu manipulieren 
um fremden Code auszuführen

Gibt es eigentlich CPUs, mit eingebautem bound checking? Also wo man 
quasi erst sagt, "Speicher von da bis da, das ist jetzt objekt 1". und 
danach "Speichere X in Objekt Y an offset Z". Dann könnte man die bound 
checks in HW im Hintergrund ablaufen lassen, und es wahre viel 
schwieriger, versehentlich irgend etwas ungewollt zu überschreiben. Und 
mit C wäre sowas ja auch kompatibel, da da Pointerarithmetik ja nur 
innerhalb des selben Objekt erlaubt ist.

(prx) A. K. schrieb:
> Gästle schrieb:
>> Was könnte ich damit anfangen?
>
> ASLR cracken, d.h. rausfinden, wo eine lib liegt.

Wie würde das aussehen. Erstmal muss ich ja herausfinden, was die nicht 
mehr gültigen Werte auf dem Stack überhaupt bedeuten. Sind ja nicht nur 
Pointer. Und wenn ich dann der Meinung bin einen Pointer gefunden zu 
haben weiß ich ja immer noch nicht, ob dass eine spezielle gesuchte Lib 
ist oder nicht zumal ja die Adressen auf dem Stack in der Regel 
Rücksprungadressen sind, also keine Pointer auf Funktionen.
Könntest du oder jemand anderes etwas näher erklären, wie ich hier einen 
sinnvollen Angriff starten kann? Ich weiß ja in der Regel nichtmal 
welche Funktion denn die letzten nicht mehr gültiegen Werte auf dem 
Stack geschrieben hat.