Issue metadata
Sign in to add a comment
|
Security: Sandboxed iFrame postMessage origin changes during async history navigate render iFrame content swap bug
Reported by
ricky.bl...@oath.com,
Oct 6 2017
|
||||||||||||||||||||||||
Issue descriptionVULNERABILITY DETAILS Building on Chrome rendering bugs 500260 /771719, we have two iFrames created on page load in a different order each page view. The iFrames each contain a pages served from the same domain. However we sandbox one of those iFrames to allow scripts but to be considered an alternate origin when messages are sent. Both pages send postMessages to the top window. The top window should be able to safely ignore messages from the sandboxed frame because origin of the sandboxed iFrame appears in a message event as "null" during normal page views in Chrome, FF, Safari. But in Chrome, when the iFrame contents are swapped during the known bug of re-render from history navigation, the sandboxed content appearing in the un-sandboxed frame results in a postMessage origin that is the full domain, instead of "null". This allows the content intended only to be sandboxed to be able to can invoke messages in the top window as if it were not sandboxed. VERSION Chrome Version: 61.0.3163.100 stable Operating System: mac OS Sierra 10.12.6 REPRODUCTION CASE See attached HTML file. 1. Start up a local web server at port 8080 and browse to http://localhost:8080/async-created-iframe-postMessage-sandbox.html. 2. Open the console and observe the postMessages: - Message sent from sandboxed iframe normally has origin of "null" so it can be safely ignored by the postMessage handler. 3. Close this tab then re-open the tab. - Or, click the link on the page then click the Chrome Back button. Both render the page using the problematic history navigation flow. 4. Observe how the iframe contents are swapped vs the iframe src attribute (this is covered in 500260/771719). 5. Open the console and observe the postMessages: - New security issue: The message sent from the page that should have been in the sandboxed iframe now has an origin present instead of "null", so the message is allowed but should not have been. Expected results: - Message should always have origin of "null" consistently even if iFrames are swapped. - Ideally once issues 500260 /771719 are resolved, iFrame contents would never swap.
,
Oct 8 2017
Missed attaching the two files loaded into the iFrames that each send a postMessage, and the file that instructs to click back. Place all files into the same directory as the original attachment.
,
Oct 9 2017
Testing further, we also see that cookies leak on a sandbox iframe during the iframe swap issue. Steps to repeat: 1. Top level page creates sandbox iframe, which normally prevents malicious page hosted on the same domain from reading the cookies. 2. When malicious page tries reading document.cookie on a normal page render, an exception is thrown as expected. 3. Close the tab and re-open the tab so that the iframe swap issue happens. 4. Observe that when the swap happens, the malicious page was able to read the cookies, and the un-sandboxed iframe is unable to read cookies. Expected result is the sandbox iframe is never able to read cookies. See all 4 HTML files updated to include cookie tests in the attached ZIP file.
,
Oct 9 2017
Adding alexmos@ and mkwst@, as first line triage for sandboxed iframes. Feel free to reroute appropriately.
,
Oct 9 2017
nasko@ - this is more of an issue with 1) history navigations being confused about which frames they should target because of how frame unique names are calculated (same as issue 500260 ), but the bug here shows that the effect of the confusion can have security implications - 2) url that should (used to) be sandboxed can be restored into a non-sandboxed frame.
,
Oct 12 2017
seems like medium severity to me, but feel free to tweak based on the ongoing triage.
,
Oct 13 2017
,
Oct 13 2017
,
Oct 18 2017
Assigning per C4, feel free to re-assign as appropriate.
,
Oct 18 2017
I was looking at things we could do for issue 500260 (which this is almost a dupe of, except for pointing out security implications).
,
Nov 3 2017
Status update: 1. Making good progress on https://crrev.com/c/713654 (I think we should be able to land it next week at the latest). 2. The CL with the fix turned out to be quite big - I would be somewhat uncomfortable merging it. 3. There are some factors mitigating the impact of the bug (OTOH, even with the mitigating factors in mind, the bug still looks like medium severity to me / based on the triage guidelines at https://www.chromium.org/developers/severity-guidelines): 3.1. The attacker doesn't have control over the page being attacked. 3.1.1. For the attack to succeed, some attacker-controlled content has to be embedded in a sandboxed frame by the page being attacked. 3.1.2. The page being attacked can prevent the attack by naming frames. OTOH, I can see not many pages doing this (there have been quite a few reports of issue 500260 happening in the wild). 3.1.3. The attacker doesn't control which frames will be swapped (it somewhat randomly depends on how frames are misidentified during history navigation - see issue 500260 for details). Therefore, even if the page didn't prevent dynamic frame confusion (3.1.2 above), the attack might still fail because the swap happens between frames with the same level of sandboxing (or the attacker-controlled content is swapped with a frame with a higher level of sandboxing).
,
Nov 3 2017
+awhalley@ for items 2 and 3 in #c11 above (although it is probably a bit too early for making merge decisions - the CL with a fix hasn't landed yet).
,
Nov 4 2017
Thanks for the details. Given we're also pretty late on in the 63 cycle, I'm ok moving this to 64.
,
Nov 9 2017
The fix for issue 500260 that has just landed (r515279) should also address this issue.
,
Nov 9 2017
Great news! Thanks so much lukasza & team.
,
Feb 16 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 elawrence@chromium.org
, Oct 7 2017