1500946 - Content Process can forge System Principal in Drag and Drop

Status: RESOLVED FIXED

(Core :: DOM: Copy & Paste and Drag & Drop, enhancement)

Description

[Tom Ritter [:tjr]]

In PBrowser.ipdl, InvokeDragSession accepts a principal from the content process.

This principal will propogate through and one of the places it reaches is TabParent::AddInitialDnDDataTo. If no principal was supplied, we will grant it the System Principal. (The Content Process may also be able to pass the System Principal.)

After propogating the principal to DataItems, it will be used in DataTransferItem::Data where a security check will be performed on the principal: "Check if the caller is allowed to access the drag data. Callers with chrome privileges can always read the data."  

This implies to me that a Content Process could use this mechanism to read data that they should not be privlegded to read.

Besides correcting any possible System Principal issues; we should assert that the Principal corresponds to the origin the content process is serving. (But that may be a followup bug under fission-ipc)

Comment 1

[Alex Gaynor [:Alex_Gaynor]]

If I've read this code correctly, with a compromised child process, you'd be able to trigger a load of a file:// protocol, which is then same-origin with other file:// URIs, allowing you more access to the disk then you should have.

:smaug, it looks like you were one of the more recent folks to work on DnD, can you take a look?

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

I guess we need to look at all the principal handling on IPC level.

Comment 3

[Tom Ritter [:tjr]]

Thinking about this more, I don't think this can be abused as a sandbox escape, but I'd like a second opinion about what the consequences of this issue could be so we can triage it appropriately. Neil, would you be able to weigh in, or pass to someone?

Comment 4

[Neil Deakin]

we should assert
that the Principal corresponds to the origin the content process is serving.
(But that may be a followup bug under fission-ipc)

The principal is only supplied at one place at https://searchfox.org/mozilla-central/rev/2e3b0483e31abffe0b4374480a34c6d23f5186ea/dom/ipc/BrowserParent.cpp#3723 so we should be able to verify at that spot that the principal is accessible from the corresponding child process. Content processes would only be adding data from the principal of the node the drag started on. For starting a drag however, it should not be using the system principal though. I'm not clear from the description above if/where this is happening.

Comment 9

[Tom Schuster [:tschuster]]

Fixed in bug 2054665.