Bug 189840
| Summary: | Should we really CRASH() in ChildProcess::didReceiveInvalidMessage? | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Michael Catanzaro <mcatanzaro> |
| Component: | WebKit2 | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED INVALID | ||
| Severity: | Normal | CC: | ap, mcatanzaro |
| Priority: | P2 | ||
| Version: | Other | ||
| Hardware: | PC | ||
| OS: | Linux | ||
Michael Catanzaro
Both the cross-platform and Cocoa-specific implementations of ChildProcess::didReceiveInvalidMessage call CRASH(). So any invalid message sent from a child process will crash the parent process.
But the WK2 security model assumes the child process is compromised. Surely a malicious child process should not be able to DOS the UI process just by sending an invalid message. I think CRASH() would only be appropriate if running a debug build.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Alexey Proskuryakov
Could you clarify the scenario that you have in mind? ChildProcess::didReceiveInvalidMessage is code that runs in child processes, so it doesn't crash the UI process.
Michael Catanzaro
Ummm yeah, you are right of course. I must have been thinking it was ChildProcessProxy... but I was even looking at a NetworkProcess crash at the time... I guess my brain was turned off when I reported this. Closing.