OS X sandboxing flaw casts doubt on upcoming Mac App Store requirement
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.
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.
Comments
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!?
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.
How is an imperfect implementation of a sandbox raise concerns over using a sandbox vs not using one at all?
False sense of security?
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.
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?
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!
/
/
/
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.