Mac OS X Sandbox Security Hole Uncovered 155
Gunkerty Jeb writes "Researchers at Core Security Technologies have uncovered a security hole that could allow someone to circumvent the application sandbox restrictions of Mac OS X. The report of the vulnerability, which affects Mac OS X 10.7x, 10.6x and 10.5x, follows Apple's announcement earlier this month that all applications submitted to the Mac App store must implement sandboxing as of March 1, 2012. Sandboxing, Apple has argued, limits the resources applications can access and makes it more difficult for malware to compromise systems. Researchers at Core however revealed Nov. 10 that they had warned Apple in September about a vulnerability in their sandboxing approach. According to Core's advisory, several of the default predefined sandbox profiles fail to 'properly limit all the available mechanisms.' As a result, the sandboxing restrictions can be circumvented through the use of Apple events."
Nothing to see here (Score:2, Informative)
This is a fake story about a fake hole. The "vulnerability" is that some sandbox profile, called "no-network", which isn't part of App Sandbox (a totally different sandbox technology, that will be required for apps on March 2012), but rather part of the legacy sandbox technology that was unused by 3rd party developers, only prevents network access. Yes, the no-network profile only prevents network access.
It's sad what's happened to Core Security in the past year or so.
Re:Put off requiring sandboxing (Score:0, Informative)
No, this is unrelated to the upcoming Sandbox requirements. This is not related to the iOS style sandbox requirements coming to the Mac AppStore at all... Just some garbage slashdot is spreading...
Broken concept (Score:5, Informative)
> Yes, the no-network profile only prevents network access.
1. no-network profile does *not* prevent network access see PoC [1]
2. The concept itself is broken, a sandbox which *only* prevents network access is completely useless. As a result network access is available to sanboxed applications.
[1] http://www.coresecurity.com/content/apple-osx-sandbox-bypass
Re:Steam can't run in a sandbox so apple can lock (Score:5, Informative)
Re:Nothing to see here (Score:5, Informative)
This is a fake story about a fake hole. The "vulnerability" is that some sandbox profile, called "no-network", which isn't part of App Sandbox (a totally different sandbox technology, that will be required for apps on March 2012), but rather part of the legacy sandbox technology that was unused by 3rd party developers, only prevents network access. Yes, the no-network profile only prevents network access.
It's sad what's happened to Core Security in the past year or so.
No, it's not a fake vulnerability. You should read the report (RTFR?).
The vulnerability is about how apple events can be used to bypass the sandboxing of an application, and in this particular case to gain unrestrained network access even though the app is tagged as "no-network". According to the report it can be used to bypass other restrictions too.
Re:Steam can't run in a sandbox so apple can lock (Score:5, Informative)
Customers were used to using drivers for scanners and etc, Apple took that away (effectively taking away the supported hardware) in Snow Leopard by breaking tons of them -- and never going back to fix them.
That's a third party problem, they need to support their own devices.
Customers were used to being able to run the PPC apps they had spent many dollars on... Apple took that away in Lion.
After they licensed very expensive software (Rosetta) to give you years to ween yourself of off PPC. I find it hard to imagine another OS vendor expending that much effort to do a seamless transition, even Bill Gates was impressed they pulled the intel switch off as seamlessly as Apple did. Ungrateful much ?
Customers have been used to apps (oh, I dunno, like Photoshop?) that were part of a system of apps that worked with their data, and Apple's taking that away within the bounds of the app store... and you think it's unlikely that this policy will spread outside the store?
Yes, they're not going to piss off a sizeable part of their customer base by making it impossible to run Photoshop or other Pro apps.
Buddy, Apple does what it wants -- they are *famous* for doing "teh stupidz" -- folders that don't nest under IOS, "wifi sync" that doesn't work under Leopard, a 4-year old native OS, while it does under XP, a ten year old non-native OS, they break the living hell out of IOS apps with just about every "upgrade", forcing developers to put up Yet Another Version of their app to correct for the incompatibilities...
Nested folders are a bad idea. People don't get nested hierarchies, spend some time watching non-geeks use computers and you'll see.
Leopard is down to 22% market share [theverge.com], XP only just dipped below 50% this summer [cnet.com]. There's a vast amount of XP machines out there, so unfortunately Apple should expend the effort to support them.
iOS is a platform that's developing at an enormous pace because mobile is so competitive and fast evolving. Change or get left behind is the name of the game, accumulating backwards compatibility cruft à la Windows would be deadly. That said I have not heard many complaints about breakages.
When your reasoning depends upon Apple doing things because customers have expectations, your reasoning is no better than a random guess. Apple makes roadmaps, has "visions", and then aims at them. Up until Leopard and IOS4, they were doing pretty well at hitting the target, though of course everyone wanted more. 10.6 and later, IOS5... these are huge bags of fail from several perspectives, most especially from the one you're using to make your assertion: Apple doesn't aim at keeping customers expectations static.
You obviously don't like iOS5 and Lion. There are a lot of us who would beg to differ.
Re:Steam can't run in a sandbox so apple can lock (Score:5, Informative)
Google Lion Adoption [lmgtfy.com]
Google Apple fora complaints [lmgtfy.com]
IOS5 feature not working [lmgtfy.com]
IOS app crashing [lmgtfy.com]
if apps are crashing and drivers don't work and features don't work and data is being lost and batteries are being consumed too fast at release time... they're not doing enough testing. Or is that too complex an idea for you to wrap your head around? Go read the apple support forums, for FSM's sake. Your profound ignorance is annoying.
Seriously? Ok, starting with Snow Leopard, there's a huge list [wikidot.com]. With Lion, I'm just going to point at them dropping the PPC emulator and see if you get it (keeping mind that there are many additional issues similar to those at the above Snow Leopard incompatibility monitor. But, you know, Google it [lmgtfy.com].)
Oh, Jeez, low-hanging fruit. I'm sorry (well, not very): [says nothing, points finger straight at you]
PS: Nothing I said was in the least an exaggeration or hyperbole: I'm an active Mac and IOS user and an OS X developer, and in these matters, I am reasonably well informed.
Defective by design (Score:1, Informative)
The fundamental approach is flawed. They chose to use a special "launchd" app to control this rather than adding the extra security to the OS kernel fork/exec. Hence, the security flaw that these researchers found.
In typical Apple fashion, after being notified, they're trying to sweep it under the rug by revising the developer documentation.
In the context Apple is using the term "sandboxing" here, this is a description of "fine grained" privileges. Linux has had fine grained privileges for years. Under Linux, they're called "capabilities". And it is the Linux kernel that does the enforcement, so that the type of "end around" that is the security flaw wouldn't work. Also, Linux already has selinux in the non-MLS mode that does much the same thing [and more].
Even if the Linux kernel developers had decided to use the "launchd" approach, they would have [in all probability] carried over the privilege list from the original sender of the message with the message itself and made it available to launchd so that launchd would not allow escalation of privilege level.
So, Apple ... Bad architecture and bad implementation of the architecture.
And, the literature on this has been around for decades.