Thanks for the report!

creis@ -- Can you weigh in on Chrome's inconsistent blocking of navigation to filesystem: URIs?

Inside BlockedWindowParams::CreateNavigateParams, we ask the render process to filter out URLs that shouldn't be navigable from the content process:

  web_contents->GetRenderProcessHost()->FilterURL(false, &popup_url);

That, in turn, treats "filesystem:" as a legal target for navigation because tabs are allowed to navigate to filesystem URLs:

  ChildProcessSecurityPolicyImpl::ChildProcessSecurityPolicyImpl() {
    // We know about these schemes and believe them to be safe.
    // ...
    RegisterWebSafeScheme(url::kFileSystemScheme);

... that in turn implies that allowing tab processes to navigate to filesystem:-scheme URLs is okay. Notably, we also permit navigation to such URLs by drag/drop of the URL to the tab or the content area of a different tab (because the same filters get applied).

In contrast, however, if there's a <a href="filesystem:..."> URL on a page, clicking it gets blocked with a notice in the console: 

      "Not allowed to load local resource: filesystem:...."

So we're definitely handling filesystem:// URLs inconsistently in these different codepaths.

Nick is actively working on some filesystem URL security issues, so maybe he can help triage this one.

Yes, sounds like Nick reported this last week in issue 647839, and he has some thoughts on it.

Hello again,
don't know if you already noticed, but I forgot to mention the same goes for blob: URIs.

This issue is a security regression. If you are not able to fix this quickly, please revert the change that introduced it.

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

Regarding comment #6: Yes, thanks. #647839 actually is exactly that issue, and it also mentions the problem for filesystem: URIs; these bugs are basically duplicates. I think "filesystem:" is probably more interesting a vector as blob: URIs seem more likely to be short-lived / transient.

Re #8: I'm not convinced this counts a regression, modulo the fact that filesystem: and blob: probably weren't supported in Chrome 1.

Fixing labels; Security_Impact-Head was assigned in error.

The attack as described seems mostly an XSS attack on web.telegram.org, that makes incidental use of how it employs filesystem URLs. Telegram.org puts itself in the same danger using the filesystem api, as it would if it were hosting user-uploaded html files on its web server.

It also relies on whateverSequencialID being guessable, or interceptable, by evil.attacker.

The attack using blob URLs would seem much harder to pull off, since the blob URLs ought to be unguessable by construction.

However, I agree that the behavior around popups is a security sensitive bug that should be fixed. The URL filtering should work identically, regardless of whether the popup blocker UI gets involved.

Assigning this to meacer, due to similarity with 647839 and due to proposals to do wholesale blocking of filesystem: navigations.

meacer: Uh oh! This issue still open and hasn't been updated in the last 17 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

meacer: Uh oh! This issue still open and hasn't been updated in the last 31 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

meacer/elawrence: can we just dupe this with issue 647839 if they are the same root cause? Thanks!

@andrea.palazzo: I'm unable to reproduce this issue. Here is what I have:

<script>
function popup() {
  window.open("filesystem:http://localhost:5432/evil.html", "", "_blank");
}
</script>
<body onload="setTimeout(popup, 1500)"></body>

Clicking on the filesystem link in the popup blocker UI opens filesystem:http://localhost:5432/evil.html which results in a load error.

Are you able to still reproduce? Thanks.

@andrea.palazzo: can you still reproduce this issue? Otherwise I'll mark this as WontFix; please re-open it if you find it's still a problem. :)

Sorry guys, I must have missed the previous e-mail; I can still reproduce the issue on 58.0.3029.96 Windows 64bit, is there a specific version I should retest it on?

Also, I noticed that the same result is achievable by forcing a user to right click and open the link in a new tab, which I believe is not consistent with the restrictions applied to other local URIs (i.e. file://). Is that an intended behavior?

Thanks,
Andrea

To summarize the bug:
1. telegram stores attacker controlled, untrusted content in a filesystem URL.
2. evil.com tries to open this filesystem URL in a popup and the popup blocker blocks it.
3. However, filesystem URLs are linkified and clickable in the popup blocker. When the user clicks on this link, it results in a browser initiated navigation which does not get blocked.

The popup blocker uses chrome::Navigate in PopupBlockerTabHelper::ShowBlockedPopup(), and even though popup->params.is_renderer_initiated is true, I see a browser initiated navigation instead (needs to be confirmed). 

But the bigger problem is (1) which is akin to an XSS as nick pointed earlier. The popup blocker bug itself is low severity.

If we can confirm that the popup blocker initiates a browser-initiated navigation, then this bug isn't related to 647839 which is concerned with renderer initiated navigations as far as I can tell.

nick: Can I assign this to you to confirm my observations in #23? 

Does the fix in  Issue 811558  also fix this one?

meacer@ / comment 24: Nick is on paternity leave.  Can you find a way to make progress without him?  alexmos@ may be able to answer fileystem: questions as well, if needed.

This is indeed fixed by  bug 811558 : The UI still shows filesystem URL, but clicking on it just loads an empty page with a "Not allowed to navigate to filesystem URL: ..." message in the console. I confirmed this with a bisect as well.

Given that, I'm duping this into  bug 811558 , but if anyone thinks there is more work to be done here (e.g. scrubbing the filesystem URL from the UI), please feel free to reopen.

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