Fuzzing a service that should not restart #1463
Replies: 12 comments
-
is that a binary only target or do you have source code and can compile it? |
Beta Was this translation helpful? Give feedback.
-
I have the source code of the target service and I can compile it before it starts running. |
Beta Was this translation helpful? Give feedback.
-
then the only senseful approach is to extend the daemon to also act as a client to which afl-fuzz talks directly. the forkserver should the be set up to be just before the input is received. |
Beta Was this translation helpful? Give feedback.
-
I can do that. So, do you mean saying that it is not possible to fuzz the daemon with the client running as a separate program and sending requests generated by afl++? |
Beta Was this translation helpful? Give feedback.
-
it is possible, but a very difficult setup and slow too. plus even if you find a crash you will maybe not be able to repeat it because you are not resetting any state in the server. |
Beta Was this translation helpful? Give feedback.
-
That would seem to be somewhat debatable? For example, https://github.com/s3team/Squirrel has done exactly that for database servers, and it works quite well. It's a bit slow, but crahes are often repeatable. A new state is initialized on a constantly running database sever by creating new databases and testing therein. Not perfect, but good enough to get reasonable results (think 40 repeatable crashes over a weekend runtime). Note that there are other things which Squirrel implemented which make it usable in this way - i.e. when talking about simple bitflipping etc instead, I agree that you would seem to need a high throughput of test in order to work well. |
Beta Was this translation helpful? Give feedback.
-
as I wrote it is possible, but a very complex setup and very very slow. sure if the overall software quality is bad you will find crashes even in a slow setup. but if your goal is to find all the bugs over time you gain a lot more by a fast fuzzing setup. if that code to clean up the state + database is already there in the server to support fuzzing it is great because you can use the same thing for the direct server fuzzing. |
Beta Was this translation helpful? Give feedback.
-
Sorry due to the functioning of my server, I cannot run the client within the server. The client must run as a separate process. One of the many reasons: The server runs in a privileged VM and the client running in the same VM can perform actions that normal clients in a different VM can't. In the first step, I just want to know how we can separate the client from the server if they are running in the same VM.
Would AFL++ use the coverage data of the server to generate new inputs automatically or we expand AFL++ for this purpose? |
Beta Was this translation helpful? Give feedback.
-
it is possible to make it work that afl-fuzz talks to a client that talks to the server. Then you are in the loop of the afl-proxy. there you receive the fuzzing data, send it to the server, check for crashes. In the server just must have a mechanism that you reset the database state, or better all state, after processing an input from the special client. |
Beta Was this translation helpful? Give feedback.
-
@vanhauser-thc, thank you for your response. I have looked into
Let me know if this would be the right implementation of you explanation. |
Beta Was this translation helpful? Give feedback.
-
passing the map size: you need to check the map size of the target (just run it with AFL_DEBUG=1 set and it will tell you) and this is the map size afl-proxy needs to report. passing coverage: you dont need to do anything except that alf-proxy receives the SHMID via env and thats why it should start the server so that this is automatic |
Beta Was this translation helpful? Give feedback.
-
Thank you for your reply. |
Beta Was this translation helpful? Give feedback.
-
I would like to fuzz a service (xenstored) in Xen hypervisor using AFL++. The service starts when the hypervisor starts, it receives requests from different clients in the VMs on the same instance hardware and continues to run throughout the life of the instance. The client writes the requests on a file or a shared memory buffer and then the service, which has its own independent execution, responds to the requests. I think that if my following questions are answered, it would be really helpful in fuzzing my target.
For fuzzing the service, I would need to create a test harness that works as a client and sends the requests generated by AFL++ to the service. I need to create a test harness client because the service can only process the requests received from a client via a connection. Can I fuzz a service that has its execution independent from the test harness? (the service runs as a separate program from test harness). Would compiling the source code of the service with afl compiler and then running the test harness with afl-fuzz command be enough? The complied service would start running when the hypervisor starts whereas the test harness would run after the booting is completed.
The service runs in the background as a daemon. Can I fuzz a program running in the background as a daemon or do I need to run it in the foreground for fuzzing?
Ideally, on a crash, the service should not need to be restarted from the beginning. I am aware that for this, there is the forkserver mode. When the service starts with the hypervisor, it receives some requests which change its state after booting. If I put the forkserver command before the line in code for receiving requests, on a crash, the restored state would be the initial state before booting, while I want to restore the state of the service after booting. Is there a way to apply forkserver that restores the state of the service to where it was before running the test harness or to just before the last request?
Beta Was this translation helpful? Give feedback.
All reactions