Presence of Scroll Reverser triggering additional security dialogs

[Ino Detelić]

Sometimes on Safari password fields when it asks to use Keychain stored passwords, this appears:

(this is using Safari Technology Preview, but it happened to me several times with normal Safari)
Is this normal?

[Nick Moore]

I haven't seen that before, thanks for reporting it. It should be harmless to add Scroll Reverser to the Accessibility list though.

[Florian Fittschen]

Hi, the same thing happens for me, when I copy certificates between keychains and when SourceTree tried to access information stored in the Keychain (see attached screenshots).

Sadly, I can't copy the certificates and SourceTree can't access the information without entering the password in the Scroll Reverser dialog...

This is very mysterious and someone should look into that!

[Zorn]

Adding Scroll Reverser to the Accessibility list should fix this (drag the app into the list). Let me know.

[MoonShotDev]

The point is, WHY is Scroll Reverser asking to "control my computer" by FORCING its users to add it to the macOS accessibility list? Apple specifically states:
"Be cautious and grant access only to apps that you know and trust. If you give apps access to your Mac, you also give them access to your contact, calendar, and other information, and are subject to their terms and privacy policies, and not the Apple Privacy Policy. Be sure to review an app’s terms and privacy policy to understand how it treats and uses your information."
Hey, I like Scroll Reverser and have been using it. But it works perfectly fine WITHOUT granting it the power to control my computer. So I ask again, WHY does it sneakily request Jedi privileges - privileges that may allow it to access all my files with the possibility of network data transfer - for a tiny little utility applet? Makes no sense, unless....

I just uninstalled it. I need to install some legit printer driver software and this is blocking me from doing that because I get the same dialog as everyone else--It appears Scroll Reverser is "stuck in the queue" and blocking me from installing my other software unless I grant Scroll Reverser God-like access to my computer first. This situation sucks. Someone needs to fix it.

I'll be happy to reinstall it again later if this chicanery is removed, especially since it works just fine without fully controlling my mac.

[Nick Moore]

I can't tell you why as I really don't know.

Scroll Reverser has no code to interact with the keychain and it does not explicitly request any privileges.

My best guess is this: Scroll Reverser inserts itself into the macOS Event stream using an Event Tap. It receives scrolling and gesture events and modifies the scrolling events when necessary to reverse them. Perhaps this tap and/or the modified scrolling events are somehow interacting with the security subsystem in some way when running alongside SourceTree. But I'm not expert enough to know how.

I suggest to review the Scroll Reverser source code (it is really quite short) and build the app yourself from source, should you have have any concerns as to its integrity.

[Zorn]

Being added to the accessibility list does things like allowing an app to intercept and send keyboard and mouse input to apps running as an administrator. It is necessary, and you are overly paranoid. This is an open-source project. There's nothing to indicate anything malicious going on.

[Levi Cameron]

The point is, WHY is Scroll Reverser asking to "control my computer" by FORCING its users to add it to the macOS accessibility list?

I'll be happy to reinstall it again later if this chicanery is removed, especially since it works just fine without fully controlling my mac.

ScrollReverse hooks into system events using CGEventTapCreate in MouseTap start. Elevated permissions are required to do this because it could alter the behaviour of other applications without the user being aware (eg user goes to click on a "Deny" button but a devious application intercepts the click and injects an event to move the mouse to "Accept" before performing the click)

Scroll Reverser has no code to interact with the keychain and it does not explicitly request any privileges.

It looks to me that the keychain issue relates to Apply working around this vulnerability: http://apple.stackexchange.com/a/213099/174338 - because ScrollReverse is modifying mouse events, it could be used to fake confirmation dialog approval - example of other apps affected). Rather than prevent simulated mouse events (potentially breaking things for people with genuine accessibility needs, and also breaking remote desktop applications) they just warn that you're potentially opening yourself up.

Curiously, the event mask is NSEventMaskGesture|NSScrollWheelMask (no clicks) but my guess is that Apple are being conservative and trying not to accidentally leave open another pathway of faking confirmations.

[MoonShotDev]

ScrollReverse hooks into system events using CGEventTapCreate in MouseTap start. Elevated permissions are required to do this because it could alter the behaviour of other applications without the user being aware (eg user goes to click on a "Deny" button but a devious application intercepts the click and injects an event to move the mouse to "Accept" before performing the click)

Yes, but again, there is no issue with Scroll Reverser working day in and day out without needing elevated privileges with Apple nagging to add it to the Accessibility list.

It looks to me that the keychain issue relates to Apply working around this vulnerability: http://apple.stackexchange.com/a/213099/174338 - because ScrollReverse is modifying mouse events, it could be used to fake confirmation dialog approval

Yes, so perhaps the way to deal with this is to have Scroll Reverser be aware of when the keychain is being accessed and temporarily un-inject itself from the event stream to avoid this pop up. The answer is NOT to tell all users "just add it to the accessibly list and stop being paranoid".

Realize, just because a project is open source does not mean it is immune to nefarious actions by some stealthy developers. To the contrary, I've always felt open source projects were actually MORE open to attacks and hacking because (a) anyone can throw up a GitHub project that people download and never bother to look at the code, and (b) any anonymous user can contribute code to a large project and, with a code patch sufficiently obfuscated, could easily inject nefarious behavior into a previously "safe" app.

So I ask, which code would you trust more? Closed source code written by well-known entities like Intuit, Apple, Microsoft, etc that have millions of users and real reputations to protect and legal ramifications at state, or would you rather install 250,000 lines of purposely obfuscated code (that few will ever actually take the time to inspect) by some "joebloe296" on GitHub? Hmm. So yeah, when Apple tells me this tiny little applet I installed is wanting to "control my computer" (their words) when I'm in the middle of trying to install a printer driver software from a reputable company, it does raise up some pretty big red flags. Also, this comes on he heals of news of DropBox getting busted for tampering with the default text on the keychain security dialog and inserting themselves into the accessibility list without users knowing or agreeing.

[Levi Cameron]

It seems that Apple are a little smarter with the dialog than I expected: it only happens if an active tap handles certain events while the dialog is open, however it doesn't seem to matter what the tap actually does with those events so they didn't get it completely right. If an active tap doesn't change any events then it really shouldn't have triggered a warning.

Reproduce instructions

• Trigger an authorization services dialog (easiest is to trigger a keychain permission request)
• While the dialog is open, scroll (2-finger trackpad or mouse scroll wheel) while the pointer is over the security dialog
• Allow the keychain request

Trigger Events

Any of the following events handled by an active tap on an authorization services dialog will trigger a second dailog

• Gestures
  • Any >=3 finger gesture that is not already handled by the OS.
    • If you go into Sys Preferences -> Trackpad and deselect every gesture, then every trackpad gesture triggers the warning
    • If you go into Sys Preferences -> Trackpad and set "Swipe between full-screen apps" to 3 fingers, then a 3-finger swipe does not trigger the warning
  • Any 2 finger gesture
    • Regardless of whether you set a 2-finger gesture (eg "Swipe between pages")
  • 1 finger gestures
    • If "Tap to click" gesture is enabled: Always
    • If "Tap to click" gesture is disabled: Only if using a force sensitive trackpad (NSEventMaskPressure exists separately from NSEventMaskGesture but there are still related gestures in the event stream). This is probably what is causing the most problems -- the builtin trackpads for retina macbooks since 2015 are all force sensitive.
• Scrolling
  • Always

(Bad) Workaround don't use a force-sensitive trackpad to click, don't use a 2-finger tap and don't scroll a mouse wheel while the keychain dialog is active.

Solutions

• If you knew whether an authorization services dialog was active then you could disable the active tap

  • I tried CGEventTapEnable(activeTapPort, NO) from inside an active tap NSScrollWheel event in an authorization services dialog. It doesn't work (it does stop the warning if you disable it from a scroll event outside the dialog).
  • You would have to somehow keep track of the window under the current mouse cursor and enable/disable if it was authorization services dialog -- I'm not sure either of those things are possible without root access and I doubt you'd be using an officially supported API to do it.

• I think the biggest problem is force-sensitive trackpads where simply clicking on the Allow button is enough to trigger the second dialog and from the user's perspective they haven't even scrolled

  • If the passive tap was used for NSEventMaskGesture and the active tap was used for NSScrollWheelMask scroll events then this would fix the vast majority of gesture triggers. I've tried this locally and it appears to work fine.
  • The passive tap was originally added here to fix #1. The tap callbacks were later merged here and then the passive tap event mask was set to zero here
    • If I set System Preferences -> Trackpad -> "Look up & data detectors" to 3-finger tap then with after patch 3-finger tap still works. The same tap callback can continue to be used for both the active & passive since they deal with different event types.

[Zorn]

Please note that, although unlikely for most users, if at any point there is an app or any sort of interface running with root privileges in which you intend to scroll, Scroll Reverser will not and can not work in that root app unless it's added to the accessibility list. This includes administrative dialogs.

Also for the individual hung up on the phrase "control my computer," intercepting a scroll event, and sending the opposite scroll event falls under that category. That's just how it is. You either deal with it or stop using an app which reverses your scrolling, since that is controlling your computer.

Also, being added to the accessibility list does not grant the app full "control" over your computer in the widest sense of the word. It allows the app to intercept and send input no matter which app it's interacting with, and it allows the app to read text from any open windows (though, Scroll Reverser does not do the latter) - it allows a few other things, too, but I'm just pointing out that it doesn't allow full control over everything.

[Levi Cameron]

I have absolutely no idea why (and haven't really investigated very much) but it also fixes #39

[Levi Cameron]

And #42 -- it looks to be that OSX really doesn't like active taps on anything that involves gestures

[Nick Moore]

Thanks @levic for your hard work on this, and others for you contributions & reports. I will review & work on getting this out in an update.

[Nick Moore]

Have just released Scroll Reverser 1.7.5 with the passive tap change, and therefore closing this issue.

[Zorn]

It should probably be noted somewhere that Scroll Reverser must be added to the accessibility list for its features to work in software running as root/admin, apps running with elevated privileges, or most system dialogues.