Oh nein, LaTeX enthält Fehler, darum gibt es ja jährlich eine neue Revision. Nur TeX selbst wird mittlerweile als so ziemlich fehlerfrei bezeichnet, sicher ist sich aber niemand. Es gibt aber Ansätze, mit mathematischen Beweisverfahren Programme in sicherheitskritischen Umgebungen zu erstellen bzw. zu prüfen, die dann tatsächlich sicher und fehlerfrei sind. Das funktioniert wegen der enormen Komplexität der zu lösenden Gleichungen aber nur bei verhältnismäßig einfachen Aufgabenstellungen. Solaris und einige Bereiche von Linux (Netfilter und Pam) benutzen das, aber auch nur, um einzelne Fälle explizit durchzurechnen. Für eine vollständige Betrachtung wird erst die Ära der Quantencomputer genug Power liefern. Im Übrigen ist das auch der Grund, warum Software- und Ideenpatente Unfug sind, denn jeder Algorithmus lässt sich prinzipiell auch ganz allgemein herleiten, von einer "Erfindung" kann dann keine Rede mehr sein, denn es fehlt die schöpferische Höhe. Sollte die EU weiterhin das Recht beugen, kann man so, auch wenn es mühsam ist, alle Patenten auf Algorithmen und Verfahren eliminieren.
"Besonders gefallen haben mir die Kapitel 4 und 8. Jeder Leser wird danach die Sicherheit von PHP mit anderen Augen sehen."
Die die PHP programmieren, sind selten Die die auch für die Sicherheit verantwortlich sind. Meist Leute die mal mit ein bisschen HTML angefangen haben, um sich eine Homepage al a "Ich, meine Familie und meine Freunde..." zu basteln. Da dann selbige nicht die Server-Administration machen, kümmert sie das auch nicht.
"Einziger Wermutstropfen sind die zahlreichen Codebeispiele, die leider meistens nur für Windows NT oder XP nutzbar sind. Hier hätte ich gerne noch mehr Unix-spezifische Anwendungen gesehen. "
Ich prangere an: ewig werden wir zurückgestellt! die Viren die wir geschickt bekommen laufen nicht bei uns. Jetzt pochen wir schon auf freie Software und Die die wir bekommen, hat noch nicht mal Backdoors oder Schnüffel-Funktionen. Da nützt es uns auch nichts, das wir uns den Code ansehen können wenn da nichts interessantes drinnen ist. Und dann immer diese übereifrigen Programmierer. Da hat der 2.6er Kernel nun endlich mal ein richtigen Fehler und gerade mal zwei Tage hält die Freude an und er ist schon wieder beseitigt. Da nutzt es auch nichts, das M$ vorrechnet das die DURCHSCHNITTLICHE Fehlerbeseitigung bei Linux Wochen dauern soll.
"Eines der bekanntesten Probleme hinsichtlich Softwaresicherheit ist der Buffer Overflow. Und obwohl die Problematik nicht neu ist, gibt es doch in regelmäßigen Abständen neue Bugs, die sich auf einen Overflow zurückführen lassen. Das ist auch der Grund, warum sich in diesem Buch gleich das ganze Kapitel 7 damit befasst."
Das bezieht sich wahrscheinlich auf C. In C++, Python, Java, Perl, Ruby und Anderen dürfte das nicht mehr das grosse Thema sein.
Bei der Harvard Architektur liegen Daten und Code nicht in strikt getrennten Speicherbereichen. Da man mit einem Bufferoverflow den auszuführenden Code immer nur dorthin bekommt wo eigentlich Daten gespeichert werden sollten, liegte er bei dieser Architektur in einem Bereich den man gar nicht als Code ausführen lassen kann.
Sorry Fehler: Bei Harvard ist es gerade eben strikt getrennt. (habe ein nicht zuviel geschrieben, weil ich den Satz anfangs noch anders formuliert hatte)
Das schuetzt dann aber nur davor, dass der Angreifer seinen eigenen Code ausfuehren kann. Er kann aber weiterhin beliebigen Code des Programms anspringen.
hat jemand "Exploiting Software" und "The Shellcoder's Handbook" (http://www.unixreview.com/documents/s=8989/ur0406c/) gelesen und kann die beiden vergleichen?
also Shellcoder's Handbook ist extrem geil, viel besser als Exploiting Software. Hier wissen die Autoren wenigstens, worum es geht und stellen ihr Wissen auch sehr gut dar.
Exploiting Software ist tiefgründiger und ausgereifter als The Shellcoder's Handbook. Bei TSH kommt mir das ganze eher wie eine Anleitung für Script-Kiddies vor, auch wenn diese nur wenig Freude daran haben werden, denn... Viele C Programme in diesen Buch haben Fehler und lassen sich ohne Aenderungen und C-Wissen nicht anwenden. Hinzu kommt noch, dass viele Texte des Buches schlicht aus dem Netzt genommen wurden. Unter anderem findet sich im TSH die komplette Anleitung von Mixter "Writing buffer overflow exploits - a tutorial for beginners" zu finden unter http://julianor.tripod.com/exploit_tutorial.txt. Die Quelle wird natuerlich nicht angegeben :(
Mein Fazit zu "The Shellcoder's Handbook: Discovering and Exploiting Security Holes": Wer sich ernsthaft mit Löchern und Exploits auseinander setzten will, dann ist es mit TSH schlecht beraten. Wenn man allerdings ein paar Leute beeindrucken will und das Wissen eher eine untergeordnete Rolle spielt, dann entweder die vielen HowTos aus dem Netzt (Mixter als Beispiel) oder das Buch besorgen. Um einen Einblick in die Welt der Sicherheitslücken zu bekommen, ist dieses Buch brauchbar.
momentmal war LaTeX nicht per Definition fehlerfrei
Es gibt aber Ansätze, mit mathematischen Beweisverfahren Programme in sicherheitskritischen Umgebungen zu erstellen bzw. zu prüfen, die dann tatsächlich sicher und fehlerfrei sind. Das funktioniert wegen der enormen Komplexität der zu lösenden Gleichungen aber nur bei verhältnismäßig einfachen Aufgabenstellungen. Solaris und einige Bereiche von Linux (Netfilter und Pam) benutzen das, aber auch nur, um einzelne Fälle explizit durchzurechnen. Für eine vollständige Betrachtung wird erst die Ära der Quantencomputer genug Power liefern.
Im Übrigen ist das auch der Grund, warum Software- und Ideenpatente Unfug sind, denn jeder Algorithmus lässt sich prinzipiell auch ganz allgemein herleiten, von einer "Erfindung" kann dann keine Rede mehr sein, denn es fehlt die schöpferische Höhe. Sollte die EU weiterhin das Recht beugen, kann man so, auch wenn es mühsam ist, alle Patenten auf Algorithmen und Verfahren eliminieren.
Die die PHP programmieren, sind selten Die die auch für die
Sicherheit verantwortlich sind. Meist Leute die mal mit ein
bisschen HTML angefangen haben, um sich eine Homepage al a
"Ich, meine Familie und meine Freunde..." zu basteln. Da
dann selbige nicht die Server-Administration machen, kümmert
sie das auch nicht.
"Einziger Wermutstropfen sind die zahlreichen Codebeispiele, die leider meistens nur für Windows NT oder XP nutzbar sind. Hier hätte ich gerne noch mehr Unix-spezifische Anwendungen gesehen. "
Ich prangere an: ewig werden wir zurückgestellt! die Viren
die wir geschickt bekommen laufen nicht bei uns. Jetzt pochen
wir schon auf freie Software und Die die wir bekommen, hat
noch nicht mal Backdoors oder Schnüffel-Funktionen. Da nützt
es uns auch nichts, das wir uns den Code ansehen können wenn
da nichts interessantes drinnen ist. Und dann immer diese übereifrigen
Programmierer. Da hat der 2.6er Kernel nun endlich mal ein
richtigen Fehler und gerade mal zwei Tage hält die Freude an
und er ist schon wieder beseitigt. Da nutzt es auch nichts,
das M$ vorrechnet das die DURCHSCHNITTLICHE Fehlerbeseitigung
bei Linux Wochen dauern soll.
"Eines der bekanntesten Probleme hinsichtlich Softwaresicherheit ist der Buffer Overflow. Und obwohl die Problematik nicht neu ist, gibt es doch in regelmäßigen Abständen neue Bugs, die sich auf einen Overflow zurückführen lassen. Das ist auch der Grund, warum sich in diesem Buch gleich das ganze Kapitel 7 damit befasst."
Das bezieht sich wahrscheinlich auf C. In C++, Python, Java, Perl,
Ruby und Anderen dürfte das nicht mehr das grosse Thema sein.
Ruby und Anderen dürfte das nicht mehr das grosse Thema sein.
Und auf nicht-Von-Neumann-Architekturen ebenfalls nicht.
Da man mit einem Bufferoverflow den auszuführenden Code immer nur dorthin bekommt wo eigentlich Daten gespeichert werden sollten, liegte er bei dieser Architektur in einem Bereich den man gar nicht als Code ausführen lassen kann.
Bei Harvard ist es gerade eben strikt getrennt. (habe ein nicht zuviel geschrieben, weil ich den Satz anfangs noch anders formuliert hatte)
Dann müsste Code und Daten in verschiedenen Speichern stehen.
Kommt die Harvard-Architektur nicht eher z.B. in einem CD-Rom vor?
oder gibts da seit gestern eine garbagecollector? ;)
schreib übrigens selbst c++
hat jemand "Exploiting Software" und "The Shellcoder's Handbook" (http://www.unixreview.com/documents/s=8989/ur0406c/) gelesen und kann die beiden vergleichen?
Gruß,
Andreas
also Shellcoder's Handbook ist extrem geil, viel besser als Exploiting Software. Hier wissen die Autoren wenigstens, worum es geht und stellen ihr Wissen auch sehr gut dar.
Gruß,
Werner
Bei TSH kommt mir das ganze eher wie eine Anleitung für Script-Kiddies vor, auch wenn diese nur wenig Freude daran haben werden, denn... Viele C Programme in diesen Buch haben Fehler und lassen sich ohne Aenderungen und C-Wissen nicht anwenden. Hinzu kommt noch, dass viele Texte des Buches schlicht aus dem Netzt genommen wurden. Unter anderem findet sich im TSH die komplette Anleitung von Mixter "Writing buffer overflow exploits - a tutorial for beginners" zu finden unter http://julianor.tripod.com/exploit_tutorial.txt. Die Quelle wird natuerlich nicht angegeben :(
Mein Fazit zu "The Shellcoder's Handbook: Discovering and Exploiting Security Holes":
Wer sich ernsthaft mit Löchern und Exploits auseinander setzten will, dann ist es mit TSH schlecht beraten. Wenn man allerdings ein paar Leute beeindrucken will und das Wissen eher eine untergeordnete Rolle spielt, dann entweder die vielen HowTos aus dem Netzt (Mixter als Beispiel) oder das Buch besorgen. Um einen Einblick in die Welt der Sicherheitslücken zu bekommen, ist dieses Buch brauchbar.