Sandbox Workaround for Blizzard Apps
Stefan Esser posted a screenshot of code where it looks like Apple’s OSes skip a sandbox check if the code is running under Blizzard’s team identifier. Stefan Esser:
I wonder why the iOS sandbox omits certain sandbox checks if code is signed by Blizzard Entertainment Inc.
It looks like if you are signed by blizzard you can execute whatever executables you find on an iOS device.
Luckily we all know that Blizzard Games never have remote vulnerabilities :-)
This struck people as dangerous and unfair, which perhaps speaks to how much faith developers have in Apple fairly enforcing its own rules. However, it turns out that it’s not actually a sandbox exception but rather a workaround for a crashing bug.
POM:
This path is for the
access()call, not for the actual enforcement.
But it doesn’t mean they can execute, it means we make them believe they could.
Practically speaking, all sandboxing rules still apply to Blizzard apps; workaround doesn’t allow operations that other apps can’t do too.
And Blizzard has fixed their updater, so the workaround shouldn’t be needed in next update.
My takeaway is that Apple will go to extraordinary lengths to avoid crashers in super-popular apps, even when it’s entirely the app’s fault.
2 Comments RSS · Twitter
"My takeaway is that Apple will go to extraordinary lengths to avoid crashers in super-popular apps, even when it’s entirely the app’s fault." - I guess that's the single metric that Apple uses to determine the quality of the software.
Reminds me of how Windows 95 changes its memory allocation behavior if SimCity is running. http://www.joelonsoftware.com/articles/fog0000000054.html
