Closed Bug 516716 (Fuzz-IPDL) Opened 14 years ago Closed 7 years ago

Dynamic fuzzing of IPDL (generically)


(Core :: IPC, defect, P2)

Windows NT





(Reporter: benjamin, Assigned: posidron)


(Blocks 2 open bugs)


(Keywords: meta, sec-other, Whiteboard: [soft])

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.
Hrm, this might be a dup of bug 506303. cjones, are they equivalent?
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.
Summary: Dynamic fuzzing of IPDL → Dynamic fuzzing of IPDL (generically)
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.
blocking-basecamp: --- → +
Whiteboard: [soft]
Depends on: 778382
Depends on: 779988
Depends on: 780219
Priority: -- → P2
Really want this, can ship with out it.
blocking-basecamp: + → ---
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
blocking-basecamp: --- → ?
Depends on: 781594
Depends on: 781903
Assignee: nobody → cdiehl
blocking-basecamp: ? → ---
Depends on: 782940
Depends on: 782945
Depends on: 807262
Depends on: 807263
Depends on: 807264
Depends on: 807266
Depends on: 807738
Depends on: 808080
Group: core-security
Keywords: meta, sec-other
Group: core-security → dom-core-security
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.
See Also: → 1359755
Closing this as the dup contains the actual work here.
Closed: 7 years ago
Resolution: --- → DUPLICATE
See Also: 1359755
Group: dom-core-security
You need to log in before you can comment on or make changes to this bug.