Frage an die Programmierer
-
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.
-
JetztPassMalAuf schrieb:
Der IP wird vor jedem Funktionsaufruf auf den Stack gepusht
Das ist aber nicht der IP, sondern die Rücksprungadresse. Das ist beim Call nunmal zufällig der selbe Wert. Aber schon wenn man in der Funktion selbst ist, dann sind der IP und der Wert auf dem Stack zwei vollkommen andere Werte.
Vielleicht habe ich *Ranner* auch nur falsch verstanden. Wenn er die Rücksprungadresse meinte, dann hat er Recht. Das ist aber nicht der IP. Dieser Wert wird erst zum IP, wenn der ret Befehl abgearbeitet wird.