This is a followup to yesterday’s post: Sky Not Falling: Sparklegate Not As Bad As It Could Be
After trying and failing to reproduce Sparklegate, I arrived at the conclusion that Gatekeeper and Quarantine did in fact protect OS X users from the Remote Code Execution (RCE) attack.
What I Missed
Radek, the discoverer of the vulnerability, insisted that I was mistaken and that Gatekeeper really did get bypassed. So today I attempted to reproduce the attack using a fresh account on a different machine.
It turns out, if you’ve ever opened Firefox, you are not vulnerable (to the FTP version of the attack), even if Firefox is not running and you’ve manually set the Finder as the default FTP handler.
Resetting the protocol handler via duti -s com.apple.finder ftp has no effect for some reason. Firefox will still launch in response to the attack and the FTP handler is magically reset back to Firefox!
However: if you’ve never run Firefox on your account, then you are vulnerable (and you should pay attention even if you have used Firefox).
How To Protect Yourself From Sparklegate
Sparklegate is a fundamental flaw in OS X, not Sparkle. It is a flaw in Finder (foremost) and WebView (second most). You almost certainly have several apps that are vulnerable to this attack, and even if every app updates its Sparkle framework there still might be others that are vulnerable.
So here are 3 ways to protect yourself from getting owned, and I recommend you do all of them:
1: Download Firefox (if necessary) and run it once on every account
Firefox users are saved by a “bug” (that I hope never gets fixed).
2: Use the `duti` command
The duti utility mentioned in my previous post can prevent this attack by changing the default app that handles a protocol.
If necessary, install Homebrew, and in a terminal window run these commands:
brew install duti duti -s org.mozilla.firefox ftp duti -s com.apple.Safari afp duti -s com.apple.Safari smb
If Firefox is not installed you’ll need to change org.mozilla.firefox to com.apple.Safari like the others. I recommend Firefox because unlike Safari it does not auto-mount anything and it’s a great browser in its own right.
Just in case there are other protocols that could be used in this attack, you may also want to:
3: Use Little Snitch (or similar) to disable LAN & Finder connections
Open Little Snitch Configuration and make sure that you are looking at All Rules. Use the search field to search for Finder and delete any rules that appear in the search results.
Next, clear the search field and scroll to the top. Uncheck the rules that allow “Any Process” to make outgoing connections to the local network and click “Disable Anyway” when prompted:
Doing this will mean that you will get prompted more frequently. Prompts will happen when, for example, iTunes tries to sync with your iPhone over Wifi, or if you try to access a network volume, or for other reasons. Generally you’ll want to allow them unless they mention something about “ftp” or “smb” or “afp” and you aren’t trying to access a network volume.
Something like this might appear if you’re being attacked via FTP, but it’s not necessarily the only prompt to watch out for:
Click Deny in such instances to prevent the attack. You’ll then be greeted with an error like this:
Finally, Make Sure Gatekeeper Is Enabled
While Gatekeeper won’t protect users who have not done at least one of the things above, it will provide additional protection in case the AFP or SMB protocols are used:
- Open System Preferences
- Go to Security & Privacy
- Make sure that “Allow apps downloaded from:” is *NOT* set to “Anywhere”
If you must open an unsigned app while Gatekeeper is on (not recommended unless you know what you’re doing): right-click on the app and choose “Open” from the contextual menu.
Conclusion
This is a devastating vulnerability that affects many OS X users. Since both WebView and the Finder are at fault, the attack goes beyond apps that haven’t updated their Sparkle framework.
Until Apple fixes this problem, you can protect yourself by doing at least one of the three things mentioned above, and preferably all of them.
Thanks to Radek for insisting that I had missed something and for discovering this vulnerability. Thanks also to Simone Margaritelli for making it simple to use the exploit, for without that I would have been hard-pressed to learn how to defend against it.
Apple told me they are aware of this problem. I hope they’re able to fix it ASAP!
duti does not seem to work well on 10.11, after a couple seconds it gets reverted back to finder as default.
You can test in CLI with open ftp://localhost
Thanks for the report Bibi!
Duti does look like an old unmaintained utility, so you may want to try one of the recent forks of it.
This one in particular seems to have been modernized a bit and may work better on 10.11:
https://github.com/nivekkagicom/duti
That said, if none of the recently updated forks work, you still have options to fall back on (installing and running Firefox, and Little Snitch).
does blocking the apps that is infected from doing outgoing connection through little snitch will solve the problem ?
also does using vpn all the time also prevent being infected ?
> does blocking the apps that is infected from doing outgoing connection through little snitch will solve the problem ?
Yes, but you can usually disabled automatic update checking in apps.
> also does using vpn all the time also prevent being infected ?
It can help, but it’s no guarantee.
Duti (via brew) settings get reverted right away in 10.11.
See my comment above about trying one of the forks.
Hi Greg – yes, I did. It doesn’t work via that fork you cited either, after compiling.
Well son-of-a… Damn. I recommend opening an issue(s) in whatever forks you think look promising in terms of upkeep.
Apple is aware of this issue, so hopefully we’ll see a fix from them, but until that happens it looks like people are left having to rely on Firefox (for FTP) and Little Snitch (for SMB + AFP).
One can also use
http://www.rubicode.com/Software/RCDefaultApp/
to change the default applications.
Indeed. Frustrating, huh. I cannot believe how hard Apple has made url handlers, in El Capitan. App-fileextension links are relatively grokkable, but url handlers, damn.
This stuff about it being an OS X vulnerability is not correct. WebViews have Navigation policies that determine whether something, like an FTP link, should be openened or not. By default, the WebView blocks all attempts to do so.
However, Sparkle overrode the default security features of WebViws and told LaunchServices to open EVERYTHING. That’s the bug. The Sparkle update fixes that security bug.