Packet fuzzing?
#1
Just wondering: Did anyone (@tycho?) ever try packet-fuzzing the server to identify crashes and/or security vulnerabilities caused by malformed packets?
Reply
Thanks given by:
#2
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.
Reply
Thanks given by:
#3
(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.
Reply
Thanks given by:
#4
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.
Reply
Thanks given by:
#5
(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.
Reply
Thanks given by:
#6
If you want to run afl in non-blackbox mode you need to restart, because otherwise the instrumentation will cause problems.
Reply
Thanks given by:
#7
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.
Reply
Thanks given by:
#8
Thats what i'm thinking, but with some nasty preprocessor stuff so we can redirect the headers. Otherwise we end up including everything.
Reply
Thanks given by:




Users browsing this thread: 1 Guest(s)