So many holes patched in 4.2

Discussion in 'iPhone' started by Schtibbie, Nov 23, 2010.

  1. Schtibbie macrumors 6502

    Joined:
    Jan 13, 2007
    #1
    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.
     
  2. jacollins macrumors 6502a

    Joined:
    Jun 19, 2010
    #2
    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...
     
  3. SomeDudeAsking macrumors 65816

    Joined:
    Nov 23, 2010
    #3
    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.
     
  4. ianray macrumors 6502

    Joined:
    Jun 22, 2010
    Location:
    @
    #4
    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 :D
     
  5. ItsJustafnPhone macrumors 6502a

    Joined:
    Jul 26, 2010
    #5
    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
     
  6. SomeDudeAsking macrumors 65816

    Joined:
    Nov 23, 2010
    #6
    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)

    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.
     
  7. ianray macrumors 6502

    Joined:
    Jun 22, 2010
    Location:
    @
    #7
    Really? All reactionary? And your evidence for this is what exactly?

    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 :D
     
  8. SomeDudeAsking macrumors 65816

    Joined:
    Nov 23, 2010
    #8
    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.
     
  9. ianray macrumors 6502

    Joined:
    Jun 22, 2010
    Location:
    @
    #9
    As already noted, application-level sandboxing: The Application Runtime Environment.

    Perhaps we disagree over semantics?
     
  10. Schtibbie thread starter macrumors 6502

    Joined:
    Jan 13, 2007
    #10
    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)

    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.
     
  11. jdong macrumors member

    Joined:
    Nov 24, 2008
    #11
    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.)
     

Share This Page