Mark additional AppleScript file extensions as dangerous
Reported by
vladimir...@gmail.com,
Jun 6 2018
|
|||||||
Issue descriptionVULNERABILITY DETAILS Attacker could trick user to silently execute downloaded applescript file with user-level privilege. Attack scenario: 0.Open `exploit.html` 1.Open new window with `applescript:` url. this will prompt user to open Script Editor application. (skip this step, if we've already got this permission) 2.User accepts navigation to `applescript:` and grants access to start script editor. User have to click on the checkbox “Always open these type of links in the associated app”. 3.Script editor opens in background, because of closing tab (Chrome gets focus again, Script Editor is only visible in Dock for now) 4. Download `exploit.applescript` file. File will be downloaded, because danger level for `.applescript` is not `ALLOW_ON_USER_GESTURE`. [download protection bypass] 5. At this point, let's assume that user opens file using downloads toolbar. 6. As of now, file is opened, and we need to execute it. in script editor, "Run" command has a shortcut "cmd + R" 7. When Script editor opens with our `exploit.applescript`, Chrome lost focus and exploit file content could became visible to user in Script Editor. [but it won't be visible, step 8] 8. We could make window focused again calling `alert()`. In this case, `exploit.html` will be focused again. Script Editor has never shown. 9. At this point, we have Script Editor with exploit inside (moreover, user didn't see it) and focused `exploit.html` in Chrome. 10. Now we need to trick user into pressing Cmd + R while navigating to `applescript:` url. It could be possible with a technique similar to https://bugs.chromium.org/p/chromium/issues/detail?id=252888, when user starts pressing specific keys in browser, but they get evaluated in non-browser windows 11. At this point user has to press Cmd and then press R. on Cmd keypress, we open `applescript:` url. Script Editor becomes focused, keypress for Cmd is interpreted as keypress on Script Editor and keydown for R will run Script Editor's shortcut "Cmd+R", e.g. "Run". (in attached exploit it's required to press CMD and hit "R" twice) 12. Script Editor runs our `exploit.applescript`. Problems: - User has to allow `applescript:` protocol by default. "Open "Script Editor"" is a default answer in modal, so it's possible to trick user again into pressing "Enter". The problem is that user should allow `applescript:` open Script Editor by default. - User has to open file using downloads toolbar: But file is treated as a non-dangerous. Additionally, Script Editor is a default app for .applescript/.scpt/.scptd files, so the only require action from user - press file's tab in "downloads" toolbar. - User has to press a specific shortcut(Cmd + R ) after navigation to `applescript:`. That's not a problem too. Cmd + R is a well-known shortcut. - Exploit doesn’t work in fullscreen mode (i.e. when Chrome’s window is fullscreen, not element.requestFullScreen()). IMPACT: - Attacker could trick user to run applescript file and execute downloaded with user-level privilege from Chrome. Other browsers: Safari shows alert every time navigation to `applescript:` url happens. TL;DR, it's not possible to silently open Script Editor in Safari. Mozilla: looks like there is no silent auto download in mozilla for .applescript files. So it will not work too (probably). VERSION Chrome Version: 67.0.3396.62 Stable + 69 Canary Operating System: macOS 10.13.4 17E202 x86_64 REPRODUCTION CASE PoC (exploit, not test case) attached.
,
Jun 6 2018
+dtrainor
,
Jun 7 2018
Yup, confirmed this on 69.0.3451.0 macOS 10.13.5. Should we mark .scpt and .scpt as dangerous as well as .applescript?
,
Jun 7 2018
Yup. Based on https://chromium.googlesource.com/chromium/src/+/master/chrome/browser/resources/safe_browsing/README.md, these file types would qualify for DANGEROUS + DISALLOW_AUTO_OPEN. Perhaps the danger level could be lowered to ALLOW_ON_USER_GESTURE if there's a use case for folks frequently downloading these files from a trusted source.
,
Jun 7 2018
I'd be quite surprised if people often download these file types often. DANGEROUS + DISALLOW_AUTO_OPEN seems like a good starting point to me. Given that the the exploit scenario is very-high-touch social engineering that would work regardless of what Chrome can do, I think marking the additional extensions as dangerous is all we can do about this bug. I'm going to track it as a security feature request, not as a vulnerability.
,
Jun 7 2018
,
Jun 7 2018
Do we want to give the same treatment to .osas and .seplugin ? I don't know enough to make a call.
,
Jun 7 2018
Yes, and .osax too.
,
Jun 7 2018
OK, I'll cover those in a second CL. The first is close to landing.
,
Jun 7 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b3bd07e30c8297bd582dafe39c574a38b1b42361 commit b3bd07e30c8297bd582dafe39c574a38b1b42361 Author: Chris Palmer <palmer@chromium.org> Date: Thu Jun 07 21:44:42 2018 Mark AppleScript downloads as dangerous. Bug: 850261 Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation Change-Id: I7269b851c9689f7a656bff594871ea873e7b51f8 Reviewed-on: https://chromium-review.googlesource.com/1091143 Reviewed-by: Varun Khaneja <vakh@chromium.org> Reviewed-by: Asanka Herath <asanka@chromium.org> Reviewed-by: David Trainor <dtrainor@chromium.org> Commit-Queue: Chris Palmer <palmer@chromium.org> Cr-Commit-Position: refs/heads/master@{#565424} [modify] https://crrev.com/b3bd07e30c8297bd582dafe39c574a38b1b42361/chrome/browser/resources/safe_browsing/download_file_types.asciipb [modify] https://crrev.com/b3bd07e30c8297bd582dafe39c574a38b1b42361/components/download/internal/common/download_stats.cc [modify] https://crrev.com/b3bd07e30c8297bd582dafe39c574a38b1b42361/tools/metrics/histograms/enums.xml
,
Jun 9 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/da99ff2768bb5cb3fd913b260f6c5c67bf1784f5 commit da99ff2768bb5cb3fd913b260f6c5c67bf1784f5 Author: Chris Palmer <palmer@chromium.org> Date: Sat Jun 09 01:59:41 2018 Mark additional AppleScript file extensions as dangerous. Bug: 850261 Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation Change-Id: I54fd2e42f935a941b27bc3e58503ad2c80568a86 Reviewed-on: https://chromium-review.googlesource.com/1091881 Reviewed-by: Varun Khaneja <vakh@chromium.org> Reviewed-by: David Trainor <dtrainor@chromium.org> Reviewed-by: Asanka Herath <asanka@chromium.org> Commit-Queue: Chris Palmer <palmer@chromium.org> Cr-Commit-Position: refs/heads/master@{#565816} [modify] https://crrev.com/da99ff2768bb5cb3fd913b260f6c5c67bf1784f5/chrome/browser/resources/safe_browsing/download_file_types.asciipb [modify] https://crrev.com/da99ff2768bb5cb3fd913b260f6c5c67bf1784f5/components/download/internal/common/download_stats.cc [modify] https://crrev.com/da99ff2768bb5cb3fd913b260f6c5c67bf1784f5/tools/metrics/histograms/enums.xml
,
Jun 9 2018
I'm not sure why this report was qualified only as "security feature request" while comparably similar reports on download bypass protection were marked as valid and rewarded: https://bugs.chromium.org/p/chromium/issues/detail?id=600907: .AS, .CPGZ, .PAX, .XIP formats https://bugs.chromium.org/p/chromium/issues/detail?id=600908: .mpkg This attack scenario could be considered as a more dangerous variation of download protection bypass that could lead to downloaded script execution. I'd like to ask to reconsider this decision.
,
Jun 11 2018
#13: Thanks for raising this point. The exploit scenario seems more convoluted than usual, with significantly more human interaction required for success than usual. (Compare e.g. a straightforward .EXE exploit.) That's why I set it to Type=Feature. But, that could be wrong. +awhalley as the decider in these matters.
,
Jun 11 2018
,
Jun 11 2018
Thanks for the report. We changed the terms of the Download Protection VRP earlier and under the new terms, this report does not qualify for a reward: "The extension of the binary file must be one of those that Chrome already tracks. This list can be found here: download_file_types.asciipb" Source: https://www.google.com/about/appsecurity/chrome-rewards/index.html#rewards Example reported issue: https://bugs.chromium.org/p/chromium/issues/detail?id=771469
,
Sep 18
Hi Chrome Team, I've made a deeper research on default protocol handlers in macOS some time ago. And accidentally found CVE-2015-7007[1]. That's a similar issue discovered in Safari that allows to run AppleScript with `applescript://` protocol handler. Additionally, the report declares that `applescript://` allows to insert malicious code into Script Editor view with `com.apple.scripteditor` set as hostname and `script=<script>` as query for `applescript://` protocol. I've disassembled the Script Editor on the latest macOS. And I confirm that this flaw still exists. `applescript://com.apple.scripteditor?script=display alert '1'` opens ScriptEditor.app with `display alert '1'` as contents. In the original report, I said that this bug is reproducible only in Chrome due to strange rules applying to windows focus. AFAIR, FF and Safari aren't vulnerable to this. Actually, after so long time passed, I agree that it's just a ~~dumb~~ low-priority bug, due to a high level of user assistance(i.e. file opening). However, the behavior of Chrome's window re-focusing with `alert()` + `applescript://<host>?script=<script>` seems like a bug, isn't it? Current attack scenario: 1. Open ScriptEditor with attacker's script. Requires navigation to `applescript://` protocol => confirmation from a user. 2. Hide ScriptEditor.app and re-focus Chrome's window using `alert()` 3. Init navigation to `applescript://` again and trick the user into pressing Cmd+R. This attack scenario is more realistic than previous. Additionally, that means marking AppleScript files as dangerous didn't change almost anything. Anyway, I decided to publish it here. > My apologies for the report I've published originally with a loud title (like "RCE+SBX") :( > I've realized my mistakes, hah [1] - https://www.rapid7.com/db/modules/exploit/osx/browser/safari_user_assisted_applescript_exec [Exploit for CVE-2015-7007] - https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/osx/browser/safari_user_assisted_applescript_exec.rb |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by palmer@chromium.org
, Jun 6 2018Components: UI>Browser>Downloads UI>Browser>Navigation
Labels: Security_Impact-Stable OS-Mac
Owner: rsesek@chromium.org