My idea was to fuzz rpcbind, which should be easy enough.
apt-get source rpcbind and
apt-get source libtirpc. The first problem was getting libtirpc to compile, which needed the following magic command:
autoreconf --install. Both packages can be compiled with clang. But the main issue was that rpcbind/portmapper binds on port 111 by default, and rpcinfo connects to port 111 by default. But for the interception proxy to work, one of these programs need to work on a different port (e.g. rpcbind listen on port 112, and the MITM proxy will listen on port 111, and rpcinfo will connect to port 111). Strangely enough, both packages seem to not define the port number to connect to, a
grep -R 111 * resulted in zero results. How can this be? After some source code digging, i realized that both programs take the port via the name
$ grep portmapper /etc/services sunrpc 111/tcp portmapper # RPC 4.0 portmapper sunrpc 111/udp portmapper
This resulted in the following workflow:
- start FFW interceptor with listenport 1024, targetport 111
/etc/services, replace 111 with 1024
- Start rpcinfo client, which will then connect to port 1024, which will forward to port 111
- After recording is finished, dont forget to revert the port in
- Fuzz with
I let it run for some time, and no immediate crashes appeared. I let it run for a night, and had the following result:
root@fuzzer:~/ffw/rpcbind# ls -l out/ | wc -l 1096355
That is 1 million crashes! The recovery mode of the last commits seem to have messed up crash detection, rpcbind probably was unable to start sooner or later, and FFW detected a crash on every iteration. This should be fixed with
- portmapper is very old. It has unusual source code and behaviour, and is hard to compile. Indeed a dinosaurier of the original Unix.
- The quest on making FFW stable and reliable continues. It still seems that for every bug i fix, i add a new one. The state machine which manages the interaction between FFW, Honggfuzz and the target is still not finished.