New issue
Advanced search Search tips

Issue 873807 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Sep 11
Cc:
Components:
EstimatedDays: ----
NextAction: 2018-09-06
OS: iOS
Pri: 1
Type: Bug-Security



Sign in to add a comment

iframe/csp sandbox escape

Reported by s.h.h.n....@gmail.com, Aug 13

Issue description

Steps to reproduce the problem:
1.  Go to https://test.shhnjk.com/sandbox_bypass.php
2. Click any link

What is the expected behavior?
popup should still be inside the sandbox

What went wrong?
Patch of  issue 822518  has following code as part of fix
https://chromium.googlesource.com/chromium/src.git/+/eee00efa1b51ac9b3f1ae4500f1d77e901ab30ab/ios/chrome/browser/app_launcher/app_launcher_tab_helper.mm#172
```
if (!request_info.target_frame_is_main) {
    request_status = ExternalURLRequestStatus::kSubFrameRequestAllowed;
    // Don't allow navigations from iframe to apps if there is no user gesture
    // or the URL scheme is for Chrome app.
    if (!request_info.has_user_gesture || HasChromeAppScheme(request_url)) {
      request_status = ExternalURLRequestStatus::kSubFrameRequestBlocked;
    }
  }
```

I'm not quite sure what `request_info.target_frame_is_main` checks, but if the check is what the word suggest, there are 2 possible bypasses.

1. Change target to something other than "_self"
2. Bypass CSP sandbox, since it can be a main frame

I know getting sandbox status is pain in iOS, but proper fix is to check if document is sandboxed. Or disable navigation to chrome app scheme from webpage.

Did this work before? N/A 

Chrome version: 68.0.3440.083  Channel: stable
OS Version: 11.4.1
Flash Version:
 
Components: Mobile>Intents
Labels: Security_Severity-Medium Security_Impact-Stable
Owner: mrefaat@chromium.org
Status: Assigned (was: Unconfirmed)
mrefaat@, mind taking a look at this? Since you're the owner of a similar issue   issue 822518  
Project Member

Comment 2 by sheriffbot@chromium.org, Aug 14

Labels: M-69 Target-69
Project Member

Comment 3 by sheriffbot@chromium.org, Aug 14

Labels: -Pri-2 Pri-1
Project Member

Comment 4 by sheriffbot@chromium.org, Aug 28

mrefaat: Uh oh! This issue still open and hasn't been updated in the last 14 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
NextAction: 2018-09-06
This is part of the investigation being done on : https://bugs.chromium.org/p/chromium/issues/detail?id=852489

i was on vacation last month, Going to update this bug soon.
Regarding escaping the sandbox using target= any other value than self. WKWebView will block the navigation it self before it reaches chromium code.
The reason why there was a sand box breakage on the original  crbug.com/822518  was that 
WKWebview didn't know that the URL is going to be opened in a new window/tab "as the target is self and it doesn't check the URL type"
 

Cc: eugene...@chromium.org
The NextAction date has arrived: 2018-09-06
Status: WontFix (was: Assigned)
based on comment#6 i'm closing this bug, please open it again if there is any question or update to the current behavior.
What if value is _self? why does it not escape CSP sandbox?
Project Member

Comment 11 by sheriffbot@chromium.org, Dec 18

Labels: -Restrict-View-SecurityTeam allpublic
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