OS X sandboxing flaw casts doubt on upcoming Mac App Store requirement

Posted:
in macOS edited January 2014
A newly-discovered security flaw in the sandboxing functionality of Mac OS X has prompted concerns over Apple's requirement that all applications submitted to the Mac App Store must implement sandboxing by March 2012. \t



Security research firm CoreLabs Research recently disclosed a potential vulnerability in Apple's desktop operating system, ArsTechnica reported on Friday.



Sandboxing provides a method for an operating system to restrict which system resources are available to an application. According to the security firm, vulnerabilities in the feature extend to the three latest releases of Mac OS X: Leopard, Snow Leopard and Lion.



"Several of the default pre-defined sandbox profiles don't properly limit all the available mechanisms and therefore allow exercising part of the restricted functionality," the vulnerability's description read.



In particular, an application without approved network access could send Apple events "to invoke the execution of other applications not directly restricted by the sandbox." The firm also noted that the issue resembles one reported by famed security expert Charlie Miller at the Black Hat Japan security conference in 2008. Apple apparently fixed the mentioned issue, but neglected to "modify the generic profiles."



Apple had originally required all submitted Mac App Store apps to support sandboxing by this month, but the company recently pushed the deadline back to March of next year.



"As of March 1, 2012 all apps submitted to the Mac App Store must implement sandboxing," Apple reportedly said in an email to developers, as noted by TUAW.



The Cupertino, Calif., company is implementing the policy in an effort to maintain security on the Mac App Store, but a number of developers have complained that the rule is overly restrictive. The recently revealed vulnerability has only added fuel to their cause, as some assert that the sandbox requirement is flawed because sandboxing itself is vulnerable.



Some have also taken issue with how Apple has handled the news of the vulnerability. Core notified Apple of the issue in September to allow ample time for it to address the issue before going public with the problem. According to the firm, Apple responded that it "does not see any actual security implications" because documentation for the NoNetwork sandbox profile does not actually promise that Apple events will be blocked.



Core replied that the vulnerability allows Apple events to eventually execute sockets-based networking, which is supposed to be blocked by the NoNetwork sandbox profile. Apple then agreed to modify its documentation to make note of the issue.



While the Mac App Store is only one option for adding software to a Mac, some critics of Apple's restrictions have voiced concerns that the company could move toward the iOS model. The App Store on iOS is currently the only legitimate source for applications on the mobile OS.



For its part, Apple has moved its own software onto the Mac App Store, even going so far as to launch Mac OS X Lion exclusively on the store in July. The company also released Final Cut Pro X in June only on the Mac App Store.
«1

Comments

  • Reply 1 of 35
    asciiascii Posts: 5,941member
    That's the trouble with OSes that allow IPC such as AppleScript, or entire other frameworks like Java: the whole thing just becomes a complicated mess for security. Why not have one OS-framework (Cocoa), isolated processes, and if that isn't enough to write your program, then you're not much of a programmer.
  • Reply 2 of 35
    Quote:
    Originally Posted by ascii View Post


    That's the trouble with OSes that allow IPC such as AppleScript, or entire other frameworks like Java: the whole thing just becomes a complicated mess for security. Why not have one OS-framework (Cocoa), isolated processes, and if that isn't enough to write your program, then you're not much of a programmer.



    Really!?
  • Reply 3 of 35
    swiftswift Posts: 436member
    Oh, I guess it would be because Apple has until March to plug security holes. Should be enough time.
  • Reply 4 of 35
    How is an imperfect implementation of a sandbox raise concerns over using a sandbox vs not using one at all?



    Apple has several months to address the issue, and just like browsers/javascript/jvm/flash/etc there will be problems with the sandboxing technology, but the point is that it can safely be fixed and improved as problems are discovered because the whole model is about the developer stating what they expect their limits to be (even if enforcement isn't perfect) and the sandbox attempting to match that as closely as possible.
  • Reply 5 of 35
    Quote:
    Originally Posted by Axcess99 View Post


    How is an imperfect implementation of a sandbox raise concerns over using a sandbox vs not using one at all?



    False sense of security?
  • Reply 6 of 35
    asciiascii Posts: 5,941member
    Quote:
    Originally Posted by Jacksons View Post


    Really!?



    Yes, it's a trade off. You can pile features on top of features but don't expect security at the end of it. Security requires that you think of every single edge case before "they" do, and that is only realistic in an environment of max simplicity.
  • Reply 7 of 35
    Quote:
    Originally Posted by ascii View Post


    Yes, it's a trade off. You can pile features on top of features but don't expect security at the end of it. Security requires that you think of every single edge case before "they" do, and that is only realistic in an environment of max simplicity.



    And what does that have to do with "not being much of a programmer?" How do you go about building utilities that need access to things outside the sandbox?
  • Reply 8 of 35
    Quote:
    Originally Posted by AppleInsider View Post


    Apple responded that it "does not see any actual security implications"



    Wasn't Charlie Miller that guy that Apple just kicked out of the iOS App Development program for demonstrating flaws within Apple's software? Or was it somebody else?



    Regardless, the faux app that was put in to the iOS app store that was used to demonstrate how one could hack there way, leaves little confidence in Apples response that it "does not see any actual security implications"



    Let's let Charlie Miller or who ever it was that Apple just kicked out of their iOS App Developer program decide!

    /

    /

    /
  • Reply 9 of 35
    So, because there's a potential flaw, the entire plan should be dumped? If that's the standard that is to be applied, no software would ever be written at all. In any case, just because Apple hasn't done something according to some 3rd party's timeline, or hasn't agreed with something some 3rd party claims, doesn't mean they aren't taking a look at it.
  • Reply 10 of 35
    Quote:
    Originally Posted by Rot'nApple View Post


    Wasn't Charlie Miller that guy that Apple just kicked out of the iOS App Development program for demonstrating flaws within Apple's software? Or was it somebody else?



    He was kicked out for violating the developer rules in submitting an app that ran undocumented code, and was created with potential malicious intent. Just because he says he never ran the code doesn't mean he didn't or wouldn't have.
  • Reply 11 of 35
    asciiascii Posts: 5,941member
    Quote:
    Originally Posted by Jacksons View Post


    And what does that have to do with "not being much of a programmer?" How do you go about building utilities that need access to things outside the sandbox?



    That doesn't even make sense. You don't access things outside your sandbox, you define your sandbox such that it gives you everything you need and nothing more. Do you even know the difference between app sandbox and universal App Store restrictions?
  • Reply 12 of 35
    blastdoorblastdoor Posts: 1,929member
    It seems to me that there are several issues in play here. First, there's a definitional issue -- how does apple want to define "sandboxing" for OSX? Second, there's the issue of a tradeoff between security and functionality in choosing that definition of "sandboxing". Third, there's the issue that unlike for iOS, OSX does allow apps that are not sandboxed.



    Put these three issues together than you can have a bunch of people talking past each other.



    It is not at all hard to imagine the practical utility of an AppStore application that can send AppleEvents to a non-AppStore application. And it's not at all hard to imagine the potential for bad things happening from a security perspective.



    It seems to me that Apple has a tricky path to navigate in weighing these tradeoffs. And I'm sure we can expect attention-seekers to yell "security flaw!!" every time Apple chooses a tradeoff that favors functionality over security. But I congratulate Apple for being willing to navigate that tricky path. It's ultimately going to be a benefit to users to have better security (albeit not perfect) while still maintaining the higher level of functionality that we expect from OSX relative to iOS.
  • Reply 13 of 35
    mstonemstone Posts: 11,510member
    Quote:
    Originally Posted by ascii View Post


    Why not have one OS-framework (Cocoa), isolated processes, and if that isn't enough to write your program, then you're not much of a programmer.



    I think the implication is that Apple is moving closer to only allowing you to install applications from the App store. If a programmer cannot write software and install it on a computer without Apple's approval, then that wouldn't be much of a computer.
  • Reply 14 of 35
    hmurchisonhmurchison Posts: 12,271member
    Quote:
    Originally Posted by mstone View Post


    I think the implication is that Apple is moving closer to only allowing you to install applications from the App store. If a programmer cannot write software and install it on a computer without Apple's approval, then that wouldn't be much of a computer.



    I disagree. I think Apple is mainly saying "if you want to have access to the MAS you need to Sandbox your app and if you want iCloud you need to sign your app"



    Apple's smart in understanding that they don't want the type of security issues that are plaguing Windows. An ounce of prevention beats a pound of cure.
  • Reply 15 of 35
    Quote:
    Originally Posted by Jacksons View Post


    False sense of security?



    Not so. No security measure is 100% impenetrable but that doesn't mean we throw caution to the wind. Sanboxing is very secure and we're better with it than without it although I am concerned about limiting the functionality in software for the sake of better security.



    Personally I believe Apple should improve it's techniques in discovering rogue apps before they are placed in the Mac App store rather than this blanket approach which could impact the features we enjoy now in certain apps. I highly doubt Apple will eventually adapt the same app model in iOS for Mac OS X, meaning software can only be downloaded through the Mac App Store.
  • Reply 16 of 35
    rcfarcfa Posts: 772member
    A sandbox is supposed to restrict a single process. The "flaw" does not allow the process restricted to access the network, it allows only the restricted process to communicate with another process that is potentially not restricted from accessing the network.



    The whole point of sandboxing is that you run the vast part of a program in a non-privileged environment, such that if that binary of that process is compromised by malware or bugs, it cannot directly do any significant harm.



    However, parts of a program may need network connectivity. The way to achieve that is not to ask for the entire program to have network privilege, the way to do this is to have a companion process that has network access privilege. The program for that companion process is kept small (and therefore relatively bug-free), and communicates by IPC with the main process to do the required network communication.



    As such, not only is this no security flaw, it is working as intended and designed. At most one can blame Apple for having a potentially misleading documentation, which according to the article, Apple fixed. Done deal.



    The point of sandboxing is not that it prevents all potential security issues, nor is it designed to be a security system in and by itself. It's only intended to contain the amount of damage a particular bug or exploit can have on the system. It's a second line of defense, not the primary security mechanism.



    In this particular case, even if the process were compromised, all it can do is call a second process. For any damage to be done, that second process would have to be "complicit" in doing actual harm, i.e. two processes need to be compromised before any security implications start to arise, and that means a lot more obstacles for bugs and malware to overcome before damage happens.



    Mission accomplished.
  • Reply 17 of 35
    Macs are fully unix-compliant and used in education and research. Apple will not restrict all software to the Mac App Store. However, the MAS does give a reliable place to get trusted software, do updates, etc. Apple will improve their security model in time and as best it can. We certainly don't have self-replicating viruses and patch Tuesday's on the mac yet!
  • Reply 18 of 35
    hirohiro Posts: 2,663member
    Quote:
    Originally Posted by internetworld7 View Post


    Not so. No security measure is 100% impenetrable but that doesn't mean we throw caution to the wind. Sanboxing is very secure and we're better with it than without it although I am concerned about limiting the functionality in software for the sake of better security.



    Personally I believe Apple should improve it's techniques in discovering rogue apps before they are placed in the Mac App store rather than this blanket approach which could impact the features we enjoy now in certain apps. I highly doubt Apple will eventually adapt the same app model in iOS for Mac OS X, meaning software can only be downloaded through the Mac App Store.



    I think it's not a bad tradeoff to submit your app to sandboxing for the access to the App Store. Devs still get full unfettered API access if they want to sell from third party storefronts.
  • Reply 19 of 35
    Quote:
    Originally Posted by Hiro View Post


    Devs still get full unfettered API access if they want to sell from third party storefronts.



    Ah, there's an interesting point. People don't really have any reason to whine about the Mac App Store unless THAT stops being true.



    I would raise a fuss about that, that's for sure. I don't even make OS X applications and I'd raise a fuss.
  • Reply 20 of 35
    a_greera_greer Posts: 4,594member
    Ben Franklin said "He who sacrifices freedom for security deserves neither." ...





    This whole sand boxing movement that started with IOS and is now spreading to Mac and even Windows is a bit troubling. if someone makes an app that the gatekeepers dont like for whatever reason cant sell their apps to the majority of users...



    For people who see no trouble with this I give you the case of Camera+ This application used teh volume button as a shutter, Apple pulled the app, destroying the developers ability to profit from their otherwise exceptionally cool application, then, like 9 months later in ios 5 we see volume button used as a shutter control! This kind of crap kills innovation because there is a risk of the platform owner killing your product and stealing it, not just competeing with it, but killing the competition completely!



    I am not for government control and regulation, but really I think there needs to be a computing opennes regulation that basically states that consumers have the right to side load applications...that is users or owners of the phones or PCs cant be stopped by the maker from installing software that the device maker doesnt like.
Sign In or Register to comment.