Chromium

[Empty comment from Monorail migration]

Thanks for the report.
Could you please capture the crash report from chrome://crashes? That'd help triage this much faster.

I'm unable to reproduce this in ChromeOS (88.0.4324.99 {"arch":"x86-64","os":"cros"})

I used windows 10 when the tab crashes its error code is: STATUS_BREAKPOINT

Have now tested it using a new chrome install with Windows Sandbox.
It seems to be very depended on the correct timings I know changing it can make the current tab crash instead of the iframe.
It seems to help going to a new tab and back.

Tested with the chromium based microsoft edge toke a while but got it to crash
Going between tabs does seem to help probably my bad timings

[Comment Deleted]

Could you please capture the crash report ID from chrome://crashes? That'd help triage this much faster.

[Comment Deleted]

I clicked it its not signed in to my email.

[Comment Deleted]

Please tell me if you need a different crash or did not receive the first one.
Is it safe to keep the crash ID here?
Thanks for looking into the issue.

Hope this issue is still active I think I might have annoyed you with the delayed crash report but it seems like a strange state to end it.

Sorry I couldn't get back to you sooner. The bug is still active and the crash report would be very helpful for further triage soon.

arthursonzogni@ the call stack looks similar to https://crbug.com/chromium/926820 so assigning to you for now. Please feel free to re-assign to a more appropriate owner, if any.

[Empty comment from Monorail migration]

[Monorail components: Internals>Sandbox>SiteIsolation]

[Empty comment from Monorail migration]

https://crbug.com/chromium/1169844#c16: Can you explain the High severity rating for this?

I'm not seeing any crash when testing locally (in 88.0.4324.104 Windows Stable, or 90.0.4400.0 Windows Canary).  The "sad frame" for the iframe is because the Google and YouTube URLs were blocked by X-Frame-Options, not a crash.  I also don't see the browser close unexpectedly.

Can you perhaps attach a video of the behavior you're seeing, to clarify?

[Empty comment from Monorail migration]

From the crash-ID:
https://crash.corp.google.com/browse?stbtiq=76a49e75649f0032#4

The stack-trace seems to be:
content::RenderFrameHostManager::InitRenderFrame
content::RenderFrameHostManager::CreateSpeculativeRenderFrame
content::RenderFrameHostManager::CreateSpeculativeRenderFrameHost
content::RenderFrameHostManager::GetFrameHostForNavigation
content::RenderFrameHostManager::DidCreateNavigationRequest
content::FrameTreeNode::CreatedNavigationRequest
content::Navigator::Navigate
content::NavigationControllerImpl::NavigateFromFrameProxy
content::Navigator::NavigateFromFrameProxy
content::RenderFrameProxyHost::OpenURL
content::mojom::RenderFrameProxyHostStubDispatch::Accept

I tried to reproduce locally on 89.XXX and then on 88.0.4324.96. No crash. Identical results as creis@.
(See Video)

The crash location seems to come from a line modified recently (7 month ago).
https://chromium-review.googlesource.com/c/chromium/src/+/2246087
+fergal@, in case you might be able to speculate what could go wrong here?

In the video provided the iframe crashed the last step is to do f.src = "https://www.youtube.com";

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Thanks! I can sometimes reproduce. See video and crash:
https://crash.corp.google.com/browse?stbtiq=d8ca61952257aa7e#2

Tips => Another reliable way to reproduce is to crash manually the iframe using the Chrome task manager.

So what we need:
- An error document (as a result of XFO) (not sure if XFO relevant)
- Crash the error page.
- Navigate the error page.

This sounds like an edge case not handled correctly. The crash location point to ~recent fergal@ CHECK_EQ:
https://chromium-review.googlesource.com/c/chromium/src/+/2246087
The repro steps seems to be related to kSkipEarlyCommitPendingForCrashedFrame and RenderDocument.

The CHECK_EQ in:
https://crash.corp.google.com/browse?stbtiq=d8ca61952257aa7e#2
```
// No proxy means that this is a same-SiteInstance subframe navigation. A                      
// subframe navigation to a different SiteInstance would have had a proxy. A                    
// main frame navigation with no proxy would have its RenderFrame init                  
// handled by InitRenderView. This will change with RenderDocument for main                    
// frames.                      
DCHECK(frame_tree_node_->parent());                    
CHECK_EQ(render_frame_host->GetSiteInstance(),                  
         current_frame_host()->GetSiteInstance());
```


I don't believe this is Security_Severity-High, the browser process is crashing intentionally because we reached the CHECK_EQ.
By reading the guideline:
https://www.chromium.org/developers/severity-guidelines
```
Also note that most crashes do not indicate vulnerabilities. Chromium is designed to crash in a controlled manner (e.g., with a __debugBreak) when memory is exhausted or in other exceptional circumstances.
```
I would say Security_Severity is None? Or maybe Security_Severity-low? What do you think creis@?

https://chromiumdash.appspot.com/commit/92dbc123a0760b7fda4e15054fa047dc3ad0cd17
This CHECK_EQ was introduced in 86.0.4189.0

As I said above, this crash in a controller manner. So this probably doesn't qualify for Security_vulnerability. Feel free to change this if you disagree.

[Empty comment from Monorail migration]

It has also crashed unrelated tabs or prevent navigation to a certain origin I dont know if its possible to detect what origins are being used.

I put a separate https://www.google.com/ tab next to it and it also crashed. on the f.src = "https://www.google.com"; stage

Works with google.com the window length of the separate tab gets changed to 0 when the iframe gets crashed so I think it would be detectable.
I also had a youtube tab that was unaffected so I dont think it crashes randomly.

Im confused is this fixing the issue that changes the src of a crashed iframe force closes the browser.
or my original issue of being able to crash a tab or iframe or a different origin? (or both)

Creis theirs is a different sad face for a crashed iframe.
setTimeout is throttled so the timings may not always be correct however this can be fixed using workers

I think there has been a misunderstanding.
I have checked the forced browser close behavior and it is not related to the bug I am trying to report.
Someone please help me.

Comments 28-33: Please be patient on the replies, as we're all in different timezones.  :)  

Thanks Arthur for repro'ing and narrowing it down! I agree with https://crbug.com/chromium/1169844#c26 that the browser crash is not a security bug (because of the clean crash via CHECK_EQ), and that we should fix it anyway.

It does sound like there's a separate renderer crash (seen at 0:09 in the video in https://crbug.com/chromium/1169844#c25), which we should also investigate.  Arthur or Fergal, do you get crash IDs for that?  If not, maybe it's possible to attach a debugger to the Google renderer process to see why it crashes when the XFO error and second tab share the process.  I suspect that's not security either, but we'll need to take a look to confirm.  I'll leave the view restrictions in place until we get confirmation.

[Monorail components: UI>Browser>Navigation]

> It does sound like there's a separate renderer crash (seen at 0:09 in the video in https://crbug.com/chromium/1169844#c25), which we should also investigate.  Arthur or Fergal, do you get crash IDs for that?

Yes, the renderer crash is:
https://crash.corp.google.com/browse?q=reportid=%27e8b23f91ebff5411%27#4

It points to a CHECK from danakj@ in:
```
RenderFrameImpl::OnDeleteFrame(...)
CHECK(!in_frame_tree_);
```
It has already been investigated in https://crbug.com/chromium/964102 and https://crbug.com/chromium/838348.
I guess by this should fixed by now? +CC danakj@ and dcheng@ in case this reproducer might help?

[Empty comment from Monorail migration]

Daniel is actively working on 838348, it's a very difficult one and is in progress for a while now. We can dupe there if this is the same.

dcheng@ should look at this though first.

> Daniel is actively working on 838348, it's a very difficult one and is in progress for a while now. We can dupe there if this is the same.

There are two CHECK triggered here, one in the browser and one in the renderer process. I believe they are mostly orthogonal. I would prefer to keep them separate. Let's say this one is only about the browser side CHECK and https://crbug.com/chromium/838348 remains about the renderer side check.

Oh ok thanks. From a quick look, it seems like we're grabbing the wrong SiteInstance then when we recreate the error page. Or.. a different SiteInstance.

The RF is crashed so this happens:

  // If a crashed RenderFrameHost must not be reused, replace it by a
  // new one immediately.                      
  if (render_frame_host_->must_be_replaced())   7ff7ad  8 months        fergal
    use_current_rfh = false;

We make a speculative RFH:

    // Check for cases that a speculative RenderFrameHost cannot be used and
    // create a new one if needed.                      
    if (!speculative_render_frame_host_ ||
        speculative_render_frame_host_->GetSiteInstance() !=                    
            dest_site_instance.get()) {

  } else {                      
    // No proxy means that this is a same-SiteInstance subframe navigation. A                  
    // subframe navigation to a different SiteInstance would have had a proxy. A                        
    // main frame navigation with no proxy would have its RenderFrame init                      
    // handled by InitRenderView. This will change with RenderDocument for main                
    // frames.                  
    DCHECK(frame_tree_node_->parent());                
    CHECK_EQ(render_frame_host->GetSiteInstance(),                      
             current_frame_host()->GetSiteInstance());

This comment seems incorrect - or we should have a proxy around, one of the two?

> This will change with RenderDocument for main frames.                

That sounds relevant :)

I dont know how much of this is already known:

When a iframe crashes which can be caused by the checker.location infinite loop or the iframe has a embedded script like [...Array(2**32-1)]
it will crash one tab of the same origin with the same error code as the iframe it seems to not be subdomain depended.

Using x = open("https://google.com"); it will crash it without needing the iframe.

[Comment Deleted]

[Comment Deleted]

Thanks for the investigations so far.

https://crrev.com/c/2658518 has test to reproduce this. I will probably can't spend a lot of time on this today, so if anyone has any insight, please chime in. Otherwise I will dig into it next week.

[Comment Deleted]

This issue seems to contain multiple bugs
URL Spoof (Security)
Origin dependent crash (May help with attacks easier)
Browser crash (Inconvenience)

I think the URL Spoof should be higher priority unless its cause by the same code

I think the URL Spoof bug should be separate issue as this is not in the security bug type.
It seems like I put multiple bugs in the same issue and want to fix the mess.
https://bugs.chromium.org/p/chromium/issues/detail?id=1172690

Yes, please file a different bug for the spoofing, I think the crash is unrelated.

Rather shockingly the repro steps are now

1 a.com has b.com subframe
2 crash subframe
3 navigate subframe to c.com

No errors needed, just 3 different SiteInstances. It's very surprising there's no test that covered this.

https://crrev.com/c/2658518

I'm going to try find out how old this bug is.

Not surprisingly, I broke this.

https://crrev.com/c/2246087

Removing the CHECK seems to solve it but I want to figure out why we thought that CHECK was correct before removing it.

https://crash.corp.google.com/browse?q=expanded_custom_data.ChromeCrashProto.magic_signature_1.name%3D%27content%3A%3ARenderFrameHostManager%3A%3AInitRenderFrame%27#samplereports

shows a steady stream of crashes but I guess at too low a level.

[Empty comment from Monorail migration]

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src/+/542d15330dfd682240e7abc740faa19ce3c8f46e

commit 542d15330dfd682240e7abc740faa19ce3c8f46e
Author: Fergal Daly <fergal@chromium.org>
Date: Tue Feb 09 04:57:18 2021

Fix overly strict CHECK in GetReplacementRoutingId.

If the render frame is live the check is correct, if the render frame
has crashed then there will be a proxy if and only if the SiteInstance
was already present in the frame tree. This means there is nothing we
can assert and the old vs new SiteInstances.

Also a test for this case. It's very surprising that this case was not
already tested. GetReplacementRoutingId just keeps on giving.

Bug: 1169844
Change-Id: Iadb5dcff9c5f470f15cf580374b4ac2dbedb3ff1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2658518
Commit-Queue: Fergal Daly <fergal@chromium.org>
Auto-Submit: Fergal Daly <fergal@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#852082}

[modify] https://crrev.com/542d15330dfd682240e7abc740faa19ce3c8f46e/content/browser/renderer_host/render_frame_host_manager_browsertest.cc
[modify] https://crrev.com/542d15330dfd682240e7abc740faa19ce3c8f46e/content/browser/renderer_host/render_frame_host_manager.cc

[Empty comment from Monorail migration]

Does this fix the crash during the navigation spam as well?

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

> Does this fix the crash during the navigation spam as well?

That is not fixed and is a long-standing issue, that is being tracked in another bug. I don't have the bug number to hand.

As this was labeled "reward-topanel" does that mean some part will get reviewed?

As this was _originally_ reported as a security vulnerability, the bots tagged it for consideration by the VRP panel. But as it's no longer deemed a security bug (per https://crbug.com/chromium/1169844#c26), it won't be considered by the VRP. Adjusting labels appropriately.

https://bugs.chromium.org/p/chromium/issues/detail?id=1169844#c26 seems to only be about to the browser close not the origin depended crashs.
However I understand I have wasted your time sorry for the inconvenience.

hi ndevtk@, per [#61](https://bugs.chromium.org/p/chromium/issues/detail?id=1169844#c61) the crash issue is a known issue and is being tracked for fix in an issue preceding your report.

Does that mean this is a duplicate security bug?

Asking because it would be nice to know if I helped with anything (seems very unlikely)
As the CHECK_EQ fix seems to be for 90 should the information about the other bug be moved from this issue?
It seems like this was a security bug until someone changed the title.

You did help. There were 3 bugs, 2 of them were known before

1 the long-standing renderer crash that you were able to trigger in the iframe, this is not  a security bug as this is an "intentional" crash (CHECK-fail) when a well-understood sequence of events brings us to a state we know we can't recover from.

2 The URL spoof, already reported

3 The browser crash fixed by https://crrev.com/c/2658518. This was new but is also an intentional crash (CHECK-fail). It was known before however, there are no security implications, it's just an unanticipated combination of states of frames and our CHECKing was too strict.

#3 was happening at a low level that had not been noticed and your bug led to it being fixed and I appreciate the report and your help in reproducing it.


 The bug I fixed was the browser crash that occurs

The crashing only when its on a certain domain seems like it could be a small privacy issue if the crashing could be detected.
Apart from that this seems like it could be public (maybe remove the security issue part)

This was explained in https://bugs.chromium.org/p/chromium/issues/detail?id=1169844#c30
Is it also in the other issue?

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

[Empty comment from Monorail migration]

This issue was migrated from crbug.com/chromium/1169844?no_tracker_redirect=1

[Auto-CCs applied]
[Multiple monorail components: Internals>Sandbox>SiteIsolation, UI>Browser>Navigation]
[Monorail mergedwith: crbug.com/chromium/1170298]
[Monorail components added to Component Tags custom field.]