Issue metadata
Sign in to add a comment
|
Security: ZDI-CAN-5327] # Sandbox Escape from renderer bug #1: wrong fix of CVE-2016-5197 |
||||||||||||||||||||||
Issue descriptionThis template is ONLY for reporting security bugs. If you are reporting a Download Protection Bypass bug, please use the "Security - Download Protection" template. For all other reports, please use a different template. Please READ THIS FAQ before filing a bug: https://chromium.googlesource.com /chromium/src/+/master/docs/security/faq.md Please see the following link for instructions on filing security bugs: https://www.chromium.org/Home/chromium-security/reporting-security-bugs NOTE: Security bugs are normally made public once a fix has been widely deployed. VULNERABILITY DETAILS After we got code execution in Samsung Internet's render process, it's still heavily sandboxed and we will need an escape. Here we use an IPC bug to start arbitrary activity in unsandboxed process to escape sandbox. The bug comes from an incomplete fix of CVE-2016-5197, which we used in last year's mobile pwn2own. Let' see the original fix: https://chromium.googlesource.com/chromium/src.git/+/abd993bfcdc18d41e5ea0f34312543bd6dae081e%5E%21/#F0 @@ -144,6 +148,14 @@ // Perform generic parsing of the URI to turn it into an Intent. try { intent = Intent.parseUri(intentUrl, Intent.URI_INTENT_SCHEME); + + String scheme = intent.getScheme(); + if (!scheme.equals(GEO_SCHEME) && !scheme.equals(TEL_SCHEME) + && !scheme.equals(MAILTO_SCHEME)) { + Log.w(TAG, "Invalid scheme for URI %s", intentUrl); + return; + } + This patch tries to enforce scheme on incoming string. However it can be trivially bypassed since the intent resolve process does not depend on scheme, component part is the key. Just adding scheme=geo in the intent string will bypass this fix. So here we use the following payload: intent:#Intent;scheme=geo;package=com.samsung.android.email.provider;component=com.samsung.android.email.provider/com.samsung.android.email.ui.messageview.MessageFileView;type=application/eml;S.AbsolutePath=/sdcard/Download/test.eml;end At the begining of the exploitation we download EML files to /sdcard/Download, which does not require user interaction, and the file path can be predicted. We coded this path in the intent string, to start our second stage sandbox escape: attacking the Samsung Email application. VERSION Chrome Version: [x.x.x.x] + [stable, beta, or dev] Operating System: [Please indicate OS, version, and service pack level] REPRODUCTION CASE Reproduced / used at Mobile Pwn2Own 2017 FOR CRASHES, PLEASE INCLUDE THE FOLLOWING ADDITIONAL INFORMATION Type of crash: [tab, browser, etc.] Crash State: [see link above: stack trace *with symbols*, registers, exception record] Client ID (if relevant): [see link above]
,
Jan 23 2018
twellington: Can you PTAL? Thanks.
,
Jan 23 2018
I ended up adding the scheme check in issue 659477 because tedchoc@ was OOO and mariakhomenko@ was out sick. If the scheme check is not correct, what is the recommended fix?
,
Jan 23 2018
The referenced code has since been deleted [i], so the attack path is either no longer valid or has changed since issue 659477 . What version of Chrome was used for this exploit? [i] The code snippet in the original bug report was moved to ViewAndroidDelegate in https://codereview.chromium.org/2708703004 and was removed in https://chromium.googlesource.com/chromium/src/+/b7d91597c0438dc21291f862ce0dd920abd11bc4
,
Jan 23 2018
The code was deleted in M-59. If the exploit works in a newer version, then it's a different problem and it would help if we had steps to reproduce. Is the intent embedded in the webpage as an intent URL? That would go through ExternalNavigationHandler, but we always clear out component in those intents...
,
Jan 23 2018
twellington: The original report is at b/68767524. The report mentions multiple bugs, and says one of them affects all versions prior to Chrome 62, but it doesn't say which version this one affects.
,
Jan 23 2018
Is there someone who can retest these exploits and figure out if we're still affected and provide a way for us to reproduce? There's not a lot of data in that bug especially since it mostly talks about a completely deleted code path.
,
Jan 23 2018
I poked Samsung since the information was disclosed to them (as per Pwn2Own rules). Will see if they respond. You can also ask directly on b/68767524 if there is specific information you want from them.
,
Jan 24 2018
,
Jan 24 2018
,
Jan 25 2018
,
Jan 25 2018
Closing this out as obsolete since the code path has been deleted. From the buganizer "For [ZDI-CAN-5327], we didn't receive any more details for this issue, but we believe the researchers were using an older version of Chrome, which was vulnerable. We confirmed that this vulnerable code was removed in the latest Chrome and we also believe this issue is now obsolete."
,
May 4 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 awhalley@google.com
, Jan 23 2018