> On 14 Jul 2016, at 17:48, Ford Prefect via swift-evolution
> <swift-evolution@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@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
