Heap Overflow

[carsti]

Heap Overflow :(

Die einzige Loesung ist die Menge an nativem Code bei einem OS mit jedem Release zu verkleinern.

Es MUSS eine basis aus C-Code geben - keine Frage. Aber diese Basis sollte so klein wie moeglich sein und permanent ge-reviewed werden. Bei allem sonstigen OS-Code und auch Anwendungs-Code sollte nur "managed" Code zugelassen werden! Keine Heap Overflows oder sonstigen Spaesse moeglich.

Ich weiss. Ich bin der Anti-Christ.

[gadthrawn]

Welcome to Singularity. Oder zu Cosmas - da ist OS basteln echt einfach.

[grorg]

Rust könnte das lösen.

[pythoneer]

grorg schrieb:
--------------------------------------------------------------------------------
> Rust könnte das lösen.

+1 Rust
-1 Managed Code

[QDOS]

grorg schrieb:
--------------------------------------------------------------------------------
> Rust könnte das lösen.
Jede Sprache die es ermöglicht einen Buffer nicht fixer größer zu verwenden, würde das lösen…

[zilti]

Jau, lasst den Sprachenkampf beginnen! Ich bin für Scheme!
Übrigens können auch managed-Sprachen solche Fehler verursachen, bloss i.d.R. mit schlimmeren Auswirkungen...

[elgooG]

gadthrawn schrieb:
--------------------------------------------------------------------------------
> Welcome to Singularity. Oder zu Cosmas - da ist OS basteln echt einfach.

Um genau zu sein gibt es bei Singularity keinen sicherheitsrelevanten nativen Code. Ein paar Zeilen Assembler und der Rest ist praktisch nur mehr managed.

Natürlich ist das keine Lösung für alle Sicherheitslücken. Es würde wohl auch schon reichen, wenn alle sicherheitsrelevanten Anwendungen einen automatisch verwalteten Speicher verwenden würden. Die wenigsten Anwendungen profitieren überhaupt von nativen Code.

Kann Spuren von persönlichen Meinungen, Sarkasmus und Erdnüssen enthalten. Ausdrucke nicht für den Verzehr geeignet. Ungelesen mindestens haltbar bis: siehe Rückseite

[carsti]

zilti schrieb:
--------------------------------------------------------------------------------
> Jau, lasst den Sprachenkampf beginnen! Ich bin für Scheme!
> Übrigens können auch managed-Sprachen solche Fehler verursachen, bloss
> i.d.R. mit schlimmeren Auswirkungen...

Geb halt mal ein explizites Beispiel.

[carsti]

elgooG schrieb:
--------------------------------------------------------------------------------
> gadthrawn schrieb:
> ---------------------------------------------------------------------------
> -----
> > Welcome to Singularity. Oder zu Cosmas - da ist OS basteln echt einfach.
>
> Um genau zu sein gibt es bei Singularity keinen sicherheitsrelevanten
> nativen Code. Ein paar Zeilen Assembler und der Rest ist praktisch nur mehr
> managed.
>
> Natürlich ist das keine Lösung für alle Sicherheitslücken. Es würde wohl
> auch schon reichen, wenn alle sicherheitsrelevanten Anwendungen einen
> automatisch verwalteten Speicher verwenden würden. Die wenigsten
> Anwendungen profitieren überhaupt von nativen Code.

Genau. Du sprichst mir aus der Seele. Mir klappt oft die Kinnlade runter fuer was fuer Programme nativer Code verwendet wird. Das sollte eine reine Nischenloesung sein! Absolut unnoetig sowas.

Wenn alle Entwicklungs-Resourcen nicht endlich waeren waer das ja alles kein Problem. Aber ich sehe bei solchen Anwendungen dann immer ein haufen Baustellen weil einfach die Zeit fehlt.
Das tollste finde ich auch oft, dass es dann nicht fuer eine Parallelisierung der CPU-intensivsten Codebereiche gelangt hat. Damit ist dann der native Code deutlich langsamer. Wobei schon bei Single-Thread Performance native nicht zwangsweise schneller sein muss als die nicht-native Konkurrenz.

[zilti]

Auch in .NET (an dieser Stelle Gruss an Singularity), der JVM und bei JavaScript-Implementationen gab es schon ganz üble Sicherheitslücken, die zum Ausführen von beliebigem Code missbraucht werden können. Bzw. gibt es ja immer wieder einmal.

(Zudem, nativer Code ist nicht immer komplett ersetzbar, es gibt nicht nur Performancegründe, auf nativen Code zu setzen, aber das nur noch so am Rande)

[carsti]

Also theoretisch nicht ersetzbar oder nicht ersetzbar weil zuviel Aufwand? Zum Beispiel haette auch keiner daran gedacht mal eben Glibc in Linux durch was anderes zu ersetzen weil zu aufwaendig. Google hats dann aber doch gemacht.

Und ja, zugegebenermassen gibt es Teile die auch theoretisch nicht ersetzt werden koennen. Wenn du meinen initialen Post liest meine ich ja auch, dass es nicht komplett ersetzt sondern minimiert werden sollte.
Singularity zeigt, dass wenig geht. Koennte sogar noch weniger sein.

Die Sicherheitsluecken von denen du in .NET, Java, JavaScript usw. sprichst sind uebrigens bei vielen schwerwiegenden Fehlern eben doch im nativen Unterbau zu finden. Uebrigens ist der native Unterbau bei .NET und Java sehr hoch! Beispielsweise ist Apache Harmony da sehr viel zurueckhaltender gewesen als Sun/Oracle.