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?
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.
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 <swift-evolution@swift.org> 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
Here’s
<https://swift.org/blog/swift-2-2-new-features/#compile-time-checked-selectors>
how selectors in Swift work, based on this
<https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md>
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
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: mikeash.com: Friday Q&A 2009-03-27: Objective-C Message Forwarding
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 (The Old New Thing). 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
On 14 Jul 2016, at 17:48, Ford Prefect via swift-evolution <swift-evolution@swift.org> wrote:
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 <swift-evolution@swift.org<mailto:swift-evolution@swift.org>> 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 <swift-evolution@swift.org<mailto:swift-evolution@swift.org>> 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<mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org<mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution