Wie kann ein Grafikformat zu einer Sicherheitslücke führen?

[Gast]

Kann mir jemand das mal erklären, warum reine Daten zu einer Komprimitierung des Systems führen können?

http://www.heise.de/newsticker/meldung/89096

[HajottV]

Kann mir jemand das mal erklären, warum reine Daten zu einer Komprimitierung des Systems führen können?

http://www.heise.de/newsticker/meldung/89096

Das hängt damit zusammen, daß die Daten ja verarbeitet werden müssen und der Programmcode, der das macht, fehlerhaft ist.

Ein ganz beliebter Fehler ist es zum Beispiel bei Strings von einer Maximallänge auszugehen. In den meisten Bildformaten (z.B. JPG) gibt es die Möglichkeit, Metadaten in Form von Text einzufügen. Geht das Programm beispielsweise davon aus, daß die Länge dieses Textes maximal 64k groß ist, der Text ist aber 64k + 100 Bytes groß, dann ist es gut möglich, daß das Programm unkontrolliert in den Speicher schreibt. Für einen Hacker interessant wird es, wenn dafür der Stack genommen wird. Dann kann man nämlich die Rücksprungadresse manipulieren.

Wenn Du mehr dazu wissen möchtest, gibt's hier (http://de.wikipedia.org/wiki/Puffer%C3%BCberlauf#Prozessoren_und_Programmierstil) mehr zu dem Thema.

Gruß

Jörg

[ollix]

Die Funktionen des Grafikprogramms lesen eine Bilddatei ein und überwachen da an irgendeiner Stelle wohl eine Puffergrenze nicht. Das heißt es wird durch eine spezielle Datei mehr Inhalt in einen Speicherbereich geschrieben als dafür vorgesehen war - d.h. was sonst hinter diesem Bereich im Speicher liegt wird überschrieben. Da bei der verwendeten PC Architektur Daten und Programmcode im gleichen Speicher liegen, kann man so z.B. versuchen die Rücksprungadresse der Funktion nach dem kritischen Einlesevorgang zu verändern, daß das Grafikprogramm nach dem Einlesen den durch die Grafikdatei eingeschleusten Code ausführt.

[HellHorse]

Kann mir jemand das mal erklären, warum reine Daten zu einer Komprimitierung des Systems führen können?

http://www.heise.de/newsticker/meldung/89096
Weil C/C++ drecks Sprachen sind, bei denen selbst Profis nicht die Grundlagen hinkriegen.

[Coda]

Hast heut aufm Flameheftchen geschlafen HellHorse? ;)

[Ganon]

Nunja. Je nachdem wem man die Schuld zuweisen will. Der Sprache, oder dem Programmierer. ;)

btw. Wie hilfreich bzw. wie Problembehaftet sind GCC-Optionen wie -fstack-protector-all / -fstack-protector?

[Crushinator]

Weil C/C++ drecks Sprachen sind, bei denen selbst Profis nicht die Grundlagen hinkriegen.
Im übertragenen Sinne hast Du zwar recht, aber andererseits mag ich's dreckig. :udevil:

[HellHorse]

Hast heut aufm Flameheftchen geschlafen HellHorse? ;)
Wenn ich flamen wollte dann würde ich das posten:
http://forums.gentoo.org/viewtopic-t-556647.html?sid=b8eeafc21ea3660c892fbcda57c52479
http://www.heise.de/newsticker/meldung/89121
http://www.heise.de/newsticker/meldung/89110
und behapten, dass das die Regel und nicht die Ausnahame ist.
(ist auch schön fair, da für Windows, Linux, und OS X alle was dabei ist)

[Ganon]

und behapten, dass das die Regel und nicht die Ausnahame ist.

Hehe ^^ Eindeutig zweideutig :D

Ne ne, hast ja Recht.

[Coda]

Wenn ich flamen wollte dann würde ich das posten:
Pufferüberläufe kann man aber auch mit einem gescheiten C++-Compiler abfangen. Dann schmiert die App zwar ab, aber was solls. Ein ungefangene Exception ist auch nicht besser.

[rotalever]

Viel interessanter wäre es doch, so zu programmieren, dass es gar nicht erst dazu kommt...

[Monger]

Viel interessanter wäre es doch, so zu programmieren, dass es gar nicht erst dazu kommt...

Die Weisheit des Tages:

Menschen machen Fehler. Auch Programmierer.

Eine Sprache die nicht gleich die Welt untergehen lässt wenn der Entwickler mal nicht so gut drauf war, hat durchaus was für sich.

[Trap]

Menschen machen Fehler. Auch Programmierer.
Sich für C/C++ zu entscheiden ist oft der erste ;)

[micki]

wenn man mit werkzeugen nicht umgehen kann, soll man es halt lassen und weiter froehlich mit dem plastikmesser arbeiten.

[Gast]

Eine Sprache die nicht gleich die Welt untergehen lässt wenn der Entwickler mal nicht so gut drauf war, hat durchaus was für sich.
Erzähl das mal Stuerungssoftwarenutzern für Fahr-/Flugzeuge oder den Softwareingeneuren der Arian 5.
http://de.wikipedia.org/wiki/Ariane_5#Fehlgeschlagener_Erstflug

[Nasenbaer]

Sich für C/C++ zu entscheiden ist oft der erste ;)
Ich behaupte einfach mal, dass du, wenn du sowas sagst, mehr C als C++ schreiben kannst. Mit reinem C++ und nutzung von STL usw. sind solcherart fehler wie man sie mit reinem C machen kann, wesentlich geringer.

Wer C++ schreibt und malloc nutzt, der hat wohl irgendwas falsch gemacht. :)

[Coda]

Gibt's inzw. eigentlich ne STL die man so kompilieren kann dass operator[] auf at() verweißt? Das fände ich nicht so blöde, vor allem zu Debugzwecken.

Und ich stimme jedem zu, der sagt dass jeder Mensch mal Fehler macht. Vor allem sind die Fehler schlecht die man übersieht - das ist doch das Kernproblem der Sache.

[SGT.Hawk]

Wenn man aber eine eigene Speicherverwaltung schreibt schon.
@PS:Gibt es denn kein Programm, was den Code analysiert und potentielle Memory-Leaks oder gefahrenvolle Funktionen,anmahnt?

[Ganon]

Gibt's inzw. eigentlich ne STL die man so kompilieren kann dass operator[] auf at() verweißt? Das fände ich nicht so blöde, vor allem zu Debugzwecken.

Tut er das bei den Standard-Containern nicht? Ich dachte ich hätte mal so etwas gelesen.

[Gast]

Ein ganz beliebter Fehler ist es zum Beispiel...Ein beliebter Fehler ist wie ein weisser Neger...

[Monger]

@PS:Gibt es denn kein Programm, was den Code analysiert und potentielle Memory-Leaks oder gefahrenvolle Funktionen,anmahnt?

Nicht alles lässt sich zur Compilezeit bereits überprüfen.

Wir hatten die Diskussion hier vor einiger Zeit schonmal, und mittlerweile sehe ich es auch ein: wichtig ist, was zur Laufzeit mit dem Code passiert. Man beraubt sich viel Flexibilität, wenn man schon im Vorneherein versucht, statisch alle Probleme zu erschlagen. Man muss ein Stück weit sich darauf einlassen, dass auch zur Laufzeit immer noch was schief gehen kann.

[micki]

Und ich stimme jedem zu, der sagt dass jeder Mensch mal Fehler macht. leider schiebt es der mensch zu gern auf was anderes wenn er den fehler begeht.

@ganon, nein tut er nicht.

[rotalever]

@PS:Gibt es denn kein Programm, was den Code analysiert und potentielle Memory-Leaks oder gefahrenvolle Funktionen,anmahnt?
valgrind macht das zur Laufzeit.

[HellHorse]

@PS:Gibt es denn kein Programm, was den Code analysiert und potentielle Memory-Leaks oder gefahrenvolle Funktionen,anmahnt?
Sicher, gibt zahlreiche Firmen, die davon leben solche statischen Analysetools zu verkaufen.
Auch Microsoft hat so Sachen: http://blogs.msdn.com/sdl/archive/2007/04/26/lessons-learned-from-the-animated-cursor-security-bug.aspx

[Kabelsalat]

Ich behaupte einfach mal, dass du, wenn du sowas sagst, mehr C als C++ schreiben kannst. Mit reinem C++ und nutzung von STL usw. sind solcherart fehler wie man sie mit reinem C machen kann, wesentlich geringer.

Wer C++ schreibt und malloc nutzt, der hat wohl irgendwas falsch gemacht. :)

Es ist immer besser Fehler erst garnicht begehen zu können. In C++ kann ich den ganzen Altkrempel noch ohne Einschränkungen nutzen und prinzipbedingt (Pointer etc.) gibt es mehr Schwachstellen. Der Programmierer muss gezwungen werden manches nicht zu verwenden. Der gute Programmier sollte diesen Zwang sogar für sich fordern, da nur so Fehlerquellen effektiv eliminiert werden können. Sollte es in seltenen Fällen aufgabenbedingt notwending sein gewisse Zwänge aufzuheben, so darf dies nur im Einzelfall geschehen und auch dann nur mit eindeutiger Kennzeichnung (etwa unsafe-Bereiche in .Net).

Gute Beispiele sind hierfür .Net und Java. Ich arbeite sehr viel mit ersterem und bin der Meinung dass selbst .Net noch nicht strikt genug ist: Etwa die Überprüfung auf arithmetischen Überlauf ist standardmäßig (global) deaktiviert - ein großer Fehler!

Wenn man aber eine eigene Speicherverwaltung schreibt schon.
@PS:Gibt es denn kein Programm, was den Code analysiert und potentielle Memory-Leaks oder gefahrenvolle Funktionen,anmahnt?

Wie schon von meinen Vorgängern angemerkt, kann man statisch nur sehr wenig ausrichten. Zur Laufzeit sind die Möglichkeiten wesentlich umfangreicher, weshalb ich Runtime-Umgebungen wie etwa .Net oder Java in den allermeisten Gebieten auch für zukunftsträchtiger halte, somal der Performance-Aspekt immer mehr in den Hintegrund tritt (gilt für die meisten Anwendungen) und moderne Runtime-Lösungen durch die zusätzlichen Optimierungsmöglichkeiten zur Laufzeit ebenfalls sehr performant sein können (theoretisch sogar performanter als nativer Code) und der Leistungsunterschied somit in der Praxis meistens vernachlässigbar klein ausfällt

wenn man mit werkzeugen nicht umgehen kann, soll man es halt lassen und weiter froehlich mit dem plastikmesser arbeiten.

Warum hat eine Kreissäge eine Schutzabdeckung? Warum gibt es "Lebendschalter" (o.ä.), die eine gefährliche Anlage bei Ohnmacht / Tod der bedienenden Person automatisch abschalteten / herunterfahren / in einen sicheren Zustand bringen? Wenn immer alles "normal" laufen würde und nie Fehler gemacht würden, wäre all dies überflüssig...

... das selbe gilt für die Programmierung: Sicherungsmechanismen zur Laufzeit (Überlaufsprüfung etc.) sind unbedingt notwendig. Auch Fehler die man erst garnicht begehen kann, können nicht auftreten. Deshalb müssen dem Programmierer Zwänge auferlegt werden.

[Ganon]

(theoretisch sogar performanter als nativer Code)


Vorsichtig mit solchen Aussagen :D Egal ob C, C++, Java oder C#. Im Endeffekt wird aus allen Maschinencode. ;) Besser wäre die Aussage unfähr so "theoretisch sogar performanter als das was normale Compiler im Normalfall produzieren"


:D

[Monger]

Deshalb müssen dem Programmierer Zwänge auferlegt werden.

Es geht nicht nur darum, den Entwickler vor grobem Dummfug zu bewahren. Gerade die Bereichslängenprüfung ist ja eine Maßnahme, über die die Runtime wacht - und davon profitiert JEDER Code der darauf läuft. Die Runtime kann zur Laufzeit die Ausführung von Code verweigern, wenn sie irgendwelche Unregelmäßigkeiten entdeckt. Das ist schon ein dramatischer Schritt vorwärts gegenüber "klassisch" kompilierter Software.

[Crushinator]

Weil C/C++ drecks Sprachen sind, bei denen selbst Profis nicht die Grundlagen hinkriegen.

http://www.heise.de/newsticker/meldung/89821

[...] Manipulierte JPEG-Bilder mit integrierten ICC-Farbprofilen können dem JDK möglicherweise Schadcode unterschieben.

Dazu fällt mir nur ein :udevil: ein.

[HellHorse]

http://www.heise.de/newsticker/meldung/89821
Ja, und der Fehler liegt selbstverständlich im C/C++ Code und nicht im Java Code.