Na dann nenn zum Beispiel einen Algorithmus der dies verhindert...
Interessiere dich ein wenig für Programmieren, Speicherverwaltung usw... und du wirst merken das es nicht so einfach ist diese Overflows zu verhindern. Vorallem da diese meist erst in der freien Wildbahn auftreten und nicht bei den Tests in der Firma.

Oh keine Sorge, ich bin über Quick Basic zu Turbo Pascal gekommen, ein kurzer, erfolgloser Ausflug zum Assembler, dann Visual Basic, Delphi, von C zu C++ dann Java. Also Interesse und Verständnis ist durchaus da, mittlerweile ist es mir allerdings zu fad, die öden Zeilen runterzuklopfen. Höchstens noch ein bisschen JavaScript :rolleyes: Und wie gesagt, einige Programmiersprachen lösen das Problem deutlich besser als C, in dem ja quasi alles erlaubt ist...

Nachtrag: Ausserdem finde ich, man macht sich's viel zu einfach. "Man kann nicht alles testen", "zuerst mal programmieren lernen, dann reden", "Fehler vom OS", "wir sind alle nur Menschen" etc. etc. ... Schwachsinn!

Wie kommen User eigentlich dazu, soviel Müll für meist unglaublich viel Kohle zu bekommen? Alles, was ein User will, ist ein Programm, welches verdammt nochmal funktioniert. Und wenn das Programm ein Sch... ist und nicht sauber läuft, dann ist es egal ob da nun ein Programmierfehler, ein Buffer Overflow oder ein Käfer in der Elektronik schuld ist. In keinem Bereich wie in der Computerbranche lassen sich Konsumenten so auf den Schädel sch....en!

niemand will, glaube ich, wirklich verhindern, dass es zu overflows kommt. sowas kann immer passieren - nur: ich will einfach, dass das programm stirbt, wenn sowas passiert. denn: WEM hilft es, wenn ein programm weiter läuft, falls bei der verarbeitung ein nicht beherrschbares problem auftritt? genau...: niemanden! im gegenteil: es ist offensichtlich erst dadurch möglich, dass sich irgend welche subjekte gestalten einen blödsinn einfallen lassen, sodass es zusätzlich zum programmfehler noch zu einem viren- oder ähnlichen befall kommt.

darum gehört das abgestellt - oder mehr noch!


und daher nochmals meine vermutung: da ... a) diese umstände allgemein bekannt sind und ... b) die compiler-hersteller nix dagegen unternehmen, folgert ... c) dass sich die hersteller von compilern sich extra dafür bezahlen lassen, dass sie diese 'löcher' in ihren produkten bestehen lassen. alles andere ergibt meiner meinung nach keinen sinn!

Gestern war ein Vortrag von MS bzgl. "Writing Secure Code".

Da wurde auch genau diese Problematik angesprochen. Aktuelle Compiler und Umbgebungen bieten Möglichkeiten das Ausführen von schadhaftem Code zu verhindern wenn ein Buffer Overrun auftritt.

Die Hauptproblematik dabei allerdings ist, dass wir derzeit Millionen von Programmen haben, welche nicht einfach so ohne weiteres überarbeitet / neu compiliert werden können vom (finanziellen) Aufwand her sowie dass es noch tausende Entwickler gibt die sich der Problematik immer noch nicht wirklich bewusst sind (und daher auch keine Gegenmaßnahmen treffen).

Darum hat man ja auch W^X erfunden, bzw. für die 386 Architektur entwickelt!

Für alle nochmal, die das jetzt noch nicht ganz verstanden haben:

Ich habe 2 Variablen: A und B
in A steht "1234567890"
in B steht "0C5B:5FF2"

A beinhaltet jetzt die Informationen über der ID-Tag und B die Sprungadresse, zu der (z.B.) gesprungen wird nach dem A verarbeitet wurde.
Im RAM steht dann: "12345678900C5B:5FF2"
Der PC/das Programm weiß ja wo was endet und was beginnt.
Wenn jetzt aber ein manipulierter (und zu langer) Tag geladen wird, steht dann im Speicher z.B.: "1234567890ABCD:EF00"
Somit wird nach der Auswertung des ID-Tags an die falsche Adresse gesprungen und folgerichtig der falsche Code ausgeführt.

Dagegen gibt es 3 Möglichkeiten:
1) Immer vor dem schreiben abfragen, ob der Wert NICHT länger ist als die Variable dimensioniert wurde,
2) Den Ausführbaren code schreibgeschützt laden, bzw Variablen mit einem Kennzeichen versehen, dass das Betriebssystem daran hindert den Code (Sprungadressen) auszuführen (was W^X beschreibt) oder
3) Den Speicherbereich nicht linear verwenden, sondern einfach zufälligen Adressen des freien RAM-Speichers verwenden. somit wird bei einem Bufferoverflow mit 99,99% Sicherheit an die Falsche Stelle (quasi ins Nichts) gesprungen.

Das Problem bei 1) ist, dass jede schreibende Aktion verlangsamen würde, so dass dies nicht jeder implementieren will. Dazu kommen noch die ganzen unwissenden Programmierer die dies schlicht und einfach nicht begreifen.

Zu 2) fallen mir keine Nachteile ein und zu 3) KANN es keine nachteile geben - abgesehen von den Page misses, die ich dabei riskiere - was mich vieleicht einige Nanosekunden ausbremst . . .

Aber M$ hat ja nicht einmal gezeigt, dass Sicherheit ein anscheinen unnützer Luxus ist. Hat ja immerhin (fast) jeder.
Die Linux-Scene ist sicherlich auch nicht perfekt, doch wenigstens glänzen die nicht so mit Fehler . . .

MfG James

@James020:

Also bitte, so einfach darf man sich das nicht machen!


Gehen wir mal in der Geschichte etwa 40 Jahre zurück - zu einer Zeit, als die EDV noch dick in den Anfängen stand und wo Assembler hoch gefeiert wurde. Klar, damit war es möglich, extrem optimierte Programme zu schreiben - optimiert in punkto Geschwindigkeit und Platzbedarf. Nur, das Zeug hatte gravierende Nachteile: eine kleine Unachtsamkeit des Programmierers, und das Chaos war perfekt.


Die logische Konsequenz war, die immer wieder selben Anforderungen mit bereits bewährten Code zu lösen. Dies brachte die ersten, so genannten Hochsprachen zutage - am kaufmännischen Sektor haben sich bis heute die beiden Sprachen Cobol und PL/1 als äußerst zweckmäßig durchsetzen können. Was ist nun der Vorteil dieser beiden Sprachen? Richtig, die Sicherheit. Nichts kostet einem Unternehmen mehr als ein EDV-System, das nicht korrekt funktioniert. In Cobol (= meine Domäne) habe ich nicht mal im Ansatz die Möglichkeit, einen Buffer-Overflow zu bekommen. Und das ist gut so - mit diesem Zeug soll sich einfach der Compiler im Hintergrund stark machen, ICH als Programmierer will davon weitgehends verschont werden. Und mittlerweile haben es Sprachen wie Cobol oder PL/1 zu einer sicherheitsmäßigen Perfektion gebracht, dass diesbezüglich keine Wünsche mehr offen bleiben.



Wo liegt also das Problem bei den Programmiersprachen für den PC? Meiner bescheidenen Meinung nach genau hier: das einzelne Individuum ist hochgradig lernfähig, das Kollektiv tut sich dagegen äußerst schwer beim Lernen. Ich sehe es täglich in meiner Firma, wo auch für den PC entwickelt wird: sämtliche Schwierigkeiten, die wir schon vor 30 Jahren gemacht hatten, werden in exakter Weise wieder am PC nachvollzogen. Nicht Einer (!!) ist auch nur ansatzweise bereit, sich von uns Programmier-Dinosauriern Tipps geben zu lassen; man wird nur mitleidig belächelt.

Ähnlich reagiert man offensichtlich in den großen Firmen, allen voran Microsoft, wo man die uralten Lösungen - noch immer - nicht aufgegriffen hat.

Freiheit ist gut - aber wenn es um die Sicherheit geht, sollte die individuelle Freiheit begrenzt werden. Aber bis dahin werden wohl noch gut 20 Jahre vergehen müssen - und die Virenprogrammierer lachen sich ob dieses fahrlässigen Verhaltens der großen EDV-Firmen ins Fäustchen!

Schön erklärt!

Ich glaube übrigens einfach, dass die Programmierer einfach zu schlampig arbeiten oder einige Aspekte schlichtweg ignorieren. Dürfte also ein bisschen in Richtung Satan's Kommentar oben gehen.

Zum Beispiel: Natürlich ist es klar, dass man nicht immer und bei jeder Variable eine Prüfung durchziehen kann, aber in vielen Fällen ginge das dermaßen schnell, dass es kaum zu Verzögerungen käme.

Im Fall des ID-Tag-Problems müsste man lediglich einmal beim Öffnen des MP3-Files/ID-Tags überprüfen, ob der Wert korrekt ist oder nicht. Das ist auf die einfachste Art eine Programmzeile und bremst das Programm nichtmal ansatzweise...

Von der Theorie hast Du mich schon verstanden... :D

Ich bin halt, wie ich immer so schön sage, im Grunde ein Kaufmann; und als solcher spielt das bisserl schlechtere Performance keine Rolle, wenn im Gegenzug die Software sicher ist. Und ich sehe Sicherheit als Grundvoraussetzung des Compilers und nicht des Programmierers. Menschen machen nun mal mitunter Fehler - Maschinen (und dazu zähle ich auch Compiler) sollten fehlerfrei arbeiten. :rolleyes:

Tjo, nun ist es aber eben leider (gottseidank?) so, dass Compiler wiederum nur von Menschen programmiert werden... :p

... mit einem entscheidenden Unterschied: ein Compiler ist das am besten getestete Programm, sodass es hier zusehends zu einer erhöhten Stabilität und Sicherheit kommen müsste. Tja, natürlich nur dann, wenn die Hersteller das wollen - und hier (siehe oben) denke ich, dass wieder die zitierte Absicht dahinter steckt.