vendredi 2 janvier 2015

Fuzzing and consequences on testing environement



I asked this question on StackOverflow but got no answers so I thought that I would try my luck here since fuzzing in closely related to security and often used in vulnerability assessment tests.


I'm currently writing a fuzzer that will generate a payload based on a custom specification format.


All is fine and I'm happy with the first version I wrote but I encountered an issue when trying to apply this fuzzer on a task that wasn't my initial use case.


The issue is related to how the fuzzer's input will affect the testing environment. e.g:




  • If the tested method constructs a buffer which's size is a variable argument. What would happen if the generated value is 2^64 and would trigger an out-of-memory (OOM) error ?




  • If the test method removes a file specified by a variable filename. What would happen if the generated value is * and the whole directory would be deleted ?




Of course these are just some naive examples but the point is that I'm trying to find a way to reduce the consequences of fuzzing on the test environment (while still remaining portable if possible).


This would make the fuzzer safer to use but also more fluent because fuzz test cases could be easily chained and run in parallel without breaking or corrupting the environment every other payload.


There are some radical solutions like:



  • not using fuzzing on methods that could have critical side effects and consequences

  • black-listing / white-listing certain inputs in certain use cases


Both would be really limiting in my opinion and make it difficult to use the fuzzer generically on black-box fuzz testing.


Other possible solutions like:



  • running tests in a headless VM like Vagrant

  • running tests in a Linux container like Docker

  • intercepting certain syscalls like I/O calls and sanitize their input


are valid but all suffer of the issue that they are very high-level. Syscalls and Docker also have the problem of not being very portable.


How do more professional / enterprise fuzzers handle this issue ?


I would imagine that black-box testing software probably solved this issue in a portable way ?





Aucun commentaire:

Enregistrer un commentaire