richo/roving

roving's Issues

Hostnames with . causes fuzzer to not start

Trying to run the example target on my machine gives me the following error message from the fuzzer:
afl-fuzz 1.83b by [email protected]

[-] PROGRAM ABORT : Non-alphanumeric fuzzer ID specified via -S or -M
Location : fix_up_sync(), afl-fuzz.c:7027

This is due to the hostname of my machine having the pattern xxx.yyy.com which makes the fuzzer ID look something like xxx.yyy.com-c46a. If I remove the periods, the fuzzer accepts the fuzzer IDs.

(This might actually be something that should be fixed in the fuzzer since I would have assumed periods to be valid if - is valid, but thought it might be good to have a workaround for the time being.)

Too many open files

Hi. The server shows “too many open files” when I was trying 4 clients. Is there anything wrong with my setting?

File descriptor exhaustion

Long running fuzzing sessions will eventually exhaust available file descriptors due to state syncs seeming to maintain a connection even after the client has retrieved the state. Haven't pin-pointed the actual offending line of of code yet. Will probably look into it more.

Building error

Hi~! When I build the client ,error shows
root@cszx:/roving# bazel build //cmd/client
ERROR: /roving/WORKSPACE:15:1: file '@bazel_gazelle//:deps.bzl' does not contain symbol 'go_repository'
ERROR: /roving/WORKSPACE:18:1: name 'go_repository' is not defined (did you mean 'local_repository'?)
ERROR: /roving/WORKSPACE:24:1: name 'go_repository' is not defined (did you mean 'local_repository'?)
....
How can I solve this problem?
Thank you !

Directory traversal bug in the server?

First of all: This tool looks nice!

So far my threat model has been that an attacker can connect to a roving server, download the target, get crashes, develop an exploit and upload that to own all the worker machines, but the following chain of events seems to make a write-what-where directory traversal on the server possible (I have not tested it):

• POST callback is called

func post(c web.C, w http.ResponseWriter, r *http.Request) {
        state := types.State{}

        encoder := json.NewDecoder(r.Body)
        encoder.Decode(&state)

        for _, hang := range state.Hangs.Inputs {
                hang.WriteToPath("work-server/hangs")
        }

        for _, crash := range state.Crashes.Inputs {
                crash.WriteToPath("work-server/crashes")
        }

        nodes[state.Id] = state
}

• WriteToPath doesn't sanitize anything, neither does the JSON decoder
• A File with arbitrary content is written to an arbitrary location (through the usual ../ dance)

func (i *Input) WriteToPath(path string) {
        path = fmt.Sprintf("%s/%s", path, i.Name)

        f, err := os.OpenFile(path, os.O_WRONLY|os.O_CREATE, 0644)
        if err != nil {
                log.Panicf("Couldn't open %s for writing", path, err)
        }

        body, err := base64.StdEncoding.DecodeString(i.Body)
        if err != nil {
                log.Fatal("Couldn't decode queue from %s", i.Name, err)
        }

        f.Write([]byte(body))
}

-M main nodes only

the syncing can be more effective if only the -M main nodes are synced from remote servers. only mains perform deterministic fuzzing hence only these have interesting data in .state/, and as all data is synced between local fuzzers, only one needs to be synced.
hence only main fuzzer nodes need to be synced, not everyone. this improves the speed of the syncing process, as well as the state syncing within afl