UPDATE February 1, 2016: It turns out some users are vulnerable to this attack. Read this followup post!
Sparklegate is the term I’ve coined for the recent discovery that, allegedly, every OS X machine out there is vulnerable to RCE (remote-code-execution) attacks because the widely used Sparkle framework, along with OS X’s standard WebView component, allow webpages to mount FTP volumes and run arbitrary programs on your computer.
The first report of this insane vulnerability restricted itself to the use of a terminal settings file to achieve this feat. Shortly after followed a second post, this time alleging that any executable could be run without need for the intermediate step of a .terminal file. This second post also came with a proof-of-concept exploit that anyone can use to attack people with.
The fix that’s suggested in the original post is for app developers to serve their update feeds over HTTPS and to update to the latest version of Sparkle in case that’s not enough. Espionage already checks for updates over HTTPS and therefore it is not particularly affected by this issue, but there is still the very remote chance that someone could obtain a legitimate-yet-fraudulent HTTPS certificate and conduct this attack. Also, the idea that this attack is even possible suggests a severe failing on Apple’s part, one that affects not just apps that use Sparkle but any app with a WebView (and every OS X user has at least several such apps).
So I decided to look into this further and attempt to reproduce the attack. Here’s what I found:
Cannot Reproduce (Mostly)
I ran Simone Margaritelli’s bettercap with the osxsparkle.rb module and tried to reproduce both of the alleged scenarios: attack-by-terminal-settings and attack-by-arbitrary-executable.
For the attack-by-arbitrary-executable I tried out /bin/ls:
sudo bettercap -L -X --no-spoofing --no-discovery --proxy --proxy-module ./osxsparkle.rb --sparkle-rce-file /bin/ls
In order to MITM yourself locally, you must also set your system-wide HTTP proxy settings to the LAN IP and port that’s shown in the output from bettercap. So I did that and then proceeded to Check for Updates in VLC.
Indeed, there was a flurry of activity, but something unexpected happened. Instead of being shown a terminal window with the output of `ls` I was taken to Firefox and a web page with this directory listing:
Well that’s not very threatening.
So I realized that apparently I was immediately, without going further, seemingly immune to this attack just because Firefox was somehow the default handler for ftp:// URLs.
OK, I thought, what happens if we remove Firefox as the handler?
After some digging I discovered a handy tool called duti (available via Homebrew). Setting the handler to com.apple.Finder didn’t work, but setting it to com.apple.Safari did. Here’s what happened when I tried it again with Safari as the default FTP handler:
Excellent! Just as I would expect, Quarantine prevents the file from automatically executing. Although it is a bit disturbing that Safari chooses to automount an FTP volume instead of handling the protocol itself (like Firefox), still no RCE.
Maybe the terminal settings file will bypass Quarantine and Gatekeeper (as the original post alleges)?
sudo bettercap -L -X --no-spoofing --no-discovery --proxy --proxy-module ./osxsparkle.rb --sparkle-rce-file ./settings.terminal
Nope:
Blocked by Gatekeeper.
Conclusion (& Precautionary Steps To Mitigate)
At least in my attempts to reproduce this vulnerability, it seems both Quarantine and Gatekeeper, together, prevent both signed and unsigned applications from being automatically run without the user’s consent.
To be clear, this is still a problem for several reasons:
- Just because a random webpage loads shouldn’t mean that Safari (or the Finder) auto-mounts or auto-launches anything! That’s just crazy! Thank goodness for Gatekeeper and Quarantine because without them this would have been a total and complete long-lasting catastrophe. So make sure you haven’t disabled either of them!
- As the original report indicates, this attack could still be used to exhaust a system’s memory because the way XML is handled is broken. Apps that check for updates over HTTP and haven’t updated to the latest version of Sparkle are still vulnerable to this.
How To Mitigate
Developers should update their apps and take care to:
- Make sure they’re using at least Sparkle 1.13.1 and preferably a later version. Until a later version is released I would recommend being cautious and building the Sparkle framework yourself from source (the Makefile makes this easy).
- Who knows what other crazy surprises like this are lurking undiscovered, so make sure your appcast is using HTTPS in addition to Sparkle’s built-in DSA signature verification.
- Sparkle should require both HTTPS and the DSA check from here on out. Now that HTTPS certs are free, no more excuses.
Users can simply download, install, and run Firefox (it’s a feature not a bug :P!).
To be certain that Firefox is the default handler for FTP you can use Homebrew to `brew install duti` and then:
duti -s org.mozilla.firefox ftp
However, there are other protocols besides FTP that could be used (like smb), so even better would be to install Little Snitch and make sure that there are no permanent rules allowing the Finder to make outgoing connections. Thus, if you get a prompt asking you to allow the Finder to connect to something (and you didn’t do anything to initiate), block it.
We will still release a minor update to Espionage with an updated Sparkle just to be extra safe.
The good news though is that as long as your Gatekeeper & Quarantine settings haven’t been modified, Sparklegate should not harm you (as long as you don’t blindly click “Yes” to things), and users can still take precautionary steps (like Little Snitch) to protect themselves even in the worst case where Gatekeeper and Quarantine fail.
Finally, a request to Apple: please fix that whole visiting-a-webpage-automounting-&-autolaunching thing. I’ve opened rdar://24428066 for this.
I see that I need to clarify few things.
1. The Default “ftp” handler in Mac OS X is Finder, not Safari, Chrome or Firefox.
2. This attack works on stock Mac OS X install, and GateKeeper enabled with both options “Mac App Store and identified developers” or “Mac App Store” (the strictest one).
3. Screenshots you’ve provided with GateKeeper/Quarantine shows us that you were trying to open those files using Safari – that’s why it’s not working. Safari will block files downloaded from the Internet or located on shared resources like FTP.
I sadly must admit that this post is mostly irrelevant. One good thing is that changing the default “ftp” handler to Firefox or Chrome helps to mitigate this attack.
Next time, please double check before publishing or mentioning work of other people.
Hey Radekk, thanks for your comment here (and elsewhere).
I spent more time today testing this on a clean account and have discovered that indeed there are situations where this attack bypasses Gatekeeper!
I’ve updated this post and have linked to a followup:
https://www.taoeffect.com/blog/2016/02/apologies-sky-kinda-falling-protecting-yourself-from-sparklegate/
Thank you again for your work on this vulnerability.