Abo
  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: hannob (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: hannob (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.

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. UDG United Digital Group, Karlsruhe, Mainz
  2. Haufe Group, Freiburg im Breisgau
  3. awinia gmbh, Freiburg
  4. Universität Potsdam, Potsdam

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 0,49€
  2. 39,99€
  3. 2,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Bug Bounty Hunter: Mit Hacker 101-Tutorials zum Millionär
Bug Bounty Hunter
Mit "Hacker 101"-Tutorials zum Millionär

Santiago Lopez hat sich als Junge selbst das Hacken beigebracht und spürt Sicherheitslücken in der Software von Unternehmen auf. Gerade hat er damit seine erste Million verdient. Im Interview mit Golem.de erzählt er von seinem Alltag.
Ein Interview von Maja Hoock

  1. White Hat Hacking In unter zwei Stunden in Universitätsnetzwerke gelangen

Kontist, N26, Holvi: Neue Banking-Apps machen gute Angebote für Freelancer
Kontist, N26, Holvi
Neue Banking-Apps machen gute Angebote für Freelancer

Ein mobiles und dazu noch kostenloses Geschäftskonto für Freiberufler versprechen Startups wie Kontist, N26 oder Holvi. Doch sind die Newcomer eine Alternative zu den Freelancer-Konten der großen Filialbanken? Ja, sind sie - mit einer kleinen Einschränkung.
Von Björn König


    Homeoffice: Wenn der Arbeitsplatz so anonym ist wie das Internet selbst
    Homeoffice
    Wenn der Arbeitsplatz so anonym ist wie das Internet selbst

    Homeoffice verspricht Freiheit und Flexibilität für die Mitarbeiter und Effizienzsteigerung fürs Unternehmen - und die IT-Branche ist dafür bestens geeignet. Doch der reine Online-Kontakt bringt auch Probleme mit sich.
    Ein Erfahrungsbericht von Marvin Engel

    1. Bundesagentur für Arbeit Informatikjobs bleiben 132 Tage unbesetzt
    2. IT-Headhunter ReactJS- und PHP-Experten verzweifelt gesucht
    3. IT-Berufe Bin ich Freiberufler oder Gewerbetreibender?

    1. ML-Processor: ARMs Smartphone-NPU schafft 5 Teraops pro Watt
      ML-Processor
      ARMs Smartphone-NPU schafft 5 Teraops pro Watt

      Computex 2019 Der ML-Processor ist, der Name impliziert es bereits, für Machine Learning gedacht: Der Funktionsblock von ARM soll neben CPU/GPU in Smartphone-Chips stecken und dort aufwendige Berechnungen bei hochauflösenden Fotos durchführen oder bei der Entsperrung per Gesicht helfen.

    2. Mali-G77: ARMs Valhall-Grafikeinheit ist 40 Prozent flotter
      Mali-G77
      ARMs Valhall-Grafikeinheit ist 40 Prozent flotter

      Computex 2019 Valhall- statt Bifrost-Architektur: ARMs Mali-G77 nutzt eine massiv veränderte Technik mit deutlich breiteren Ausführungseinheiten und eine zusätzliche Cache-Stufe. Daher laufen Spiele gleich 40 Prozent flotter und Machine Learning wird gar um 60 Prozent schneller berechnet.

    3. Cortex-A77: ARM-Kern hat 20 Prozent mehr Leistung pro Takt
      Cortex-A77
      ARM-Kern hat 20 Prozent mehr Leistung pro Takt

      Computex 2019 Mit dem Cortex-A77 hat ARM einen CPU-Kern für das 7-nm-Verfahren entwickelt, der teils ein Drittel flotter ist als der Cortex-A76. Ein Fünftel davon macht die IPC aus, denn der Kern wurde deutlich breiter als bisher.


    1. 06:00

    2. 06:00

    3. 06:00

    4. 03:45

    5. 20:12

    6. 11:31

    7. 11:17

    8. 10:57