Posts: 721
Threads: 77
Joined: Apr 2014
Thanks: 0
Given 8 thank(s) in 89 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: 0
Given 4 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: 0
Given 4 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: 0
Given 4 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,486
Threads: 176
Joined: Jan 2012
Thanks: 40
Given 157 thank(s) in 838 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: 0
Given 4 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.