Re: [swift-evolution] executing a string

[Josh Parmenter via swift-evolution]

I could see a method being implemented that does something bad, but isn’t 
called directly anywhere in code. A code path analysis of a program may miss 
the problematic method (though unlikely?). But if the method signature is 
passed in dynamically as the result of a web call or something, it could then 
be called and cause a problem. However- the malicious code here really is 
already in the binary.

Since app store review is mentioned here, I can’t speak as to how a binary is 
inspected for review, or what tools the app store team has at its disposal. But 
I would be surprised if there isn’t at least some sort of automated step that 
would reveal the code block that might be problematic. And finding another 
instance where calling something by selector would also raise a flag (in fact, 
even Xcode points out the possibility of a leak in these cases). Yes - it MIGHT 
be problematic, but I think there are greater security holes in the iOS / Obj-C 
ecosystem than what is mentioned here. Since it is a compiled language, and 
apps don’t ship with compilers, it seems like the possibility for abuse here is 
not huge. However - many iOS apps can execute JavaScript or create WebViews 
with strings from just about any source - and this is where (it seems to mean) 
a strong sandboxing environment is really needed. But I am curious to know 
(like Félix) if there are examples of this happening.

Best,

Josh

On Jul 14, 2016, at 10:18 PM, Félix Cloutier via swift-evolution 
> wrote:

I've never heard of an app being exploited through selector abuse. Do you have 
any example of that?

Félix

Le 14 juil. 2016 à 08:48:53, Ford Prefect via swift-evolution 
> a écrit :

One of the major security flaws of Obj C is
the ability to convert a string into a selector, which
permits using private methods by constructing selectors
at runtime long after the app store review has been completed.
Does Swift do away with that? I understand it doesn't
use selectors per se but is there an analogous mechanism?

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] executing a string

[Félix Cloutier via swift-evolution]

I've never heard of an app being exploited through selector abuse. Do you have 
any example of that?

Félix

> Le 14 juil. 2016 à 08:48:53, Ford Prefect via swift-evolution 
>  a écrit :
> 
> One of the major security flaws of Obj C is
> the ability to convert a string into a selector, which
> permits using private methods by constructing selectors
> at runtime long after the app store review has been completed.
> Does Swift do away with that? I understand it doesn't
> use selectors per se but is there an analogous mechanism?
>  
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] executing a string

[Karl via swift-evolution]

> On 14 Jul 2016, at 17:48, Ford Prefect via swift-evolution 
>  wrote:
> 
> One of the major security flaws of Obj C is
> the ability to convert a string into a selector, which
> permits using private methods by constructing selectors
> at runtime long after the app store review has been completed.
> Does Swift do away with that? I understand it doesn't
> use selectors per se but is there an analogous mechanism?
>  
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

As has been pointed out, Swift selectors are already much safer. I believe you 
can still convert a string to a selector, but really…

I wouldn’t call it a security flaw. Objects in Obj-C are free to pass messages 
around fairly loosely - sometimes the method you are trying to call doesn’t 
even exist but will be dynamically created and hooked up at runtime when you 
call it. This is a good article to learn more about how powerful Obj-C’s 
messaging system is: 
https://www.mikeash.com/pyblog/friday-qa-2009-03-27-objective-c-message-forwarding.html

It’s only a security flaw if you can somehow perform privileged operations from 
doing that. I’m not sure how the jailbreak community actually implements it, 
but I’d assume that to write out to system/non-app files they would need to 
disable sandboxing, which is what really gives you the security that apps won’t 
grab your data or make persistent changes outside of their own containers, or 
talk to the network when they shouldn’t (see: iOS keyboard extensions).

Yeah, you can call non-public APIs. That’s true in basically all software. The 
reason Apple discourages it isn’t for security - it’s so they don’t have to 
maintain code they never promised to maintain. It leads to more stable and 
reliable software.

It’s not really an undocumented API (really an undocumented behaviour), but 
there’s a famous lesson from Microsoft about this:

> Windows 95? No problem. Nice new 32 bit API, but it still ran old 16 bit 
> software perfectly. Microsoft obsessed about this, spending a big chunk of 
> change testing every old program they could find with Windows 95. Jon Ross, 
> who wrote the original version of SimCity for Windows 3.x, told me that he 
> accidentally left a bug in SimCity where he read memory that he had just 
> freed. Yep. It worked fine on Windows 3.x, because the memory never went 
> anywhere. Here's the amazing part: On beta versions of Windows 95, SimCity 
> wasn't working in testing. Microsoft tracked down the bug and added specific 
> code to Windows 95 that looks for SimCity. If it finds SimCity running, it 
> runs the memory allocator in a special mode that doesn't free memory right 
> away. That's the kind of obsession with backward compatibility that made 
> people willing to upgrade to Windows 95.

If you like that, Raymond Chen’s oldnewthing is a great source of Microsoft 
technical war-stories (https://blogs.msdn.microsoft.com/oldnewthing/). But 
anyway, nobody wants that kind of headache, and then having to maintain those 
hacks for who-knows-how-long? That’s why they’re so strict about using official 
APIs and documented behaviour - because if you don’t, you’ll have to choose 
between breaking software and making users unhappy, or maintaining a collection 
of hacks to present the illusion of the old, never-intended-to-be-final 
behaviour.

Karl___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] executing a string

[Saagar Jha via swift-evolution]

Here’s

how selectors in Swift work, based on this

proposal. Swift’s selectors are a lot safer than Objective-C’s.

> > > > > One of the major security flaws of Obj C is > > the ability to
convert a string into a selector, which > > permits using private methods
by constructing selectors > > at runtime long after the app store review
has been completed. > > Does Swift do away with that? I understand it
doesn't > > use selectors per se but is there an analogous mechanism? > > >
> >

--

swift-evolution mailing list swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

On Thu, Jul 14, 2016 at 08:49 Ford Prefect via swift-evolution
swift-evolution@swift.org wrote:


-- 
-Saagar Jha
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] executing a string

[Tino Heth via swift-evolution]

Turning strings into selectors is a powerful feature as well ;-) — but afaik, 
Swift doesn't use another sort of special dispatch besides what is known from 
other languages.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution