Bug 94039 - Fix security vulnerability in Sparkle updater, switch to HTTPS for updates
Summary: Fix security vulnerability in Sparkle updater, switch to HTTPS for updates
Status: RESOLVED FIXED
Alias: None
Product: XQuartz
Classification: Unclassified
Component: Other (show other bugs)
Version: unspecified
Hardware: Other Mac OS X (All)
: medium major
Assignee: Jeremy Huddleston Sequoia
QA Contact: Jeremy Huddleston Sequoia
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-08 06:45 UTC by pibswhxs
Modified: 2016-12-06 23:54 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description pibswhxs 2016-02-08 06:45:26 UTC
See: https://vulnsec.com/2016/osx-apps-vulnerabilities/

Actions required:
- Update to latest version of Sparkle framework (1.13.1; http://sparkle-project.org/)
- Serve AppCast update feed (http://xquartz.macosforge.org/downloads/sparkle/release.xml) via HTTPS only to prevent MITM attacks.
Comment 1 Jeremy Huddleston Sequoia 2016-02-08 07:14:15 UTC
There is no vulnerability here.  We don't really care if someone MITM's our connection to the update server because if they give an invalid payload, the signature will fail.

Furthermore, github does not support https.
Comment 2 Jeremy Huddleston Sequoia 2016-02-08 07:19:52 UTC
Oh, you're saying the vulnerability isn't in spoofing the update payload but rather the web page itself.  Well, there's not much we can do about that unless github starts allowing https traffic.  This is the reason we have this exception in our Info.plist:

	<key>NSAppTransportSecurity</key>
	<dict>
		<key>NSExceptionDomains</key>
		<dict>
			<key>xquartz.org</key>
			<dict>
				<key>NSExceptionAllowsInsecureHTTPLoads</key>
				<true/>
				<key>NSIncludesSubdomains</key>
				<true/>
			</dict>
		</dict>
	</dict>
Comment 3 pibswhxs 2016-02-08 10:55:00 UTC
It's not about GitHub, it's about using https://xquartz.macosforge.org/downloads/sparkle/release.xml for AppCast feeds instead of http and updating to the latest Sparkle framework. That's it.
Comment 4 Jeremy Huddleston Sequoia 2016-02-08 17:48:52 UTC
We're no longer hosted at MacOSForge.  We're hosted at GitHub.  The update feed is located at http://www.xquartz.org/releases/sparkle/beta.xml, and unless github starts offering us a way to access that via https, we don't have a way of addressing this.  This is why we have to add xquartz.org to the whitelist.
Comment 5 itadmin 2016-02-10 20:09:08 UTC
Surely there is no reason to not update to the patched 1.13.1 Sparkle Framework version:

https://github.com/sparkle-project/Sparkle/releases/download/1.13.1/Sparkle-1.13.1.tar.bz2

As for no vulnerability

https://www.evilsocket.net/2016/01/30/osx-mass-pwning-using-bettercap-and-the-sparkle-updater-vulnerability/
Comment 6 Jeremy Huddleston Sequoia 2016-02-11 09:38:21 UTC
1) We can't update to 1.13.1 because we support Snow Leopard clients.
2) The upstream changes simply block http redirect, but we rely on http redirects for current server moves (and that might be needed in the future).  Their solution is to use https (which would be great if we could).
3) 1.13.1 doesn't protect against DNS spoofing.  You can still MITM 1.13.1 when using http using DNS spoofing attacks.  https is the only solution.
4) github does not support https for hosted sites.

Please see my post to x11-users about the issue and why it's not as trivial a fix as you seem to think and reply to that thread.

http://lists.apple.com/archives/x11-users/2016/Feb/msg00004.html

If you have a viable solution (eg: you know somewhere that will provide free hosting with a dedicated IP address, so we can use https, I'd be happy to use that for the feed.
Comment 7 Michael McNeill 2016-12-05 16:05:39 UTC
@Jeremy, you mention that this limitation is because of GitHub not offering HTTPS on hosted sites, but I found this article: https://github.com/blog/2186-https-for-github-pages. Is it possible for you to change to the *.github.io short name for this update feed and utilize the provided HTTPS?
Comment 8 Jeremy Huddleston Sequoia 2016-12-06 23:54:32 UTC
We switched hosting to be able to use https.  This was addressed about a year or so ago.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.