[swift-evolution] executing a string

[Karl]

> On 14 Jul 2016, at 17:48, Ford Prefect via swift-evolution <swift-evolution at swift.org> 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160715/5e2642d7/attachment.html>