| (In)security allgemein Sicherheit, Anonymität im Netz. Schutz und Maßnahmen. Prävention und Konzepte. Sicherheitsarchitekturen allgemein und auf der Netzwerkebene. |
Diskussion: Buffer-Overflows deterministisch finden im Forum (In)security allgemein, in der Kategorie Security Area; Anzeige 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 ...
![]() |
| | #1 (permalink) |
| Registriert seit: 31.07.06 ![]() Likes: 32 | Anzeige 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 |
| | |
| | #2 (permalink) |
| Guest Likes: | Du hast die Moeglichkeiten schon genannt, um Buffer Overflows in closed-source Programmen zu finden. Assemblercode durchwuehlen, und dabei musst du erstmal nur die eingaben beruecksichtigen ob sie soetwas zulassen und dann kannst du rangehen und nachschauen wo du in dem Programm hinspringen moechtest, was auch wieder schwer wird da die Programme meistens so gebaut sind das sich immer in einem Bestimmten Bereich verschieben. Das blinde senden von Strings ist pure Zeitverschwendung, denn es muessen 2 Sachen auftreten damit ein Buffer-overflow erfolgreich ist. 1. Du musst auf ,einer CISC-Maschiene, die Returnadresse ueberschreiben koennen. 2. Du musst sie so ueberschreiben das kein Seg-default auftritt, also das das Programm dann nicht versucht auf irgendeinen Speicherbereich ausser dem seinen zuzugreifen. So ein Verhalten wird meistens vom OS erkannt, zumindest wenn Stack-Protection aktiviert ist. Mfg sw33t |
|
| HaBOT | - Anzeige - |
| |
| | #3 (permalink) |
| Registriert seit: 14.04.06 ![]() Likes: 4 | Naja, willkürlich Strings an Programme zu schicken ist eine bekannte und übliche Vorgehensweise. Sogenannte Fuzzer werden genau zu diesem Zweck entwickelt. Es ist klar, dass die Chance, irgendeine sinnvolle Return-Adresse zu finden, relativ klein ist. Wenn es allerdings Speicherzugriffsfehler gibt, kann man eigentlich schon davon ausgehen, dass der Buffer übergelaufen ist. Den Exploit zu schreiben ist dann wieder Handarbeit, aber wenigstens weiß man, wo man ansetzen kann. Auch klar ist, dass man mit dieser Methode zwar Sicherheits-Lücken finden kann, aber nicht nachweisen, dass es keine gibt. |
| | |
![]() |
| - Anzeige - | |
| |
| Themen-Optionen | |
| Ansicht | |
| |
Ähnliche Themen | ||||
| Thema | Autor | Forum | Antworten | Letzter Beitrag |
| Buffer Overflows | .Gast | (In)security allgemein | 4 | 14.05.08 22:23 |
| Statistik Buffer Overflows | Dawen | (In)security allgemein | 1 | 31.12.07 17:37 |
| xmms buffer | odigo | Linux/UNIX | 4 | 04.08.06 14:19 |
| Ich kann alle im Netzwerk finden, mich kann man auch finden aber nicht zugreifen | Strahl | Network · LAN, WAN, Firewalls | 11 | 21.07.05 16:52 |