Re: An API for Airplane mode on iOS?

[Jens Alfke]

> On Feb 9, 2016, at 10:38 AM, Alex Zavatone  wrote:
> 
> Simply put, if we can detect that this user is has turned off Airplane mode, 
> we can respond in a more cautious manner.

But you can run into the same behaviors if the user has turned WiFi and/or 
cellular off and then back on. The Airplane Mode switch is just a ‘macro’ that 
turns WiFi, cellular and Bluetooth off (or back on) at once. You can also get 
race conditions if the device has been away from WiFi and then comes in range 
of a network that takes a little while to negotiate. (Usually if you’re 
listening for reachability of a specific host, you won’t hit these in-between 
states, though.)

The way we deal with this is to retry HTTP requests, if they fail with some 
common transient IP-level errors like ‘no route to host’ or ‘connection reset 
by peer’. The retry delay doubles after each failure, and most types of 
requests give up after 3 failures, so the delays are like 1, 2, 4 seconds.

—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/archive%40mail-archive.com

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

Re: An API for Airplane mode on iOS?

[dangerwillrobinsondanger]

> On Feb 9, 2016, at 4:02 PM, Jens Alfke  wrote:
> 
> 
>> On Feb 8, 2016, at 9:45 PM, Glenn L. Austin  wrote:
>> 
>> According to the docs on Reachability (possibly lost in the mists of 
>> time...), Reachability isn't really designed to tell you whether your net 
>> access *will* succeed, but to give you reasons that your last access 
>> *failed.*
> 
> It’s not that surprising. There’s no guarantee that any IP packet will make 
> it across the network, and no way to tell whether a host really is reachable 
> without actually sending a packet to it (and back.) So the only way 
> Reachability could tell you an access *will* succeed would be if it were 
> constantly pinging the server, which is obviously impractical.
> 
> All Reachability tells you is whether there is an active network interface 
> that can be used to route a packet one hop toward the desired host.
> 
> ―Jens
> __ 

Indeed. 
I like to call this "The Truth About Sockets", or "It Would Be Nice If Apple 
and Other API Vendors Just Shared Precisely What They Do To Determine Which 
User Friendly Network-Related Error Message To Present To Users In Their Apps"

Safari as an example does try the connection first. Apple recommends this. 
After a failure or three it is good to attempt a reasonable explanation to the 
user. 
Pretty easy to determine if you're getting loop back or no initial hop.
A little fancier to look at getting more hops but destination server not 
responding. 
Really more work to understand when you're connected to a captive network but 
not authenticated and try to let users know or to deal with cellular data 
turned off for an app and not know. 

In the end the first step is always the same. 
Try to connect first. 
Even the venerable Beej's Guide to Sockets says this. 


___

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

Re: Just a quick verification on a bad access cause.

[Alex Zavatone]

On Feb 8, 2016, at 5:10 PM, Jens Alfke wrote:

> 
>> On Feb 8, 2016, at 1:47 PM, Alex Zavatone  wrote:
>> 
>> if ( [myIVar respondsToSelector:@selector(someMethod)] {
>> EXC_BAD_ACCESS (code=1, address=0x143545358)
>> I did a po on myiVar and I get an address or 0x00014f05ee00
> 
> 0x143545358 is probably the (bogus) class-info pointer it got from the 
> object’s ‘isa’ pointer. So in this case the myIVar pointer itself isn’t 
> itself obviously bad, but it is pointing to garbage. Most likely it used to 
> be a valid object but was dealloced and the memory’s been reused for 
> something else.
> 
> NSZombieEnabled is the obvious thing to try here. And/or the address 
> sanitizer.
> 

Arrrgh.  This is not a trivial case to reproduce.  Thanks for the tips though.  

>> Also, I'd prefer to use the property not the iVar as I've found these much 
>> safer in the past for accessing internal objects without causing access 
>> issues.  
>> Am I correct here?
> 
> I always use ivars because it’s much more efficient in code size and clock 
> cycles. The only case where using ivars directly can bite you is if either 
> the ivar or the property will be modified on another thread, since ARC’s 
> inlined setter code isn't thread-safe.
> 
> But I always prefix ivars with an underscore to make it obvious that they 
> have different scope from locals.

Yeah, something that kills me here.  No camelcasing and identical ivar and 
property names.  : /

Thanks you, sir.  As always, your input is much appreciated.

Alex Zavatone
___

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

Re: An API for Airplane mode on iOS?

[Alex Zavatone]

On Feb 8, 2016, at 5:13 PM, Jens Alfke  wrote:

> 
>> On Feb 8, 2016, at 1:55 PM, Alex Zavatone  wrote:
>> 
>> I'm using reachability classes to determine if we can reach our web services 
>> IP and monitoring all reachability enums, but would be "really nice™" is if 
>> there is a published API to read the position of the Airplane Mode setting.
> 
> Do you need to treat airplane mode differently than just turning off WiFi 
> (and cellular, if the device has it), or simply being out of reach of a base 
> station?
> 
> Generally it’s enough to know that the host isn’t reachable, or that there 
> are no available network interfaces.
> 

Apparently, I do.  We have a client who puts his device in Airplane Mode 
overnight and he’s on the other side of the planet.

I’ve created multiple tests using reachability and it would be REALLY EASY if 
we could simply respond to changes in the Airplane Mode switch.

BUT, I know this isn’t everything.  I am well aware that the connection will 
often take time to negotiate, so I have several methods meant to test if our 
iOS app can “see” our web server once reachability has changed.

We have some ugly code underneath that doesn’t fail properly (does nothing on a 
fail) and I’m sure that’s related to the issue, but it’s scary in there and I 
don’t have the all the time this requires to address that.


___

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

Re: An API for Airplane mode on iOS?

[Jens Alfke]

> On Feb 9, 2016, at 4:17 AM, Alex Zavatone  wrote:
> 
> I’ve created multiple tests using reachability and it would be REALLY EASY if 
> we could simply respond to changes in the Airplane Mode switch.

This triggers changes in network interfaces that you can detect using the 
SystemConfiguration framework.
It _should_ result in a reachability notification, but you’re implying it 
doesn’t for some reason, right?
There are lower-level SystemConfiguration APIs that can tell you about network 
interfaces going up/down.

—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/archive%40mail-archive.com

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

PSA: Does your app use Sparkle? Update it, or use an HTTPS server

[Jens Alfke]

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=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/archive%40mail-archive.com

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

Re: PSA: Does your app use Sparkle? Update it, or use an HTTPS server

[Jean-Daniel Dupas]

OK. I did watch the POC and it appears this is not in the update process, but 
in the check for update that the attack occurs.

> Le 9 févr. 2016 à 23:27, Jean-Daniel Dupas  a écrit :
> 
> 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  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  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=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/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

Re: PSA: Does your app use Sparkle? Update it, or use an HTTPS server

[SevenBits]

Yes, this is very important -- don't ignore this message!

On Tuesday, February 9, 2016, Jens Alfke  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=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/sevenbitstech%40gmail.com
>
> This email sent to sevenbitst...@gmail.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

Re: PSA: Does your app use Sparkle? Update it, or use an HTTPS server

[Graham Cox]

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  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=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/archive%40mail-archive.com

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

Re: PSA: Does your app use Sparkle? Update it, or use an HTTPS server

[Jean-Daniel Dupas]

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  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  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=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

Re: An API for Airplane mode on iOS?

[Alex Zavatone]

On Feb 9, 2016, at 12:15 PM, Jens Alfke wrote:

> 
>> On Feb 9, 2016, at 4:17 AM, Alex Zavatone  wrote:
>> 
>> I’ve created multiple tests using reachability and it would be REALLY EASY 
>> if we could simply respond to changes in the Airplane Mode switch.
> 
> This triggers changes in network interfaces that you can detect using the 
> SystemConfiguration framework.
> It _should_ result in a reachability notification, but you’re implying it 
> doesn’t for some reason, right?
> There are lower-level SystemConfiguration APIs that can tell you about 
> network interfaces going up/down.

What is happening is that edge cases are coming back from the client and every 
edge case is another case to fix and test, which requires to much turnaround 
time.

I already removed a race condition where a "start a connection" message was 
sent out when the reachability of the network interfaces had changed to "I am 
not returning 0", but this did not guarantee that the internet connection has 
renegotiated its IP and could reach our target web services yet.

Simply put, if we can detect that this user is has turned off Airplane mode, we 
can respond in a more cautious manner.

The underlying code is wrapping several layers, each with its own "is the 
network available" internal ivar and/or property.

You've pointed me in the right direction, Jens.  If I have the time to fix it, 
that's another matter.

I do have an, "I don't care what changed, can this device reach this IP through 
any means?" method set up.  It's just the underlying layers of PTSD inducing 
fragile spaghetti code that simply aren't safe to try and change that lie 
underneath… waiting to bite the poor soul who thinks they can modify them.  

I'll take a look at the system configuration frameworks.  

Cheers and thanks again.

> 
> —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/archive%40mail-archive.com

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

Re: PSA: Does your app use Sparkle? Update it, or use an HTTPS server

[Jens Alfke]

> On Feb 9, 2016, at 2:22 PM, Graham Cox  wrote:
> 
> 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?

Using HTTPS for the appcast RSS feed should be sufficient, because it prevents 
an attacker from tampering with the contents of the feed.

> The comment you link doesn’t clarify it for me - it mentions WebView, but I’m 
> not clear about how Sparkle is using Webview

It’s to display the release notes, which come from an RSS entry in the feed and 
are in HTML format. And Sparkle had a couple of bugs relating to that: (a) the 
WebView was configured to allow JavaScript, and (b) their delegate handled 
navigation requests to file: URLs by sending them to the Finder. This meant 
that a malicious feed entry could run a script to download some malware and 
then tell the Finder to launch the downloaded malware installer.

Full details are here:
https://vulnsec.com/2016/osx-apps-vulnerabilities/

One of the takeaways from this for Mac developers is that WebViews can be 
really dangerous, and if you use one in your app, you should give it the 
minimum possible privileges and be really careful about how you respond to any 
requests the loaded web page makes.

—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/archive%40mail-archive.com

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

Re: PSA: Does your app use Sparkle? Update it, or use an HTTPS server

[Graham Cox]

> On 10 Feb 2016, at 1:08 PM, Charles Srstka  wrote:
> 
> If your app is accessing your appcast via HTTP, that could be intercepted 
> just the same as your relnotes, and then the attacker could set the relnotes 
> URL to whatever s/he wants.


Yep, I see that. Bugger.

—G.
___

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

Re: PSA: Does your app use Sparkle? Update it, or use an HTTPS server

[Trygve Inda]

> If your hosting provider still charges an arm and a leg for SSL, switch.

I need SSL for multiple subdomains. My host (Pair Networks) charges $449/yr
for such a certificate. That seems really expensive. What are others paying
for this? I have been very happy with Pair as we run a complex server setup
with multiple cron jobs, custom C programs etc.

I also see no way to add an SSL certificate to a CNAME'd site at Amazon S3:

download.xericdesign.com CNAME
s3.amazonaws.com/download.xericdesign.com/

Trygve



___

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

Re: PSA: Does your app use Sparkle? Update it, or use an HTTPS server

[Charles Srstka]

If your app is accessing your appcast via HTTP, that could be intercepted just 
the same as your relnotes, and then the attacker could set the relnotes URL to 
whatever s/he wants.

Charles

> On Feb 9, 2016, at 7:53 PM, Graham Cox  wrote:
> 
> Wait a sec, I think I see an easy solution to this.
> 
> The appcast supplies the URL for the release notes, so that can be updated to 
> https without having to republish the app itself. That makes this a lot less 
> trouble than it seems.
> 
> Am I right?
> 
> —Graham
> 
> 
> 
> 
> 
>> On 10 Feb 2016, at 12:49 PM, Graham Cox  wrote:
>> 
>> 
>>> On 10 Feb 2016, at 12:22 PM, Jens Alfke  wrote:
>>> 
>>> It’s to display the release notes, which come from an RSS entry in the feed 
>>> and are in HTML format. And Sparkle had a couple of bugs relating to that: 
>>> (a) the WebView was configured to allow JavaScript, and (b) their delegate 
>>> handled navigation requests to file: URLs by sending them to the Finder. 
>>> This meant that a malicious feed entry could run a script to download some 
>>> malware and then tell the Finder to launch the downloaded malware installer.
>>> 
>> 
>> 
>> Got it, so the signing aspect is irrelevant.
>> 
>> Already updated to use https, but of course the problem is that in itself 
>> requires a Sparkle update… 
> 
> 
> ___
> 
> 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/cocoadev%40charlessoft.com
> 
> This email sent to cocoa...@charlessoft.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

Re: An API for Airplane mode on iOS?

[Alex Zavatone]

On Feb 9, 2016, at 3:37 PM, Jens Alfke  wrote:

> 
>> On Feb 9, 2016, at 10:38 AM, Alex Zavatone  wrote:
>> 
>> Simply put, if we can detect that this user is has turned off Airplane mode, 
>> we can respond in a more cautious manner.
> 
> But you can run into the same behaviors if the user has turned WiFi and/or 
> cellular off and then back on.

Yup.

> The Airplane Mode switch is just a ‘macro’ that turns WiFi, cellular and 
> Bluetooth off (or back on) at once. You can also get race conditions if the 
> device has been away from WiFi and then comes in range of a network that 
> takes a little while to negotiate. (Usually if you’re listening for 
> reachability of a specific host, you won’t hit these in-between states, 
> though.)
> 
> The way we deal with this is to retry HTTP requests, if they fail with some 
> common transient IP-level errors like ‘no route to host’ or ‘connection reset 
> by peer’. The retry delay doubles after each failure, and most types of 
> requests give up after 3 failures, so the delays are like 1, 2, 4 seconds.

That’s what I would like to do.

However, we have a 4 deep nested set of classes (I didn’t write this and if I 
did, I should be shot), when the operation fails at the lowest level… nothing 
happens.

No return statement indicating an error and in all the classes above it, we 
have the same issue.

That’s what’s obvious.  

Obviously, this a problem, but possibly not the only problem.  

See where I am with this?  It could easily (wait, wait, it is) a snake pit.

(Caveat, yes, you’re right, but my boss will kill me until this gets 
higher priority to address.)

However, all is not lost.  A certain Hoerl type character pointed me to a 
pretty nice SO answer which references to some getIPAddress code from some so 
called “Jens” character for testing if Airplane Mode (or the equivalent) is on.

Well, as luck would have it, I’m already using it, just not in that manner.

SO, before I go digging into a “very bad world”, we can at least run a test by 
our client to see what his device is seeing - connectivitywise.


Then, we can determine if I should prepare to descend into the pit of darkness.

Hopefully, I’ll be able to gut and rebuild the monstrosity before that has to 
happen.  

Thanks again guys.  

Alex Zavatone
___

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

Re: PSA: Does your app use Sparkle? Update it, or use an HTTPS server

[Jake Petroules]

AWS Certificate Manager provides multi-domain certificates (up to 100, I think) 
for free. You can serve an S3 bucket using CloudFront with a custom domain and 
SSL, and costs for this will be pretty minimal (probably well under $10 a 
month?).

> On Feb 9, 2016, at 8:48 PM, Trygve Inda  wrote:
> 
>> If your hosting provider still charges an arm and a leg for SSL, switch.
> 
> I need SSL for multiple subdomains. My host (Pair Networks) charges $449/yr
> for such a certificate. That seems really expensive. What are others paying
> for this? I have been very happy with Pair as we run a complex server setup
> with multiple cron jobs, custom C programs etc.
> 
> I also see no way to add an SSL certificate to a CNAME'd site at Amazon S3:
> 
> download.xericdesign.com CNAME
> s3.amazonaws.com/download.xericdesign.com/
> 
> Trygve
> 
> 
> 
> ___
> 
> 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/jake.petroules%40petroules.com
> 
> This email sent to jake.petrou...@petroules.com

-- 
Jake Petroules - jake.petroules at petroules.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

Re: PSA: Does your app use Sparkle? Update it, or use an HTTPS server

[Graham Cox]

> On 10 Feb 2016, at 12:22 PM, Jens Alfke  wrote:
> 
> It’s to display the release notes, which come from an RSS entry in the feed 
> and are in HTML format. And Sparkle had a couple of bugs relating to that: 
> (a) the WebView was configured to allow JavaScript, and (b) their delegate 
> handled navigation requests to file: URLs by sending them to the Finder. This 
> meant that a malicious feed entry could run a script to download some malware 
> and then tell the Finder to launch the downloaded malware installer.
> 


Got it, so the signing aspect is irrelevant.

Already updated to use https, but of course the problem is that in itself 
requires a Sparkle update… 

—Graham



___

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

Re: PSA: Does your app use Sparkle? Update it, or use an HTTPS server

[Graham Cox]

Wait a sec, I think I see an easy solution to this.

The appcast supplies the URL for the release notes, so that can be updated to 
https without having to republish the app itself. That makes this a lot less 
trouble than it seems.

Am I right?

—Graham





> On 10 Feb 2016, at 12:49 PM, Graham Cox  wrote:
> 
> 
>> On 10 Feb 2016, at 12:22 PM, Jens Alfke  wrote:
>> 
>> It’s to display the release notes, which come from an RSS entry in the feed 
>> and are in HTML format. And Sparkle had a couple of bugs relating to that: 
>> (a) the WebView was configured to allow JavaScript, and (b) their delegate 
>> handled navigation requests to file: URLs by sending them to the Finder. 
>> This meant that a malicious feed entry could run a script to download some 
>> malware and then tell the Finder to launch the downloaded malware installer.
>> 
> 
> 
> Got it, so the signing aspect is irrelevant.
> 
> Already updated to use https, but of course the problem is that in itself 
> requires a Sparkle update… 


___

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

Re: PSA: Does your app use Sparkle? Update it, or use an HTTPS server

[Quincey Morris]

On Feb 9, 2016, at 17:53 , Graham Cox  wrote:
> 
> The appcast supplies the URL for the release notes, so that can be updated to 
> https without having to republish the app itself. That makes this a lot less 
> trouble than it seems.

Yes, but the appcast itself is vulnerable to separate attack, if your access to 
it is http. (Its URL is specified in the bundle plist.)

>> Already updated to use https, but of course the problem is that in itself 
>> requires a Sparkle update… 

Yes, but it’s no worse a problem than the one you started with.

___

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

Re: PSA: Does your app use Sparkle? Update it, or use an HTTPS server

[Roland King]

> On 10 Feb 2016, at 13:45, sqwarqDev  wrote:
> 
> 
>> On 10 Feb 2016, at 09:08, Charles Srstka  wrote:
>> 
>> If your app is accessing your appcast via HTTP, that could be intercepted 
>> just the same as your relnotes, and then the attacker could set the relnotes 
>> URL to whatever s/he wants.
> 
> 
> Can I just double-check my understanding here:
> 
> 1. If the SUFeedURL uses https, the app is not vulnerable.
> 
> 2. If 1 is true, neither of these matter:
>   2.1 the version of Sparkle
>   2.2 whether the release notes are http or https
> 
> 

1. true

2. By my reading, not true. if the app notes are http then they can be spoofed 
and inject javascript via the webkit widget to run nefarious code. 

Making both https works as neither can be spoofed, upgrading sparkle fixes the 
issue even if the notes are not https. Until someone finds the next exploit, 
thus meaning all https all the time is a better way to go. 


___

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

Re: PSA: Does your app use Sparkle? Update it, or use an HTTPS server

[Ken Thomases]

On Feb 9, 2016, at 11:45 PM, sqwarqDev  wrote:
> 
> 
>> On 10 Feb 2016, at 09:08, Charles Srstka  wrote:
>> 
>> If your app is accessing your appcast via HTTP, that could be intercepted 
>> just the same as your relnotes, and then the attacker could set the relnotes 
>> URL to whatever s/he wants.
> 
> 
> Can I just double-check my understanding here:
> 
> 1. If the SUFeedURL uses https, the app is not vulnerable.

Not quite, because of 2.2 below.

Also, in theory somebody could: a) compromise your server to serve a malicious 
appcast or b) get a Certificate Authority to issue them a certificate in error 
(e.g. via social hack), thus undermining HTTPS security.  These are less likely 
and fairly catastrophic, so may be deemed to eclipse the vulnerability in 
Sparkle.


> 2. If 1 is true, neither of these matter:
>   2.1 the version of Sparkle
>   2.2 whether the release notes are http or https

If the release notes are via a separate URL and that URL is HTTP rather than 
HTTPS, then the attacker can spoof it as easily as they could spoof an HTTP 
appcast.  If they do that, then your app is just as vulnerable.

You are mostly safe if the appcast URL is HTTPS _and_ the release notes are 
embedded in the appcast or accessed via HTTPS URL.

Regards,
Ken


___

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

Re: PSA: Does your app use Sparkle? Update it, or use an HTTPS server

[sqwarqDev]

> On 10 Feb 2016, at 09:08, Charles Srstka  wrote:
> 
> If your app is accessing your appcast via HTTP, that could be intercepted 
> just the same as your relnotes, and then the attacker could set the relnotes 
> URL to whatever s/he wants.


Can I just double-check my understanding here:

1. If the SUFeedURL uses https, the app is not vulnerable.

2. If 1 is true, neither of these matter:
2.1 the version of Sparkle
2.2 whether the release notes are http or https


TIA


Phil


___

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

Re: PSA: Does your app use Sparkle? Update it, or use an HTTPS server

[diederik]

About feedback to users and helping them avoid problems:

So in order to avoid problems in the immediate short run, we should inform
users to turn off automatic software updates and update checks with a
current version and also tell them how they can find out which apps use
Sparkle??

Once an updated version is available, inform them to update, but only
through a secure network?

Anything more we need to think off with regard to users?






> On Feb 9, 2016, at 11:45 PM, sqwarqDev  wrote:
>>
>>
>>> On 10 Feb 2016, at 09:08, Charles Srstka 
>>> wrote:
>>>
>>> If your app is accessing your appcast via HTTP, that could be
>>> intercepted just the same as your relnotes, and then the attacker could
>>> set the relnotes URL to whatever s/he wants.
>>
>>
>> Can I just double-check my understanding here:
>>
>> 1. If the SUFeedURL uses https, the app is not vulnerable.
>
> Not quite, because of 2.2 below.
>
> Also, in theory somebody could: a) compromise your server to serve a
> malicious appcast or b) get a Certificate Authority to issue them a
> certificate in error (e.g. via social hack), thus undermining HTTPS
> security.  These are less likely and fairly catastrophic, so may be deemed
> to eclipse the vulnerability in Sparkle.
>
>
>> 2. If 1 is true, neither of these matter:
>>  2.1 the version of Sparkle
>>  2.2 whether the release notes are http or https
>
> If the release notes are via a separate URL and that URL is HTTP rather
> than HTTPS, then the attacker can spoof it as easily as they could spoof
> an HTTP appcast.  If they do that, then your app is just as vulnerable.
>
> You are mostly safe if the appcast URL is HTTPS _and_ the release notes
> are embedded in the appcast or accessed via HTTPS URL.
>
> Regards,
> Ken
>
>
> ___
>
> 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/diederik%40tenhorses.com
>
> This email sent to diede...@tenhorses.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