516716 - (Fuzz-IPDL) Dynamic fuzzing of IPDL (generically)

Status: RESOLVED DUPLICATE of bug 777067

(Core :: IPC, defect, P2)

Description

[Benjamin Smedberg]

We'd like to dynamically fuzz IPDL to verify that any sequence of messages allowed by the IPDL protocol cannot generate protocol errors (and therefore kill the child process).

It should be possible to generate the fuzzer directly from the IPDL protocol declarations.

Comment 1

[Benjamin Smedberg]

Hrm, this might be a dup of bug 506303. cjones, are they equivalent?

Comment 2

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Comment 0 describes a dup of bug 506303, yeah.

But if this task is what I remember, it's to fuzz the *IPDL* infrastructure.  That is, take any random protocol and inject as many system-level errors as possible, and make sure the IPDL code can tolerate the error and clean up properly.  Some examples of system-level errors are the IPC pipe closing at arbitrary times, child process crashing (maybe the same), failed write to the pipe, failed read, failure to serialize/deserialize data, and so forth.

Comment 4

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

There are three levels at which it's most useful to "fuzz" the IPC system
 - first is OS level fault injection.  Adding code to content processes to randomly crash, close IPC sockets, and send-known bad data like fds.  This is relatively straightforward and we may be able to use existing tools.  It would be most useful to run these during test suites.

 - second is socket-level "dumb" fuzzing of protocols.  After some random amount of time, start writing random garbage to the IPC sockets from content processes.  Again, this would be useful to run during test suites.  This is quite straightforward.

 - third is protocol-level "smart" fuzzing of protocols.  Use the .ipdl files themselves to generate code to write malicious IPC messages, randomly.  More specifically, randomly replace a requested message to be sent with a maliciously-constructed one.  The idea here is, when you see int32_t in messages, send extreme values like INT32_MAX, INT32_MIN.  Send "", "\0f", really long strings for string parameters.  Send random IDs in slots where valid actor IDs are supposed to go.  Etc.  This is pretty difficult.

I would recommend going from first level to third.  I provide more specifics about where to hook in fuzzing code for each.

Comment 5

[Andreas Gal :gal]

Really want this, can ship with out it.

Comment 6

[Jason Smith [:jsmith]]

Per IRC conversations with a few other folks, I think the best course of action if there is disagreement on whether this blocks or not is to do the following:

- Move the blocking-basecamp flag to ? for re-evaluation
- Indicate a rationale for why you disagree

Comment 7

[Paul Theriault [:pauljt] (no longer reading bugmail)]

cdiehl, can we open this up? I dont think it needs to be hidden? Also note that bug 1359755 is to implement the protocol level fuzzer (part 3) as referenced in comment 4.

Comment 8

[Paul Theriault [:pauljt] (no longer reading bugmail)]

Closing this as the dup contains the actual work here.