Cuberite Forum

Just wondering: Did anyone (?) ever try packet-fuzzing the server to identify crashes and/or security vulnerabilities caused by malformed packets?

I haven't. The tool I use primarily handles files, and cProtocol is too closely tied to cClientHandle to build easily on its own. I would like to have another look at doing it at some point, as I wouldn't be suprised if I found crashes.

(12-26-2015, 11:10 PM)worktycho Wrote: [ -> ]I haven't. The tool I use primarily handles files, and cProtocol is too closely tied to cClientHandle to build easily on its own. I would like to have another look at doing it at some point, as I wouldn't be suprised if I found crashes.

I wonder if we could use the American Fuzzy Lop for this: Save a typical packet in a file, feed it to netcat and make it transmit it to the server, see if that causes a crash, and report back to AFL so that it modifies the file.

---

Also, to fuzz things beyond initial connection, one would have to replace netcat with some custom software, which connects, authenticates, and joins the world, and only then sends the fuzzing packet stored in the file.

Also, you'd either need to deal with server startup time, which would need a serious cluster to find anything, or use black box mode, which isn't as good.

(12-26-2015, 11:27 PM)worktycho Wrote: [ -> ]Also, you'd either need to deal with server startup time, which would need a serious cluster to find anything, or use black box mode, which isn't as good.

We wouldn't need to restart per test, a restart per crash is enough. It's fine to test multiple packets on the same running server.

If you want to run afl in non-blackbox mode you need to restart, because otherwise the instrumentation will cause problems.

Couldn't we just build an executable that would use the cProtocol180 class from Cuberite, but provide custom implementation of all the classes it depends upon, and feed it from stdin instead of network? That way, we could fuzz just the packet parsing, which is at least the first line of defense against malicious attacks.

Thats what i'm thinking, but with some nasty preprocessor stuff so we can redirect the headers. Otherwise we end up including everything.