dev/random schrieb:
Normalerweise liegen Daten und Code in unterschiedlichen Speicherbereichen, aber durchaus dicht bei einander. Bei einem Pufferüberlauf sind die Daten (z.B. eine Grafik die geladen wird) zu groß für den dafür vorgesehenen Speicherbereich und überschreiben den "dahinter" liegenden Speicher.
Code wird heute in der Regel nicht mehr überschrieben, der ist normalerweise auch gegen Überschreiben geschützt. Ebenso sind Datenbereiche dagegen geschützt als Code ausgeführt zu werden. Das Problem ist in der Regel der Stack, da liegen die lokalen Variablen zusammen mit den Return Adressen, außerdem oft auch noch Funktionspointer. Die lassen sich leicht mit Pufferüberläufen überschreiben. Man injiziert also nicht direkt Code, sondern ändert den Kontrollfluss des Programmes so, das der existierende Programmcode etwas anderes tut, als er normalerweise tun würde. Da alle Shared Libraries eines Prozesses im Adressraum verfügbar sind, ist man nicht auf den Code der Library mit der Verwundbarkeit beschränkt.
MarS81 schrieb:
Wenn ich richtig informiert bin, sind Bibliotheken in unixoiden Betriebssystemen in der Regel als shared library eingebunden. Das heißt, einmal diese shared library patchen und alle Programme die darauf zugreifen sind abgesichert.
Das ist oft so, aber es gibt auch viele Programme, die Bibliotheken statisch einbinden. Das gilt besonders für Software die nicht im Repo der Distribution ausgeliefert wird, sondern z.B. als deb/rpm „Datei“ verteilt wird. Also z.B. Chrome oder auch “kommerzielle“ Linux Software.
Dann gibt es ja zunehmend Package Manager wird Snap die eben „Self Contained“ Binaries mit allen Libraries enthalten. Und dann eben Docker Images, usw.
DarkSoul schrieb:
Wäre interessant zu wissen, ob besser abgesicherte Funktionen benutzt wurden oder ob da eben "vergessen" wurde, dass man diese benutzen kann oder ob sie gar absichtlich weggelassen wurden, da sie eben auch ein Stück langsamer sind als die "ungeschützten" Funktionen.
Es gibt halt ein bisschen mehr auf der Welt als Strings und die Standard C Library bietet jenseits von Strings nicht viel an. Bei den genannten Libraries geht es ja um Basisbibliotheken die z.B. das WebP Datenformat überhaupt erst implementieren. Und die müssen dabei „Low-Level“ Operationen auf dynamischen Speicherstrukturen implementieren. Dabei kann auch ein geübter Entwickler schlicht Fehler machen und auch die Test-Coverage kann Lücken enthalten, die diese Fehler nicht entdecken.
###Zaunpfahl### schrieb:
Das sowas noch immer in C geschrieben wird liegt denk ich am Stolz einiger Entwicker
Naja, die Code Basis in C ist halt so extrem riesig, das alles in Rust neu zu schreiben würde Jahrzehnte dauern.
Softwareentwicklung funktioniert ja in der Regel so, das vielleicht 10-20% des Codes Eigenentwicklung sind, der Rest ist eingebundener Third-Party Code. Das ist auch gut so, denn wenn z.B. Jeder wieder seine eigene SSL Library bauen würde, wäre die Qualität mit Sicherheit schlechter.
Außerdem sorgt die Verwendung von Rust nicht automatisch für sicheren Code. Gerade wenn man Low-Level Blbiotheken implementiert, die z.B. direkt mit dem Speicherlayout von Datenstrukturen hantieren, kann man die gleichen Fehler wie in C machen.
Hier ist ein ganz guter Artikel dazu, warum man für „Real-World“ Anwendungen Unsafe Rust braucht und wie man damit umgeht.
https://rustmagazine.org/issue-3/understand-unsafe-rust/
Der Artikel bringt es ganz gut auf den Punkt:
Die „Welt“ ist unsicher, und unsafe Rust Code wird benutzt die Brücke zur unsicheren Welt zu bauen.
Und beim Bau dieser Brücken kann man Fehler machen.
Auch Low-Level-Code wird nicht komplett neu geschrieben, da greift man genauso auf Bibliotheken/Sniplets/etc zurück, die dann fest eingebunden werden um es einfach auszudrücken. Eigentlich sollten solche Fehler bei Prüfungen mittlerweile auffallen, dachte ich.