1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › Ersatz für C: Tor…

Anständiges Fuzzing-Framework fehlt

  1. Thema

Neues Thema Ansicht wechseln


  1. Anständiges Fuzzing-Framework fehlt

    Autor: Headcool 03.04.17 - 15:59

    Eine der Lösungen wie man native Sprachen sicher machen kann ist Fuzzing. Am besten wenn man parallel memcheck, dr. memory oder vergleichbares mitlaufen lässt.

    Das Problem liegt aber darin, dass momentan hauptsächlich Blackbox-Fuzzing betrieben wird. Eigentlich bräuchte es ein anständiges Fuzzing-Framework sodass man neben Regressionstests auch Fuzzingtests schreiben kann, welche dann auf einem Server rund um die Uhr laufen können.

  2. Re: Anständiges Fuzzing-Framework fehlt

    Autor: nille02 03.04.17 - 16:20

    Aber damit löst man das Problem nicht.

  3. Re: Anständiges Fuzzing-Framework fehlt

    Autor: chriskoli 03.04.17 - 16:36

    nille02 schrieb:
    --------------------------------------------------------------------------------
    > Aber damit löst man das Problem nicht.
    Damit alleine nicht. Das stimmt schon. Aber gerade bei einer Anwendung wie Tor wären solche Tests auf keinen Fall verkehrt.

  4. Re: Anständiges Fuzzing-Framework fehlt

    Autor: Pampersfox 03.04.17 - 16:53

    Der Lehrer würde jetzt sagen: Thema verfehlt, setzen, Sechs.

  5. Re: Anständiges Fuzzing-Framework fehlt

    Autor: Headcool 03.04.17 - 17:34

    chriskoli schrieb:
    --------------------------------------------------------------------------------
    > Damit alleine nicht. Das stimmt schon. Aber gerade bei einer Anwendung wie
    > Tor wären solche Tests auf keinen Fall verkehrt.

    Genauso ist es. Sicherheit erreicht man nur durch die Kombination von vielen verschiedenen Maßnahmen.
    Maßnahmen wie Regression Testing, Fuzzing, Control Flow Enforcement, ASLR, Bound Checking, Stack Security Cookies, DEP, feingranulares Rechtemanagement, Sandboxing, etc. sind nur in ihrer Kombination so wirksam wie möglich.
    All diese Maßnahmen verbessern den Schutz und verringern die Anzahl der Exploits und machen es für Angreifer schwerer und teurer. Manche zeroday exploits für populäre Programme sind jetzt schon 6+ stellige Beträge wert. So wie sich die Sicherheit in den letzten Jahren entwickelt hat und in den nächsten Jahren entwickeln wird, wird der Preis noch gewaltig steigen und genau das ist das Ziel. Schon jetzt werden solche Exploits gehütet wie ein Schatz wie am letzten Torbrowser Exploit zu sehen war.

  6. Re: Anständiges Fuzzing-Framework fehlt

    Autor: hab (Golem.de) 03.04.17 - 18:03

    Headcool schrieb:
    --------------------------------------------------------------------------------
    > Eine der Lösungen wie man native Sprachen sicher machen kann ist Fuzzing.
    > Am besten wenn man parallel memcheck, dr. memory oder vergleichbares
    > mitlaufen lässt.
    >
    > Das Problem liegt aber darin, dass momentan hauptsächlich Blackbox-Fuzzing
    > betrieben wird. Eigentlich bräuchte es ein anständiges Fuzzing-Framework
    > sodass man neben Regressionstests auch Fuzzingtests schreiben kann, welche
    > dann auf einem Server rund um die Uhr laufen können.

    Möchte hier mal kurz einhaken, weil diese Ansichten wirken auf mich etwas... veraltet. memcheck (aka valigrind) und dr. memory arbeiten rein auf binary-ebene und können daher viele klassen von sicherheitslücken nicht erkennen (beispielsweise overreads auf dem stack). Besser sind Tools wie Address Sanitizer oder Memory Sanitizer, die auf Compilerebene arbeiten.

    "Blackbox"-Fuzzing ist auch ein eher veralteter begriff. Was man üblicherweise heutzutage macht ist coverage-basiertes Fuzzing, was ebenfalls auf der Compiler-Ebene ansetzt. Das ist weder black- noch whitebox, sondern ein Feedback-Mechanismus, der auf Basis der Codepfade fuzzing betreibt (afl oder libfuzzer).

  7. Re: Anständiges Fuzzing-Framework fehlt

    Autor: Headcool 03.04.17 - 20:26

    Memory Sanitizer macht nur das was der Debugger eh schon machen sollte. Address Sanitizer unterstützt noch keine Memory Leaks. Der Vorteil der Tools ist halt, dass sie schneller sind, aber eine Alternative sind sie mMn nicht.
    Ich selbst verwende ja oft den Intel Inspector, welcher im Bereich Memory nicht so gut arbeitet (viele false positives) aber dafür auch Threading Errors wie Data Races inkludiert.

    Bezüglich coverage-based Fuzzing muss ich sagen, dass mir das nicht wirklich reicht. Ich will die Tests selbst schreiben, wenn möglichst auf kleinster Ebene.
    Also nicht das klassische System-Fuzzing bei der man eine ganze Binary fuzzt, sondern eher eine Art Unit-Fuzzing um die korrekte Ausführung einzelner Funktionen zu überprüfen.

  8. Re: Anständiges Fuzzing-Framework fehlt

    Autor: hab (Golem.de) 03.04.17 - 22:29

    Headcool schrieb:
    --------------------------------------------------------------------------------
    > Address Sanitizer unterstützt noch keine Memory Leaks.

    Das ist falsch. In clang geht das schon lange, in gcc in neueren Versionen auch.

    > Der Vorteil der
    > Tools ist halt, dass sie schneller sind, aber eine Alternative sind sie mMn
    > nicht.

    Die Geschwindigkeit ist ein Vorteil, aber ein weiterer und entscheidender ist dass address sanitizer eine deutlich größere Klasse an Bugs erkennt.

    > Bezüglich coverage-based Fuzzing muss ich sagen, dass mir das nicht
    > wirklich reicht. Ich will die Tests selbst schreiben, wenn möglichst auf
    > kleinster Ebene.
    > Also nicht das klassische System-Fuzzing bei der man eine ganze Binary
    > fuzzt, sondern eher eine Art Unit-Fuzzing um die korrekte Ausführung
    > einzelner Funktionen zu überprüfen.

    Genau das kann man mit libfuzzer machen.

  9. Re: Anständiges Fuzzing-Framework fehlt

    Autor: skade 04.04.17 - 18:03

    Es gibt Integration in libfuzz und American Fuzzy Lop (AFL) und die Verwendung ist nicht unüblich:

    https://crates.io/crates/cargo-fuzz
    https://github.com/rust-fuzz/afl.rs

  10. Re: Anständiges Fuzzing-Framework fehlt

    Autor: Headcool 04.04.17 - 23:32

    hannob (golem.de) schrieb:
    --------------------------------------------------------------------------------
    > Das ist falsch. In clang geht das schon lange, in gcc in neueren Versionen
    > auch.

    Die Clang Dokumentation listet diesen Teil noch als experimental.

    > Die Geschwindigkeit ist ein Vorteil, aber ein weiterer und entscheidender
    > ist dass address sanitizer eine deutlich größere Klasse an Bugs erkennt.

    Also, wenn man die Leaks Detection die noch experimental ist nicht mitzählt, dann bin ich da anderer Meinung.
    Gut gefällt mir aber der UndefinedBehaviorSanitizer. Denn das sind die Bugs die man normalerweise nicht findet/ignoriert.
    Wenn man alle diese Sanitizer benützt stimmt das mit der größeren Klasse an Bugs allerdings schon.
    Problematisch ist aber die Auswahl an Betriebsystemen. Windows sollte unbedingt unterstützt werden, und eine GUI für den Produktiveinsatz braucht es auch.

    > Genau das kann man mit libfuzzer machen.

    Du hast mich nicht genau verstanden. Ich will die Datengeneration anpassen. Ich will ja nicht nur einen Haufen Mülldaten generieren lassen um irgendwelche Crashes zu testen, sondern ich will vor allem einen Haufen gültiger Daten generieren lassen um diese mit einer existierenden Alternativversion vergleichen zu können. Was gültige Daten sind soll der Fuzzer nicht teuer und langwierig herausfinden müssen da ich ja schon weiß wie meine Invarienten aussehen. Ich will mithilfe von Datengeneratoren, welche Teil des Fuzzingframeworks sein sollten, gültige Daten generieren. Ich will Abhängigkeiten zwischen Daten angeben, ich will Zufallsverteilungen von Daten angeben, ich will besonders kritische Werte/Wertbereiche angeben damit mit diesen mehr und intensiver getestet wird.

  11. Re: Anständiges Fuzzing-Framework fehlt

    Autor: Boereck 05.04.17 - 08:55

    > Du hast mich nicht genau verstanden. Ich will die Datengeneration anpassen.
    > Ich will ja nicht nur einen Haufen Mülldaten generieren lassen um
    > irgendwelche Crashes zu testen, sondern ich will vor allem einen Haufen
    > gültiger Daten generieren lassen um diese mit einer existierenden
    > Alternativversion vergleichen zu können. Was gültige Daten sind soll der
    > Fuzzer nicht teuer und langwierig herausfinden müssen da ich ja schon weiß
    > wie meine Invarienten aussehen. Ich will mithilfe von Datengeneratoren,
    > welche Teil des Fuzzingframeworks sein sollten, gültige Daten generieren.
    > Ich will Abhängigkeiten zwischen Daten angeben, ich will
    > Zufallsverteilungen von Daten angeben, ich will besonders kritische
    > Werte/Wertbereiche angeben damit mit diesen mehr und intensiver getestet
    > wird.

    Hm, das klingt eher so, als wolltest du eine C Version von QuickCheck haben. Es gibt einige C Portierungen:
    https://en.m.wikipedia.org/wiki/QuickCheck
    Ist nur die Frage ob dir das komfortabel genug für deine Zwecke ist.

  12. Re: Anständiges Fuzzing-Framework fehlt

    Autor: Headcool 05.04.17 - 15:15

    Naja, Datengeneratoren gibts es viele. Wenn man nur die verwendet, dann endet man letztendlich bei einer Art Bruteforcefuzzing für zugegeben gültige Daten. Ich würde schon gerne die genetischen Algorithmen moderner Fuzzer nützen.
    Was mir sonst noch eingefallen wäre ist was nötig wäre mocking. Wenn man nur eine Funktion testen will, dann ist es oft notwendig eine Funktion zu mocken und die Daten dafür sollten auch vom Fuzzer generiert werden, natürlich in den Rahmenbedingungen die der Programmierer spezifiziert hat.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Fraunhofer-Institut für Software- und Systemtechnik ISST, Dortmund
  2. EMS Electro Medical Systems GmbH, München
  3. AIR LIQUIDE Deutschland GmbH, Düsseldorf
  4. Hochschule für Technik Stuttgart, Stuttgart

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 55,99€ (Bestpreis)
  2. 413,10€ (mit Rabattcode "PRAKTISCH" - Bestpreis)
  3. 96,90€ (inkl. Rabattgutschein - Bestpreis)
  4. (u. a. Microsoft 365 Family 1 Jahr für 76,90€, Braun Stabmixer MQ 7045X für 99,90€)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Programm für IT-Jobeinstieg: Hoffen auf den Klebeeffekt
Programm für IT-Jobeinstieg
Hoffen auf den Klebeeffekt

Aktuell ist der Jobeinstieg für junge Ingenieure und Informatiker schwer. Um ihnen zu helfen, hat das Land Baden-Württemberg eine interessante Idee: Es macht sich selbst zur Zeitarbeitsfirma.
Ein Bericht von Peter Ilg

  1. Arbeitszeit Das Sechs-Stunden-Experiment bei Sipgate
  2. Neuorientierung im IT-Job Endlich mal machen!
  3. IT-Unternehmen Die richtige Software für ein Projekt finden

Weclapp-CTO Ertan Özdil: Wir dürfen nicht in Schönheit und Perfektion untergehen!
Weclapp-CTO Ertan Özdil
"Wir dürfen nicht in Schönheit und Perfektion untergehen!"

Der CTO von Weclapp träumt von smarter Software, die menschliches Eingreifen in der nächsten ERP-Generation reduziert. Deutschen Perfektionismus hält Ertan Özdil aber für gefährlich.
Ein Interview von Maja Hoock


    Fiat 500 als E-Auto im Test: Kleinstwagen mit großem Potenzial
    Fiat 500 als E-Auto im Test
    Kleinstwagen mit großem Potenzial

    Fiat hat einen neuen 500er entwickelt. Der Kleine fährt elektrisch - und zwar richtig gut.
    Ein Test von Peter Ilg

    1. Vierradlenkung Elektrischer GMC Hummer SUV fährt im Krabbengang seitwärts
    2. MG Cyberster MG B Roadster mit Lasergürtel und Union Jack
    3. Elektroauto E-Auto-Prämie übersteigt in 2021 schon Vorjahressumme