New issue
Advanced search Search tips
Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Oct 31
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug-Security



Sign in to add a comment
link

Issue 891697: Security: macOS: the option to "Allow JavaScript From Apple Events" can easily be activated by malicious apps.

Reported by andr...@hegenberg.me, Oct 3

Issue description

VULNERABILITY DETAILS
Google Chrome has recently disabled triggering JavaScript using Apple Events on macOS by default - which was a very good idea. As a user I expected this to protect me from attacks based on malicious apps that send Apple Events. However it turns out that it is pretty easy to bypass because the setting can be enabled by malicious apps easily.

There are at least two different situations:
* If the attacking app has access to the macOS Accessibility API enabled it can just enable the setting in Google Chrome by triggering the menubar item View => Developer => Allow JavaScript from Apple Events.

* If the attacking app doesn’t have access to the macOS Accessibility API it can just assign a keyboard shortcut (using the functionality provided in System Preferences => Keyboard => Shortcuts => App Shortcuts) to the Google Chrome menubar item View => Developer => "Allow JavaScript from Apple Events" using two commands that were completely unsecured until macOS Mojave:

defaults write -g NSUserKeyEquivalents -dict-add "Allow JavaScript from Apple Events" "@~^x"

defaults write com.apple.universalaccess "com.apple.custommenu.apps" -array-add NSGlobalDomain

This shortcut can then be triggered using Apple Events easily. On macOS Mojave this doesn’t work anymore because com.apple.universalaccess is now secured. However even on Mojave this works if the user has added any other shortcut globally in System Preferences => Keyboard => Shortcuts => App Shortcuts before. It is easy for an attacker to achieve this by tricking the user to add a shortcut there.

I think there may also be another way to trigger the menu item on Mojave, but I will need to do some more testing to verify this.

In general I think this menu item should be secured by an extra (secured) alert (like in Safari) or be moved to the Chrome settings page instead.


VERSION
Chrome Version: Tested on Version 70.0.3538.35 (beta) and on 69.0.3497.100 (stable release)

Operating System: tested on macOS 10.13.6 and macOS 10.14.0

REPRODUCTION CASE
See the attached Apple Scripts. They can be executed using the Apple Script Editor for testing.

The script „ExecuteJavaScriptUsingKeyboardShortcut_Source“ assigns a keyboard shortcut to the Chrome menu item „Allow JavaScript from Apple Events“. Then it triggers the keyboard shortcut to enable JavaScript execution. It works without any permissions until (including) macOS High Sierra.

The script “ExecuteJavascriptUsingAccessibility_Source“ directly triggers the menubar item using Apple Script, but it requires Accessibility access for the executing app. This works on Mojave too.
 
ExecuteJavaScriptUsingKeyboardShortcut_Source.applescript
821 bytes Download
ExecuteJavascriptUsingAccessibility_Source.applescript
519 bytes Download

Comment 1 by mea...@chromium.org, Oct 4

Owner: markchang@chromium.org
Status: Assigned (was: Unconfirmed)
Thanks for the report.

> * If the attacking app has access to the macOS Accessibility API enabled it can just enable the setting in Google Chrome by triggering the menubar item View => Developer => Allow JavaScript from Apple Events.

Please note that local attacks are outside of our threat modal. Chrome cannot defend against a malicious app that can use OS APIs to control Chrome's settings.

My understanding is that this was intended as a hardening measure and not an outright ban. 

markchang: Can you please decide what to do here (wontfix or not)?

Comment 2 by andr...@hegenberg.me, Oct 4

But Chrome does a lot to prevent local attacks already. (E.g. not allowing automatic installation of extensions). Allowing arbitrary Java Script execution defeats the purpose of almost all other local security measures you have taken.

The problem is that a completely unprivileged app, running just with user permissions, can run arbitrary Java Script on any website when using the "keyboard shortcut based approach" I described. Pre Mojave there is no notification to the user at all about something running Java Script on a website when doing this.

I understand that if the user gives Accessibility permissions to an app, it's already too late. But a unprivileged app should not be able to do this. 

Safaris approach is to show at least an alert before enabling this, that alert can not be confirmed using programmatically created events.

Comment 3 by mea...@chromium.org, Oct 5

Cc: palmer@chromium.org rsesek@chromium.org
Components: Internals>PlatformIntegration
Labels: Security_Severity-Low Security_Impact-Stable OS-Mac
We take measures to prevent local attacks, but we can't fully defend Chrome from a malicious user or software running on the same machine. https://chromium.googlesource.com/chromium/src/+/lkgr/docs/security/faq.md#Why-arent-physically_local-attacks-in-Chromes-threat-model gives more details on this.

In this example, the app is no longer unprivileged if it's granted Accessibility permission, though. That said, the Safari approach sounds simple and we could try something like that.

palmer, rsesek: Any thoughts on this?

Comment 4 by palmer@chromium.org, Oct 5

Cc: -palmer@chromium.org kerrnel@chromium.org
Booping this to kerrnel, who is our macOS expert.

Comment 5 by andr...@hegenberg.me, Oct 5

Only the first described approach requires accessibility. The other approach works without any privileges before Mojave and even on Mojave under the described circumstances. The only requirement is that the app is not sandboxed.

I believe this is a pretty big security issue because Chrome for many users is the main app and handles a lot of sensitive data.
The problem is not that Chrome can't protect from local attacks in general but that the ability to run
 Java Script from unpriviledged apps destroys the operating systems security measures. It would allow to install keyloggers and steal private data in a very sensitive context.

Comment 6 by kerrnel@chromium.org, Oct 5

rsesek@, you were involved in the Apple Events restrictions, right? WDYT?

Comment 7 by kerrnel@chromium.org, Oct 5

Also doesn't macOS mojave require users to go into settings manually to allow the accessibility permission?

Comment 8 by sheriffbot@chromium.org, Oct 6

Project Member
Labels: Pri-2

Comment 9 by markchang@chromium.org, Oct 8

I read the attack vector being mostly about pre-mojave, since the a11y API is not protected.

Comment 10 by andr...@hegenberg.me, Oct 8

The problem is that any unpriviledged app can assign a keyboard shortcut to any menu item in macOS. This includes the Chrome menu item which enables Java Script execution via Apple Script. It can then trigger the shortcut using Apple Script/Apple events and then execute arbitrary JavaScript in Chrome. See the ExecuteUsingKeyboardShortcut script I attached in the initial post.

The other example I posted (which was using Accessibility) was just meant for clarification. Accessibility permissions are NOT necessary to execute JavaScript in Chrome.

(on Mojave it got a bit harder to assign a keyboard shortcut to the menu item, but it is still possible)

Comment 11 by andr...@hegenberg.me, Oct 8

But I definitely agree it is mostly pre-Mojave because there the user won't notice anything (Especially because sending keystrokes on Mojave got harder).

Still, I think a significant number of users will continue to use Chrome on older macOS versions.

Comment 12 by andr...@hegenberg.me, Oct 8

Sorry one more comment:
I just noticed that (pre-Mojave) executing Java Script is also possible by having an app "type" the Java Script into the address bar. Even if the "Allow Apple Events From Java Script" option is disabled.
If that's the desired behavior it doesn't make sense to fix the issue because any app that could use the Apple Events could also type text into the address bar (pre-Mojave).

Just note that Safari has much better security in this area. It doesn't allow Java Script from the address bar by default and it doesn't allow Java Script from Apple Events by default. In Safari both must explicitly be enabled and can not be enabled using programatically generated events.

Comment 13 by rsesek@chromium.org, Oct 30

Cc: ellyjo...@chromium.org markchang@chromium.org
Owner: rsesek@chromium.org
Catching up on email post-OOO.

Assigning a keyboard shortcut to the menu item and then invoking it is pretty novel - we should try to defend against that because it shouldn't be hard to do. I was wondering if the setting were to move into chrome://settings if that would be sufficient, but I suspect that a script could navigate to chrome://settings and then simulate clicks/tab key navigation to enable it.

I think we can partially protect the menu item by doing a few things:

- Checking the CGEventGetIntegerValueField(…, kCGEventSourceUnixProcessID) of the event when handling the menu item action
- Blocking the action if there's a key equivalent associated with the menu item (or somehow determining that it was a synthetic key event)

C.f. https://objective-see.com/talks/Wardle_SyScan2018.pdf

However, comment #12 about typing in javascript navigations by sending the key events to the Omnibox would indeed bypass this altogether. That sounds like a different issue, though. Could you file a new bug for that?

Comment 15 by rsesek@chromium.org, Oct 31

Labels: M-72
Status: Fixed (was: Assigned)
I split out the report in #12 to issue 900654 (so no need to file a separate bug as I asked in #13).

The original report should be fixed by #14 though.

Comment 16 by sheriffbot@chromium.org, Nov 1

Project Member
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify

Comment 17 by awhalley@chromium.org, Nov 5

Labels: reward-topanel

Comment 18 by awhalley@chromium.org, Nov 12

Labels: -reward-topanel reward-unpaid reward-500
*** Boilerplate reminders! ***
Please do NOT publicly disclose details until a fix has been released to all our users. Early public disclosure may cancel the provisional reward. Also, please be considerate about disclosure when the bug affects a core library that may be used by other products. Please do NOT share this information with third parties who are not directly involved in fixing the bug. Doing so may cancel the provisional reward. Please be honest if you have already disclosed anything publicly or to third parties. Lastly, we understand that some of you are not interested in money. We offer the option to donate your reward to an eligible charity. If you prefer this option, let us know and we will also match your donation - subject to our discretion. Any rewards that are unclaimed after 12 months will be donated to a charity of our choosing.
*********************************

Comment 19 by awhalley@google.com, Nov 12

Cc: awhalley@google.com
Hi andreas@, the Chrome VRP panel decided top award $500 for this bug, thanks! A member of our finance team will be in touch to arrange payment. Also, how would you like to be credited in Chrome release notes?

Comment 20 by andr...@hegenberg.me, Nov 12

Oh that is very nice, thank you!
If you want to credit me you can use: "Andreas Hegenberg (folivora.AI GmbH)"

Comment 21 by awhalley@google.com, Dec 3

Noted, thanks!

Comment 22 by awhalley@google.com, Dec 3

Labels: -reward-unpaid reward-inprocess

Comment 23 by awhalley@google.com, Jan 28

Labels: Release-0-M72

Comment 24 by awhalley@chromium.org, Jan 28

Labels: CVE-2019-5780 CVE_description-missing

Comment 25 by sheriffbot@chromium.org, Feb 7

Project Member
Labels: -Restrict-View-SecurityNotify 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

Comment 26 by awhalley@chromium.org, Today (5 hours ago)

Labels: -CVE_description-missing CVE_description-submitted

Sign in to add a comment