Hallo,
hoffentlich kriegst du dann danach keine Crashes.
http://www.pc-magazin.de/common/nws/einemeldung.php?id=56051
gruesse
Klatsch, Fakten, News, Betas 5.087 Themen, 27.849 Beiträge
xafford 
Olaf19 „[x] bookmarked... sehr lesenswert!“
Wenn man die potenziellen Angreifer bestehenden Hürden so sieht, ist es schon erstaunlich, dass immer noch so viele Rechner angegriffen werden.
Das mit den Hürden ist relativ. Für mich wären sie unüberwindbar, aber ich kenne mehr als nur eine Person, die dies grundsätzlich mit etwas Zeitaufwand hinbekommen würde.
Insbesondere das direkte Anspringen der Schad-Routine, ohne zu wissen, wo genau diese im Speicher landen wird, stelle ich mir nicht einfach vor.
Ist es auch nicht, aber aus Verständnisgründen (auch was mein eigenes Verständnis angeht) habe ich einiges weggelassen was an programmiertechnischen Kniffen existiert, um dafür zu sorgen den eigenen Code zur Anwendung zu bringen.
Was die Programmiersprache C angeht, habe ich nach deiner Schilderung das Gefühl, dass weniger die Sprache als solche die Schuld hat, sondern mehr die C-Programmierer.
Die Sprache hat insofern Schuld, dass sie es einem Programmierer immens vereinfacht direkt im Speicher herum zu pfuschen, Sprachen ohne Zeigerarithmetik oder Sprachen mit Laufzeitumgebung machen es dem Programmierer eigentlich unmöglich, hier besteht nur der Angriffsvektor der Implementierung.
Nebenbei ist aber auch oftmals der Umgang mit Bibliotheken und Compilern schuld. Es gibt Bibliotheken für C/++, die BOs prinzipiell vermeiden, wer sie jedoch nicht nutzt ist selbst schuld. Zudem neigen viele Programmierer dazu Compiler-Warnungen schlicht zu ignorieren, obwohl diese oftmals auf mögliche Probleme in dieser Richtung hinweisen können.
Denn per If-Abfrage wäre es ja möglich zu überprüfen, ob der vom Benutzer eingegebene String länger ist als der dafür reservierte Speicherbereich
Das geht mit einer IF-Abfrage so nicht, da Eingaben idR Streams darstellen, um diese mit einer IF-Abfrage auf Länge prüfen zu können müsstest Du sie schon in einen Speicherbereich kopiert haben, womit es jedoch geht ist zum einen eine WHILE-Schleife mit einem Längenzähler, oder man nutzt eben passende Bibliotheksfunktionen, bei denen man die zu kopierende Länge entsprechend angibt.
Was ich immer wieder verblüffend finde ist, dass sich Menschen mit großem programmiertechnischen Knowhow dazu bereit finden, solchen Schund auf die Menschheit loszulassen - anstatt ihre fachliche Kompetenz konstruktiv einzusetzen... Anwendungsentwickler sind inzwischen doch wieder gefragt?
Naja, es gibt einen relativ alten und in diesem Bereich sehr richtungsweisenden Artikel auf Phrack namens "Smashing the stack for fun and profit", ich würde den Titel jedoch erweitern zu "Smashing the stack for fun, honour and profit". Mittlerweile ist einfach unheimlich viel Geld zu machen mit "schlüsselfertigen" Exploits.
P.S. falls wir uns nicht mehr lesen, wünsche ich schon frohe Feiertage.
Same to you!
Das mit den Hürden ist relativ. Für mich wären sie unüberwindbar, aber ich kenne mehr als nur eine Person, die dies grundsätzlich mit etwas Zeitaufwand hinbekommen würde.
Insbesondere das direkte Anspringen der Schad-Routine, ohne zu wissen, wo genau diese im Speicher landen wird, stelle ich mir nicht einfach vor.
Ist es auch nicht, aber aus Verständnisgründen (auch was mein eigenes Verständnis angeht) habe ich einiges weggelassen was an programmiertechnischen Kniffen existiert, um dafür zu sorgen den eigenen Code zur Anwendung zu bringen.
Was die Programmiersprache C angeht, habe ich nach deiner Schilderung das Gefühl, dass weniger die Sprache als solche die Schuld hat, sondern mehr die C-Programmierer.
Die Sprache hat insofern Schuld, dass sie es einem Programmierer immens vereinfacht direkt im Speicher herum zu pfuschen, Sprachen ohne Zeigerarithmetik oder Sprachen mit Laufzeitumgebung machen es dem Programmierer eigentlich unmöglich, hier besteht nur der Angriffsvektor der Implementierung.
Nebenbei ist aber auch oftmals der Umgang mit Bibliotheken und Compilern schuld. Es gibt Bibliotheken für C/++, die BOs prinzipiell vermeiden, wer sie jedoch nicht nutzt ist selbst schuld. Zudem neigen viele Programmierer dazu Compiler-Warnungen schlicht zu ignorieren, obwohl diese oftmals auf mögliche Probleme in dieser Richtung hinweisen können.
Denn per If-Abfrage wäre es ja möglich zu überprüfen, ob der vom Benutzer eingegebene String länger ist als der dafür reservierte Speicherbereich
Das geht mit einer IF-Abfrage so nicht, da Eingaben idR Streams darstellen, um diese mit einer IF-Abfrage auf Länge prüfen zu können müsstest Du sie schon in einen Speicherbereich kopiert haben, womit es jedoch geht ist zum einen eine WHILE-Schleife mit einem Längenzähler, oder man nutzt eben passende Bibliotheksfunktionen, bei denen man die zu kopierende Länge entsprechend angibt.
Was ich immer wieder verblüffend finde ist, dass sich Menschen mit großem programmiertechnischen Knowhow dazu bereit finden, solchen Schund auf die Menschheit loszulassen - anstatt ihre fachliche Kompetenz konstruktiv einzusetzen... Anwendungsentwickler sind inzwischen doch wieder gefragt?
Naja, es gibt einen relativ alten und in diesem Bereich sehr richtungsweisenden Artikel auf Phrack namens "Smashing the stack for fun and profit", ich würde den Titel jedoch erweitern zu "Smashing the stack for fun, honour and profit". Mittlerweile ist einfach unheimlich viel Geld zu machen mit "schlüsselfertigen" Exploits.
P.S. falls wir uns nicht mehr lesen, wünsche ich schon frohe Feiertage.
Same to you!
