Hackse
0
Hi,
täglich erscheinen neue Security-Lücken in Software. Milw0rm ist voller Sicherheitslücken der unterschiedlichsten Art und diese Sicherheitslücken treten zugegebenermaßen teilweise sogar in Bibliotheken auf, bei denen ich nicht mal auf die Idee käme zu suchen.
Habe ich den Sourcecode, kann ich den BO entwickeln und er funktioniert.
In Opensource-Software ist es aufgrund des offenen Sourcecodes meist unproblematisch(er) Buffer-Overflow-Möglichkeiten zu finden (strcpy, allg. keine Stackprüfung et cetera ...), doch was ich suche ist eine deterministische Vorgehensweise um Bufferoverflows in Software zu finden, an deren Sourcecode ich nicht heran komme und quasi nur das Binary-File habe.
Kann mir nicht vorstellen, dass ein primitives Senden zufälliger Strings an einen Prozess alles sein kann um einen BO zu finden.
Programm disassemblieren, haufenweise Assembler-Code durchwühlen und hoffen, dass irgendwo die Stackprüfung vergessen wurde?
Wenn ich lese, dass in einem closed Programm in kurzer Zeit teilweise Bufferoverflowmöglichkeiten im zweistelligen Bereich gefunden wurden, dann muss es auch eine deterministische Art der Suche nach solchen Schwächen geben.
Was ist die klügste Lösung des deterministischen Vorgehens?
Greetz
HACKSE
täglich erscheinen neue Security-Lücken in Software. Milw0rm ist voller Sicherheitslücken der unterschiedlichsten Art und diese Sicherheitslücken treten zugegebenermaßen teilweise sogar in Bibliotheken auf, bei denen ich nicht mal auf die Idee käme zu suchen.
Habe ich den Sourcecode, kann ich den BO entwickeln und er funktioniert.
In Opensource-Software ist es aufgrund des offenen Sourcecodes meist unproblematisch(er) Buffer-Overflow-Möglichkeiten zu finden (strcpy, allg. keine Stackprüfung et cetera ...), doch was ich suche ist eine deterministische Vorgehensweise um Bufferoverflows in Software zu finden, an deren Sourcecode ich nicht heran komme und quasi nur das Binary-File habe.
Kann mir nicht vorstellen, dass ein primitives Senden zufälliger Strings an einen Prozess alles sein kann um einen BO zu finden.
Programm disassemblieren, haufenweise Assembler-Code durchwühlen und hoffen, dass irgendwo die Stackprüfung vergessen wurde?
Wenn ich lese, dass in einem closed Programm in kurzer Zeit teilweise Bufferoverflowmöglichkeiten im zweistelligen Bereich gefunden wurden, dann muss es auch eine deterministische Art der Suche nach solchen Schwächen geben.
Was ist die klügste Lösung des deterministischen Vorgehens?
Greetz
HACKSE