libqubes-rpc-filecopy fuzz target
The libqubes-rpc-filecopy fuzz target is now running on ClusterFuzz’s infrastructure for the past ~5 days now. There were a few hiccups in the integration initially, but now the integration is complete and we have our first set of statistics. The qubes developers on the CC list for oss-fuzz can view the statistics on the oss-fuzz webapp.
There seem to be a lot of crashes right now, but none is security related or reproducible. Judging from the performance report:
The crashes are caused by testcases which trigger timeouts (t > 25s), and due to slow units. I will analyze the particular testcases which trigger these crashes and attempt to eliminate them.
Based on the coverage report, there are some portions of the code which are not being covered. For ideal integration, oss-fuzz recommends > 80% coverage. We should aim to get the coverage atleast up to that mark.
Other fuzz targets
Most of the qubes components have a server-client architecture, and fuzzing network calls is quite complicated. Earlier, the only solution I found was to rewrite our own implementation of the send() and recieve() calls to enable file I/O. But unfortunately, that could not work because it involves using LD_PRELOAD which I doubt the ClusterFuzz environment supports.
After discussing with my mentor, we figured that writing a mock libvchan library for file I/O and statically linking it to the fuzz targets would be our best option. I have started writing it. We do not necessarily want all the functionality that the original libvchan library has. We only need the library to roughly mimic the original one with file I/O.
Fuzzing the GUI
We had started the integration with oss-fuzz with initial focus on the inter-vm filecopy and the GUI. The libqubes-rpc-filecopy fuzzer is running now and after some improvements it should be running efficiently. Fuzzing the GUI however, involves bypassing the network calls (which we plan to do with the mock libvchan lib), and being able to run the target. In order to actually run, say the qubes-gui-daemon, we would require the X server (prefferably xvfb) to be running on the machine. ClusterFuzz however does not allow us to run (or even install) xvfb on it’s bots. We need to come up with some workaround for this.
Meanwhile, I will be looking into adding other possible fuzz targets that work well with the ClusterFuzz infrastructure.
GSoC Second phase
The first phase of GSoC is over. Based on the feedback I recieved from my mentor, from now on I will try to limit the discussions on IRC, and try to have them on the qubes-devel mailing list instead, for a more open discussion where others can join in. Once we have some more fuzz targets running efficiently on ClusterFuzz, we will begin work on static analysis.
As of now, the immidiate goals for the second phase, as I see it, are:
- Fixing the timeout and slow units issue in the libqubes-rpc-filecopy fuzz target
- Integrating other fuzz targets.
- Getting the coverage up to 80% at least on all targets
- Once the oss-fuzz integration is wrapped up, we should aim to add the fuzz targets to the upstream repositories.
- Starting the work on static analysis.