Issue metadata
Sign in to add a comment
|
Should an <iframe> access chrome://resources? |
||||||||||||||||||||||
Issue descriptionVersion: 50.0.2639.0 (Official Build) Canary OS: All Currently, when a whitelisted extension is loaded inside an <iframe>(specifically the PDF Viewer extension), the resources in chrome://resources are still not allowed to load (this is an issue for OOPIF-based MimeHandlerView). This behavior is not well-defined. Should we allow such (this) extensions to somehow access chrome://resources or not? Assuming that <iframe> is NOT allowed to access those resources, the following behavior seems flawed: 1- Run chrome with --site-per-process. 2- Navigate a tab to the PDF Viewer extension (could as well navigate to any PDF assuming that --use-cross-frames-for-guests is NOT active). 3- Navigate the <iframe> to the PDF Viewer extension. What is the expected output? The extension should not load the chrome://resources and throw errors. What do you see instead? The extension loads the chrome://resources. I believe this behavior is in part due to some permissions set by the ChildProcessSecurityProcess. The CPSPImpl grants permission to lead schemes based on RenderProcessHostImpl::id_. Since the PDF extension lives in a single process, after navigating the tab all the permissions for that tab are granted.This is how an <iframe> can access those resources if the extension is loaded on any other tab.
,
Mar 9 2016
,
Mar 10 2016
,
Mar 10 2016
,
Mar 10 2016
,
Mar 10 2016
ekaramad@: Does this have any impact outside --site-per-process? I'm not sure that this should be considered Security_Impact-Stable.
,
Mar 10 2016
I don't think it does. Without the --site-per-process <iframe> cannot load chrome://resources even if the extension is running. The <iframe> lives on the tab process and hence no access to chrome://resources. But is there a possibility that the tab process and Pdf extension are group together? I also cannot think of other ways a renderer process could chose to live in the extension process. But generally, what should chrome://resources be blocked on <iframe>'s?
,
Apr 1 2016
ekaramad@: Uh oh! This issue is still open and hasn't been updated in the last 21 days. Since this is a serious security vulnerability, we want to make sure progress is happening. Can you update the bug with current status, and what, if anything, is blocking? If you are not the right Owner for this bug, please find someone else to own it as soon as possible and remove yourself as Owner. If the issue is already fixed or you are to unable to reproduce it, please close the bug. (And thanks for fixing the bug!). These nags can be disabled by adding a 'WIP' label and an optional codereview link. - Your friendly ClusterFuzz
,
Apr 21 2016
ekaramad: Uh oh! This issue still open and hasn't been updated in the last 41 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers? If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one? If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 6 2016
ekaramad: Uh oh! This issue still open and hasn't been updated in the last 56 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers? If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one? If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 26 2016
,
May 27 2016
Changing to Security_Impact-None based on c#7.
,
Dec 2 2016
I am still wondering if this behavior is a bug or should I just mark this bug as a Wont Fix? To get into context the following two scenarios seem inconsistent to me: a) 1- Run chrome with --site-per-process and navigate an iframe to chrome-extension://mhjfbmdgcfjbbpaeojofohoefgiehjai/index.html?url= 2- You should see an error about not having access to chrome://resources. 3- Alternatively, you would not see the extension's zoom buttons. b) 1- Open a PDF inside a tab 2- In another tab add an <iframe> and navigate it to: chrome-extension://mhjfbmdgcfjbbpaeojofohoefgiehjai/index.html?url= 3- We can successfully load the chrome://resources inside <iframe>. 4- Alternatively, you can verify that the extension's zoom buttons appear this time. Which one is the correct behavior?
,
Nov 7 2017
This issue is now resolved. I suspect Alex's CL: https://chromium-review.googlesource.com/c/chromium/src/+/641818 and possibly Alex's other CL: https://chromium-review.googlesource.com/c/chromium/src/+/709937 have fixed the issue. Following the repro steps in comment #13 will now load the UI and fail at 'getStreamInfo' which is unrelated to the bug here. Marking as fixed.
,
Nov 8 2017
,
Feb 14 2018
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by raymes@chromium.org
, Mar 7 2016