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 „Danke - ich kann bis jetzt nicht klagen :-)“
... was ich immer schon wissen wollte, wieso führt eigentlich ein Buffer Overflow dazu, dass ein Angreifer auf dem silbernen Tablett Root-Rechte serviert bekommt? Warum schmiert das betroffene Programm nicht einfach ab, so wie bei Java? Ist C aus diesem Grund heute keine empfehlenswerte Programmiersprache mehr?
Das Problem hat erst einmal nur indirekt mit der verwendeten Programmiersprache zu tun, es hat etwas mit der grundlegenden Architektur des PC zu tun, die Daten- und Programmspeicher nur ungenügend trennt. Auf einer solchen Architektur ist es prinzipiell immer möglich einen Overflow auf dem Stack oder dem Heap zu erreichen.
Auch führt ein BO nicht automatisch zu Root-Rechten, er führt nur unter Umständen (aber nicht immer) dazu, dass ein Angreifer eigenen Code ausführen kann. Es kann aber auch einfach nur dazu reichen, ein Programm oder ein System schlicht abstürzen zu lassen.
Da C eine sehr hardwarenahe Programmiersprache ist gelingt es dort recht einfach direkt auf den Speicher zuzugreifen und diesen zu manipulieren. Zudem sind einige Funktionen in C nicht so abgesichert, dass sie Speichergrenzen prüfen und da C vorkompiliert ist gelingt es auch nicht die Speichergrenzen einer Variable zur Laufzeit zu überprüfen. Reserviert man also z.B. Speicher zur Speicherung einer Zeichenkette mit einer Länge von 10 Zeichen und kopiert in diese Benutzereingaben, ohne die Länger dieser Benutzereingaben zu prüfen, so wird ab den 9. Zeichen der Speicherbereich dieses Speichers überschritten (Zeichenketten in C sind Nullbasiert, d.h. ein 0x00 kennzeichnet das Ende der Zeichenkette). Kritisch wird es nun mit dem, was im Speicher überschrieben wird und womit es überschrieben wird.
Im Besten Fall passiert überhaupt nichts, es landet nur in einem im Programmverlauf nicht relevanten Speicherbereich Datenmüll. Ebenso kann es zu einem unvorhersehbaren Programmablauf führen, zu falschen Werten oder einem Programmabsturz. Zufällig und problemlos ist es nicht möglich eigenen Programmcode einzufügen und zur Ausführung zu bringen.
Grundproblem für einen Exploit sind nämlich mehrere Dinge:
Wichtig ist also, dafür zu sorgen, dass der Code vom Aufbau her von der Maschine ausgeführt werden kann, dass er angesprungen wird und was er tut und das Alles erfordert eigentlich weniger Kenntnisse in C oder C++, sondern Kenntnisse der zugrunde liegenden Maschinensprache.
Prinzipiell sind auch Sprachen mit Laufzeitumgebung wie Java, C#, Python oder Scriptsprachen wie PHP nicht vor BOs gefeit, denn liegt das problem in der darunter leigenden Laufzeitumgebung, so lässt sich dieses auch ausnutzen (schön zu sehen z.B. an den BOs in PHP). Allerdings hat es eine Laufzeitumgebung einfacher Speichergrenzen zu überprüfen, da sie sowohl während der Kompilierung des Quellcodes potentielle Schwachstellen erkennen kann, als auch während der Ausführung prüfen kann, was sie hier in welchen Speicherbereich mit welcher Größe kopiert. Tut sie dies an einer Stelle nicht, so kommt es genau wie in anderen Sprachen auch ebenso zu einem Buffer Overflow.
Das Problem hat erst einmal nur indirekt mit der verwendeten Programmiersprache zu tun, es hat etwas mit der grundlegenden Architektur des PC zu tun, die Daten- und Programmspeicher nur ungenügend trennt. Auf einer solchen Architektur ist es prinzipiell immer möglich einen Overflow auf dem Stack oder dem Heap zu erreichen.
Auch führt ein BO nicht automatisch zu Root-Rechten, er führt nur unter Umständen (aber nicht immer) dazu, dass ein Angreifer eigenen Code ausführen kann. Es kann aber auch einfach nur dazu reichen, ein Programm oder ein System schlicht abstürzen zu lassen.
Da C eine sehr hardwarenahe Programmiersprache ist gelingt es dort recht einfach direkt auf den Speicher zuzugreifen und diesen zu manipulieren. Zudem sind einige Funktionen in C nicht so abgesichert, dass sie Speichergrenzen prüfen und da C vorkompiliert ist gelingt es auch nicht die Speichergrenzen einer Variable zur Laufzeit zu überprüfen. Reserviert man also z.B. Speicher zur Speicherung einer Zeichenkette mit einer Länge von 10 Zeichen und kopiert in diese Benutzereingaben, ohne die Länger dieser Benutzereingaben zu prüfen, so wird ab den 9. Zeichen der Speicherbereich dieses Speichers überschritten (Zeichenketten in C sind Nullbasiert, d.h. ein 0x00 kennzeichnet das Ende der Zeichenkette). Kritisch wird es nun mit dem, was im Speicher überschrieben wird und womit es überschrieben wird.
Im Besten Fall passiert überhaupt nichts, es landet nur in einem im Programmverlauf nicht relevanten Speicherbereich Datenmüll. Ebenso kann es zu einem unvorhersehbaren Programmablauf führen, zu falschen Werten oder einem Programmabsturz. Zufällig und problemlos ist es nicht möglich eigenen Programmcode einzufügen und zur Ausführung zu bringen.
Grundproblem für einen Exploit sind nämlich mehrere Dinge:
-
- Der Angreifer weiß primär nicht, wo seine Daten im Speicher liegen werden
-
- Der Angreifer weiß nicht, ob dieser Speicherbereich angesprungen wird und der Code darin zur Ausführung kommt
-
- Er muss Shellcode einfügen, d.h. direkten Maschinencode, sein Code ist also plattformspezifisch
-
- Enthält sein Code 0x00, so muss er den Code so umwandeln, dass er keine 0x00 mehr enthält
-
- Läuft der Code unpreveligiert, so sind seine Möglichkeiten nur beschränkt
-
Wichtig ist also, dafür zu sorgen, dass der Code vom Aufbau her von der Maschine ausgeführt werden kann, dass er angesprungen wird und was er tut und das Alles erfordert eigentlich weniger Kenntnisse in C oder C++, sondern Kenntnisse der zugrunde liegenden Maschinensprache.
Prinzipiell sind auch Sprachen mit Laufzeitumgebung wie Java, C#, Python oder Scriptsprachen wie PHP nicht vor BOs gefeit, denn liegt das problem in der darunter leigenden Laufzeitumgebung, so lässt sich dieses auch ausnutzen (schön zu sehen z.B. an den BOs in PHP). Allerdings hat es eine Laufzeitumgebung einfacher Speichergrenzen zu überprüfen, da sie sowohl während der Kompilierung des Quellcodes potentielle Schwachstellen erkennen kann, als auch während der Ausführung prüfen kann, was sie hier in welchen Speicherbereich mit welcher Größe kopiert. Tut sie dies an einer Stelle nicht, so kommt es genau wie in anderen Sprachen auch ebenso zu einem Buffer Overflow.
