IssueTracker

The new ContextAware API will be available in Activity 1.2.0-alpha08 and is used by Fragment 1.3.0-alpha08 and AppCompat 1.3.0-alpha02 to implement FragmentManager's and AppCompatDelegate's pre-onCreate() logic.

Wait, this can't work as advertised.

FragmentActivity extends ComponentActivity

public FragmentActivity(@LayoutRes int contentLayoutId) {
    super(contentLayoutId);
    init();
}

private void init() {
    addOnContextAvailableListener(new OnContextAvailableListener() {
        // ...
    }
}

ComponentActivity

@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
    // ...
    mContextAwareHelper.dispatchOnContextAvailable(this);
    super.onCreate(savedInstanceState);
    //...
}

1. Call FragmentActivity constructor,
2. which calls ComponentActivity super constructor,
3. which dispatches context available... to noone,
4. and calls platform Activity.onCreate.
5. Bubble up to FragmentActivity constructor and register context listener,
6. which is invoked synchronously but only after platform Activity.onCreate has already been called.

Did I miss something? I'm confused.

Never mind, constructor vs onCreate. :facepalm: Sorry.

Re #8 - the fact that these are different things is indeed exactly why this API exists :)

https://docs.google.com/document/d/1hyftTRyqV7ZJ5s2b_-Q9K6RJdpgedgvKP4vYoTK7i1A/edit?usp=drive_web ([Feedback] Bass Booster)

https://docs.google.com/document/d/1hyftTRyqV7ZJ5s2b_-Q9K6RJdpgedgvKP4vYoTK7i1A/edit?usp=drive_web ([Feedback] Bass Booster)

Sorry I don't have any context on this. I think this 2017 bug was only about some UI changes. The blocking detection logic was done in issue 40084719, maybe some of the folks from that bug would know? japhet@ could you please help triaging this?

cc'ing lbrady@ and shivanisha@ who's team did some work on this code a couple of years ago

Thanks kenrb@! I can confirm that the bug doesn't happen if popups and redirects are allowed on the site in question (on either desktop or Android).

The bug appears specific to the use of OpenURL, which treats the URL in question as browser-initiated and allows privileged URLs. Because the URL comes from the renderer, it should be filtered first. Thanks to dgn@'s link to https://crbug.com/40084719, I discovered the browser-side implementation as well.

• Android: FramebustBlockedMessageDelegate::HandleOpenLink()
• Desktop: FramebustBlockTabHelper::OnBlockedUrlClicked()

It looks like I was wrong in comment #7 and we can't solely set is_renderer_initiated to true, since that also requires setting an initiator origin. Thanks to some suggestions from nasko@ and alexmos@, the fix might involve some combination of:

• Using FilterURL on any URLs passed from the renderer. (This can probably be done quickly.)
• Preserving initiator origin (and any other relevant parameters) in the dialog, supposedly similar to what the popup blocker does, and then treating it as renderer-initiated. (This is probably worth doing, possibly as a followup.)
• Optionally preserving more of the navigation context.

I think we may have also previously discussed changing the OpenURL / LoadURL APIs so that they don't allow privileged URLs by default, although this would be a larger overhaul.

Anyway, now that I know where both the desktop and Android code live (and we've confirmed what the bug is across both platforms), I can probably help with the fix.

Interestingly, there seems to be a test for this case already in FramebustBlockBrowserTest.ModelAllowsRedirection from https://chromium-review.googlesource.com/c/chromium/src/+/755523, but it verifies that you can click through to the chrome:// URLs. I'm guessing that was just an oversight of the risk, without realizing web renderers aren't allowed to trigger navigations to chrome:// URLs (even indirectly).

pmonette@: Can you confirm it's ok to change that test to expect that the user can't proceed to chrome:// URLs, and can only proceed to blocked URLs the renderer would have already been able to navigate to in other circumstances?

I'm working on a first fix in https://chromium-review.googlesource.com/c/chromium/src/+/5973403, by adding FilterURL calls. It looks like that should address both the Android and desktop cases, since they both appear to go through RenderFrameHostImpl::DidBlockNavigation before reaching the respective dialogs.

There's additional cleanup we land after that, but this first CL should resolve the main security concern.

[Navigation triage]

Just adding the Available hotlist to remove this from the untriaged list. The fix is just waiting for owners approval before it can land.

Project: chromium/src
Branch: main
Author: Charlie Reis <creis@chromium.org>
Link:      https://chromium-review.googlesource.com/5973403

Filter any URLs passed to the "redirect blocked" dialogs.

Filter any URLs passed to the "redirect blocked" dialogs. 
 
The framebusting mitigation from https://crbug.com/40084719 can block 
subframes from navigating the main frame cross-origin without a user 
gesture. However, the dialog allows the user to manually proceed to the 
URL if desired. 
 
This URL was not adequately filtered before, allowing chrome:// and 
other privileged URLs to be used even if the renderer could not nomrally 
navigate to them.  This CL adds the necessary filtering, which should 
apply to both the desktop and Android dialogs. 
 
Bug: 375550814 
Change-Id: Icd518a869a06ad982767386d5d7a1528e6179e6c 
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5973403 
Reviewed-by: Patrick Monette <pmonette@chromium.org> 
Reviewed-by: Nate Chapin <japhet@chromium.org> 
Reviewed-by: Andy Paicu <andypaicu@chromium.org> 
Reviewed-by: Liam Brady <lbrady@google.com> 
Auto-Submit: Charlie Reis <creis@chromium.org> 
Commit-Queue: Charlie Reis <creis@chromium.org> 
Cr-Commit-Position: refs/heads/main@{#1377807}

Since https://chromium-review.googlesource.com/5973403 should resolve the security aspects of this report, I'll mark this as fixed. I've filed https://crbug.com/377339178 to track some followup work to make similar issues less likely.

In terms of severity, I looked for examples of similar bugs that allowed navigation to chrome:// and file:// URLs. In general this type of navigation is disallowed because it can be used as a stepping stone for privilege escalation, though no direct harm is likely to happen as a result. In that sense, it's similar to https://crbug.com/40083873, which was considered Low (S3) (even when not requiring a user to click through a warning dialog, like this report). I'll adjust to this to S3 accordingly.

There are some other similar bugs with higher severity, but I think they had larger consequences. For example, https://crbug.com/40092668 was Medium (S2), but it didn't require user interaction and could lead to leaking file contents via extension APIs. In another example, https://crbug.com/40087849 was High (S1) because it allowed loading the file in the initiator's process as well, where it could be leaked. I don't think this bug has the same risks as those, but I'm happy to revise the severity if there are examples where the content might be leaked to the attacker.

Thanks for spotting https://crbug.com/40082800 as another example, rated Medium (S2). It's possible the reward panel could decide this should be Medium, though I'll mention a few considerations there:

• I would say that clicking through a "Redirect Blocked" notification (which warns the user that something may be wrong) is more of a mitigation than clicking a normal link in a PDF. In the PDF case, there are no warnings to the user that something is wrong, and the chrome:// or file:// URL was opened directly.
• That bug was raised from Low to Medium when it was found it affected more cases than just the one reported (here). I'm not sure whether the raise in severity was fully justified there or not, but the broader impact did play into it.
• The reward was actually $2000, and the total amount was only $4000 because it was donated to charity and so Google matched it.

Regarding https://crbug.com/377440449, I think you might be testing in a version that doesn't have the fix yet (currently just 132.0.6820.0 and higher)?

Regarding comment #24, it sounds like you might be looking for ways to leak user information via the bug, which would be super helpful if you found something. The comment cut off at "From a deeper look to find a way to get user information, it", though. Is there any more you can share?

Thanks!

Thank you for the report, Khiem. We appreciate your efforts and reporting this issue to us. In the future, it would much more helpful if your reports were clear and concise explanations of the security issue and impact to a user, following feedback we have conveyed in other bug reports and over email.

This bug has been closed for more than 14 weeks. Removing issue access restrictions.