So many holes patched in 4.2

[Schtibbie]

Wirelessly posted (Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_2_1 like Mac OS X; en-us) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8C148 Safari/6533.18.5)

http://lists.apple.com/archives/security-announce/2010/Nov/msg00003.html

Am I the only one made uneasy by so many critical "attacker could take over device" security holes, such as this big list they fixed in 4.2?

Doesn't this point to a deep architectural issue that so many holes COULD exist? I'm not impressed they patched the holes. Other people found the holes for them. I'm thinking the os should be inherently tighter.

 

[jacollins]

Most of those are Webkit errors. Probably items found in the usual Webkit development and then brought back into the Apple version. Just goes to show, the Interwebs are a dangerous place to be...

 

[SomeDudeAsking]

Wirelessly posted (Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_2_1 like Mac OS X; en-us) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8C148 Safari/6533.18.5)

This also concerns me. The fact that Apple does zero security or sandboxing is just asking for trouble.

 

[ianray]

This also concerns me. The fact that Apple does zero security or sandboxing is just asking for trouble.

Assuming no irony or sarcasm in your comment, then even a little research would easily demonstrate that there is indeed in-house security testing[1] -- and that iOS Apps are indeed sandboxed[2].

1. Search for "credit:Apple" in the 'About the security content' documents
2. The Application Runtime Environment

That's not to say, of course, that things could be much, much better

 

[ItsJustafnPhone]

not really, its always a cat and mouse game between developers and hackers

EVERY OS has always needed to be patched/updated to deal with new security holes/hacks


Look at windows XP, even to this day they are releasing security updates

 

[SomeDudeAsking]

Wirelessly posted (Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_2_1 like Mac OS X; en-us) AppleWebKit/533.17.9 (KHTML, like Gecko) Mobile/8C148)

This also concerns me. The fact that Apple does zero security or sandboxing is just asking for trouble.

Assuming no irony or sarcasm in your comment, then even a little research would easily demonstrate that there is indeed in-house security testing[1] -- and that iOS Apps are indeed sandboxed[2].

1. Search for "credit:Apple" in the 'About the security content' documents
2. The Application Runtime Environment

That's not to say, of course, that things could be much, much better

It's hard to say whether Apple does any security testing at all. It's all reactionary, nothing is proactive. And iPhone apps are not sandboxed. Sandboxing is the ability to restrict privileges of malicious code that has successful executed an exploit. What Apple calls sandboxing is actually Steve Jobs marketing department.

 

[ianray]

It's hard to say whether Apple does any security testing at all. It's all reactionary, nothing is proactive.

Really? All reactionary? And your evidence for this is what exactly?

And iPhone apps are not sandboxed. Sandboxing is the ability to restrict privileges of malicious code that has successful executed an exploit. What Apple calls sandboxing is actually Steve Jobs marketing department.

Marketing, really? That there is a an execution-level application sandbox is beyond dispute (or do you disagree?!).

You are of course correct that exploits allow malicious code to be run -- the 'drive-by' jailbreak using Safari to visit a malicious website was ample proof of that

 

[SomeDudeAsking]

Wirelessly posted (Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_2_1 like Mac OS X; en-us) AppleWebKit/533.17.9 (KHTML, like Gecko) Mobile/8C148)

Show me the documentation where Apple actually says they have sandboxing.

 

[ianray]

That there is a an execution-level application sandbox is beyond dispute (or do you disagree?!).

Show me the documentation where Apple actually says they have sandboxing.

As already noted, application-level sandboxing: The Application Runtime Environment.

Perhaps we disagree over semantics?

 

[Schtibbie]

Wirelessly posted (Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_2_1 like Mac OS X; en-us) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8C148 Safari/6533.18.5)

It's hard to say whether Apple does any security testing at all. It's all reactionary, nothing is proactive.

Really? All reactionary? And your evidence for this is what exactly?

And iPhone apps are not sandboxed. Sandboxing is the ability to restrict privileges of malicious code that has successful executed an exploit. What Apple calls sandboxing is actually Steve Jobs marketing department.

Marketing, really? That there is a an execution-level application sandbox is beyond dispute (or do you disagree?!).

You are of course correct that exploits allow malicious code to be run -- the 'drive-by' jailbreak using Safari to visit a malicious website was ample proof of that

I read that apple document that mentions sandboxinf but it also points out that if your app suffers from a buffer overflow or something, bad-guy code will run. And remember that drive-by exploit that could jailbreak the entire phone (if it had been used in a nefarious way). That's an indication that the low-level architecture let's the phone execute pretty much anything if that "anything" gets itself inserted in the right place.

 

[jdong]

How do you think a sandbox works?

If a successful buffer overflow is performed, you get the privileges of the SANDBOXED APPLICATION. Then, you must launch another exploit from within the sandbox using the facilities available to you to gain root.


For jailbreakme, the initial buffer overflow was in FreeType which gained access to Safari's domain. Then, an ioctl was used to the bpf kernel module which exploited a second vulnerability in the kernel to gain full system access.

Applications on iOS are sandboxed via the same TrustedBSD-based mandatory access control framework (Seatbelt) that was ported to OS X back in the days of Leopard. This is a kernel enforced sandbox similar to SELinux/AppArmor, but suffers from the same caveats. The only way to stop the second attack vector is to severely restrict what applications inside a sandbox are allowed to do on the system, which means further placing restrictions on what app developers are allowed to do via the iOS SDK, which clearly nobody wants.


(BTW, most jailbreak apps do not run inside any sandbox. Take that information however you like.)