I agree. I can’t see how that can work with a properly configured Sparkle, that 
is an App that accepts only properly signed update.


> Le 9 févr. 2016 à 23:22, Graham Cox <graham....@bigpond.com> a écrit :
> 
> Thanks for the heads-up Jens.
> 
> Is it enough to change the SUFeedURL to https (if your server supports it, 
> which ours does), or does it also require the library to be updated? The 
> comment you link doesn’t clarify it for me - it mentions WebView, but I’m not 
> clear about how Sparkle is using Webview - wouldn’t it just request the 
> appcast directly, parse it and then download the update notes if it finds an 
> update BEFORE opening a webview? Other than displaying the update notes I 
> don’t see why Sparkle would open a Webview, but my understanding of how it 
> works could well be wrong.
> 
> There’s another thing too. Even if the appcast feed were compromised and an 
> “update” containing malware were injected, it would still have to be signed 
> correctly using the developers private key which Sparkle checks before 
> installing the update. So even if it got that far it would surely fail at 
> that step?
> 
> —Graham
> 
> 
> 
>> On 10 Feb 2016, at 8:10 AM, Jens Alfke <j...@mooseyard.com> wrote:
>> 
>> Ars Technica has an article today about a vulnerability in the Sparkle 
>> auto-update framework, which can allow an attacker to hijack an app update 
>> check to install malware on the user’s Mac:
>>      
>> http://arstechnica.com/security/2016/02/huge-number-of-mac-apps-vulnerable-to-hijacking-and-a-fix-is-elusive/
>> 
>> The clearest description of the bug is in this comment:
>>      
>> http://arstechnica.com/security/2016/02/huge-number-of-mac-apps-vulnerable-to-hijacking-and-a-fix-is-elusive/?comments=1&post=30615427#comment-30615427
>> 
>> Basically: If your app uses a version of Sparkle older than 1.13 — like 
>> every single Sparkle-using app on my computer :( — and the updates are 
>> delivered over a non-HTTPS connection, you’re vulnerable (or rather, your 
>> users are.)
>> 
>> The attack’s not trivial: it requires someone to tamper with the appcast RSS 
>> feed being received by Sparkle, at the time that it checks for an update. 
>> Most likely this would be by poisoning the DNS on a shared router and 
>> pointing your domain to their server; or else they could compromise the 
>> router to sniff the HTTP traffic and inject the payload into the stream.
>> 
>> The best fix is to upgrade your server to use HTTPS. If your hosting 
>> provider still charges an arm and a leg for SSL, switch.
>> In addition (or as the second-best fix if you can’t go SSL), download the 
>> latest Sparkle and update your app project to use it.
>> 
>> —Jens
> 
> 
> _______________________________________________
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/mailing%40xenonium.com
> 
> This email sent to mail...@xenonium.com


_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to