Posts: 721
Threads: 77
Joined: Apr 2014
Thanks: 113
Given 130 thank(s) in 91 post(s)
12-26-2015, 06:49 PM
(This post was last modified: 12-26-2015, 06:50 PM by LogicParrot.)
Just wondering: Did anyone (@tycho?) ever try packet-fuzzing the server to identify crashes and/or security vulnerabilities caused by malformed packets?
Posts: 783
Threads: 12
Joined: Jan 2014
Thanks: 2
Given 73 thank(s) in 61 post(s)
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.
Posts: 783
Threads: 12
Joined: Jan 2014
Thanks: 2
Given 73 thank(s) in 61 post(s)
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.
Posts: 783
Threads: 12
Joined: Jan 2014
Thanks: 2
Given 73 thank(s) in 61 post(s)
If you want to run afl in non-blackbox mode you need to restart, because otherwise the instrumentation will cause problems.
Posts: 6,485
Threads: 176
Joined: Jan 2012
Thanks: 131
Given 1075 thank(s) in 852 post(s)
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.
Posts: 783
Threads: 12
Joined: Jan 2014
Thanks: 2
Given 73 thank(s) in 61 post(s)
Thats what i'm thinking, but with some nasty preprocessor stuff so we can redirect the headers. Otherwise we end up including everything.