Frage an die Programmierer
-
buffer schrieb:
Das Problem mit den 'Integer Overflows' bzw. auch 'Buffer Overflows' tritt seit Jahren immer wieder auf - sollte man nicht zwischenzeitlich aus diesen Fehlern lernen bzw. gelernt haben?
Kann mir bitte jemand erklären, wieso diese Fehler immer noch auftauchen - abgesehen mal vom Faktor Mensch?
Ich hoffe doch, dass es noch andere Gründe ausser dem Faktor Mensch gibt.
Ich erklärs dir mal am Beispiel des Menschen.
Sagen wir mal du gehst in eine Kneipe und trinkst ein wenig. Danach gehts dir gut und nix is.
Wenn du es aber übertreibst mit dem trinken, kommt später alles wieder raus!
=> der Alk übernimmt die Kontrolle über dichGenauso ist es auch mit dem Buffer. Wenn du den zu arg abfüllst mit daten, so läuft der über.
=> die daten ( exploit? ) übernimmt die KontrolleKlar?
-
Seit der erfindung des Alkohols haben die Menschen es immer noch nicht gelernt, damit vernünftig umzugehen.
Warum sollten die menschen also gelernt haben mit Buffern umgehn zu können?
-
Naja, die meisten Menschen haben schon gelernt keine Buffer-Overflows zu erstellen, denn meistens ist es doch gewollt (z.B. durch einen Hacker) um seinen eigenen Code in den Speicher zu bekommen oder einfach das System zum Absturz zu bringen...
-
Tobias W schrieb:
Naja, die meisten Menschen haben schon gelernt keine Buffer-Overflows zu erstellen, denn meistens ist es doch gewollt (z.B. durch einen Hacker) um seinen eigenen Code in den Speicher zu bekommen oder einfach das System zum Absturz zu bringen...
Das ist nicht der Punkt. Gut Software sollte das aber garnicht zulassen. Genau darum geht's ja, wenn die Software so gebaut wäre, daß das nicht ginge, dann könnte auch keiner solche Overflows erzeugen, nichtmal gewollt.
Ein Hauptproblem ist imho, daß viele C-Funktionen zum Verarbeiten von strings nicht sicher waren. Ist ja noch garnicht so lange her, daß da neue Varianten dazu kamen, bei denen man die Zielpuffergröße mit übergeben muß.
-
Guten Tag,
Das Problem ist, daß es sich nicht verhindern lässt, es ist ein Problem der PC Architektur an sich. Der Instruction Pointer muss ja bei Funktionsaufrufen aufm Stack landen dagegen kannste auch nicht viel machen.
Das eine Anwendung so programmiert sein sollte, daß keine Buffer Overflows auftreten können ist jawohl selbstredend.
MfG,
*Ranner*
-
Ich weiß noch ausm Infounterricht, dass es (laut der theoretischen Informatik) für einen Automaten unmöglich ist zu ermitteln ob ein Quellcode in einer Endlosschleife endet oder nicht (Halteproblem). Daher liegts in solchen Situationen am Faktor Mensch Endlosschleifen/-rekursionen zu finden. Da kanns dann schonmal zu Buffer Overflows kommen, wenn man was übersieht.
mfg
Xul
-
Guten Tag,
das liegt daran das viele Leute die Programmiersprache C verwenden wo sie gar nicht angebracht ist.
-
Xul schrieb:
Daher liegts in solchen Situationen am Faktor Mensch Endlosschleifen/-rekursionen zu finden. Da kanns dann schonmal zu Buffer Overflows kommen, wenn man was übersieht.
Hä? Ich kann deine Argumentationskette nicht nachvollziehen. Was hat das eine mit dem anderen zu tun. ...erklär da mal ein bischen, wie Du das meinst. Am Besten erstmal was Buffer Overflows mit Endlosschleifen zu tun haben.
-
was Buffer Overflows mit Endlosschleifen zu tun haben
Naja, eher mit Endlosrekursionen. Die nicht abgearbeiteten Funktionsaufrufe müllen dann den Stack zu, und der is irgendwann voll. Aber auch Endlosschleifen mit Zählvariablen drin können nen overflow produzieren. Da man das Finden solcher "Unannehmlichkeiten" nicht automatisieren kann (eben aufgrund dieses Halteproblems) ist es immer dem Programmierer überlassen solche Endlosschleifen/-rekursionen zu finden, und der sieht nun mal auch nicht alles.
Grüßle
dit xul
-
Ranner schrieb:
Das Problem ist, daß es sich nicht verhindern lässt, es ist ein Problem der PC Architektur an sich.
Wenn eine Anwendung einem potentiellen Angreifer aber keine Möglichkeiten bietet Exploits auszunutzen, dann gibt es kein Problem. Dann müsste man schon den Code im Speicher ändern. Das hat aber nichts mit der Architektur zu tun, sondern wäre einfach eine Sicherheitslücke im BS, zumindest wenn dies von einem anderen Rechner aus gemacht werden kann.
Ranner schrieb:
Der Instruction Pointer muss ja bei Funktionsaufrufen aufm Stack landen dagegen kannste auch nicht viel machen.
Das ist Käse. Der IP landet nirgendwo, und schon gar nicht aufm Stack. Wenn überhaupt, dann steht der IP mit dem Code Segment in Verbindung.
@topic
Buffer-Overruns sollten heutzutage nun wirklich kein Problem mehr sein, weder in C, und erst recht nicht in C++. Aber wie es nunmal so ist, es gibt diesbzgl. keine guten oder schlechten Anwendungen, sondern einfach nur gute oder schlechte Programmierer.
Etwas schlechter sieht es mit Integer-Overflows aus. Das liegt aber grundsätzlich daran, dass weder der Standard noch die diversen Architekturen selbst eine allgemeine Lösung anbieten. Das soll aber nicht heissen, dass es nicht möglich wäre. Nur ist es ein nicht unerheblicher Mehraufwand, den die meisten Leute scheuen. Manchmal nimmt man den Overflow sogar bewusst in Kauf, weil dies in den Algorithmus passt. Leider beachten diese Leute dann nicht, dass zB der C++ Standard sagt, dass dies undefiniert ist.
-
In Java gibts die doch nicht mehr, oder? Bzw man kann keine Code irgendwo platzieren, wo er nicht hin soll (ArrayIndexOutOfBounds ...).
-
Java hat als Interpretersprache (ja, das ist es, auch wenn die Javaianer gerne das Gegenteil behaupten) ganz andere Möglichkeiten, auf solche Fehler zu reagieren bzw. ihnen entgegen zu wirken. Wie stellst du dir das bei nativem Code vor?
-
groovemaster schrieb:
Buffer-Overruns sollten heutzutage nun wirklich kein Problem mehr sein, weder in C, und erst recht nicht in C++.
sollten sie dann aber vor 20 jahren genauso wenig... darum kamen und kommen die ja auch so selten vor...
-
Reyx schrieb:
Java hat als Interpretersprache (ja, das ist es, auch wenn die Javaianer gerne das Gegenteil behaupten) ganz andere Möglichkeiten, auf solche Fehler zu reagieren bzw. ihnen entgegen zu wirken. Wie stellst du dir das bei nativem Code vor?
man könnte es endlich mal lassen, "nativen code" zu verwenden. das würde uns diese probleme ersparen.
@halteproblem:
für jeden algorithmus, bei dem ein mensch eine endlosschleife erkennt lässt sich ein algorithmus schreiben, der dies ebenfalls kann. im übrigen ist das, was der mensch beim "denken" macht auch nichts weiter, als eine gute mischung aus "algorithmus" und "raten":schland:
-
Reyx schrieb:
Wie stellst du dir das bei nativem Code vor?
Für Bereichsprüfungen bei Arrayzugriffen braucht man keine virtuelle Maschine. Solche Bereichsprüfungen können auch in den nativen Maschinencode eingebaut werden. Ich sehe da gar kein Problem.
-
groovemaster schrieb:
Ranner schrieb:
Der Instruction Pointer muss ja bei Funktionsaufrufen aufm Stack landen dagegen kannste auch nicht viel machen.
Das ist Käse. Der IP landet nirgendwo, und schon gar nicht aufm Stack. Wenn überhaupt, dann steht der IP mit dem Code Segment in Verbindung.
Hmmmm?
Wieso ist das Käse? Bei mir landet der IP meistens auf dem Stack...
-
Fehler gibt es, weil es in der Natur des Menschen liegt Fehler zu machen.
Und manche Tools verleiten eher dazu Fehler zu machen als andere (aber kein einziges Tool hindert mich am Fehler machen). So dass wir das Problem haben:
Mensch macht gerne Fehler und Tool verleitet ihn dazu. Das kombiniert mit so schicken Sachen wie Termindruck, etc. macht ein nicht wirklich schoenes Gebilde daraus
-
Shade Of Mine schrieb:
Fehler gibt es, weil es in der Natur des Menschen liegt Fehler zu machen.
Und manche Tools verleiten eher dazu Fehler zu machen als andere (aber kein einziges Tool hindert mich am Fehler machen). So dass wir das Problem haben:
Mensch macht gerne Fehler und Tool verleitet ihn dazu. Das kombiniert mit so schicken Sachen wie Termindruck, etc. macht ein nicht wirklich schoenes Gebilde daraus
...womit wir dieses problem auf die endlichkeit der menschlichen existenz zurückgeführt hätten. :schland:
-
DrGreenthumb schrieb:
sollten sie dann aber vor 20 jahren genauso wenig
Sicher, nur war es damals aufwendiger. Immerhin gab es noch keine STL. Und die C Programmierer haben auch dazugelernt.
audacia schrieb:
Wieso ist das Käse? Bei mir landet der IP meistens auf dem Stack...
Nein, das tut er mit Sicherheit nicht. Wie kommst du auf sowas?
Der IP gibt die aktuelle Position im Code Segement (cs) an, also die Stelle, an der die CPU den nächsten Maschinenbefehl abholt, um diesen zu verarbeiten. Der Stack, oder besser das Stack Segment (ss), ist eine ganz andere Baustelle.
-
Der IP wird vor jedem Funktionsaufruf auf den Stack gepusht und wenn die Funktion durch ist und alle (lokalen) Variablen wieder von Stack sind wird auch der IP vom Stack gepopt damit man die Adresse wieder hat wo man vor dem Aufruf war und wieder zurück springen kann. Es wird natürlich nicht der IP auf den Stack gepusht (der ist ja festgelötet), sondern der Wert, welcher ja beim Funktionsaufruf überschrieben wird.