Could they though? The way I understand the answer is that the security hole happens if a privileged user which manipulates files for an unprivileged user calls access() and then open(). In this case Blizzard's application is an unprivileged user, thus even if you manage to insert yourself between the calls, you will only be able to make Blizzards application execute code. The application still runs in a sandbox so you will not get that far.
That is not a security flaw in access, it's a potential security flaw in administrative processes that use access() and then operate on files. There's a hole there where someone could swap the file that they are trying to open. That's just a reason to not use that API (there are the at APIs for a reason). But since Blizzard processes are (presumably) not running as root, there isn't a security flaw.
> If an attacker knows what files Blizzard is calling access() on, they could likely use this exploit and execute arbitrary code.
The ability to maybe* get a program to do some file operations on a different file than it checked against is miles away from code execution, unless the program's job is to execute code from a file.
The existence of the inherent time-of-check versus time-of-use hole with access is a several steps away from "execute arbitrary code". The example given presumes you are using access on crontab (and that the app can write to it).
You're looking at the output of a disassembler, not at the original source code. It probably reads something boring like sizeof(Identifier) in the original.
That's exactly what it is. The third parameter to memcmp is the length of the buffers to be compared - "G847MC6JZ5", the string being compared, has a length of 11 characters (including the null terminator, which is a little odd). 11 is B in hex, and is stored as an unsigned Long Long, so the representation in the disassembler is 0xBuLL.
I recall a story of how the windows 95 team (or the like) was crazy dedicated to backwards compatibility, so they had a check to see if the user was running Roller Coaster Tycoon and if so, disabled virtual memory so the game would run.
Though I'd like to know more details, like:
* Why does blizzard need to run in the sandbox on Mac OS X? The app sandbox is opt-in (though required for App Store apps)
Here's the story Joel Spolsky wrote some time ago[1]:
> Windows 95? No problem. Nice new 32 bit API, but it still ran old 16 bit software perfectly. Microsoft obsessed about this, spending a big chunk of change testing every old program they could find with Windows 95. Jon Ross, who wrote the original version of SimCity for Windows 3.x, told me that he accidentally left a bug in SimCity where he read memory that he had just freed. Yep. It worked fine on Windows 3.x, because the memory never went anywhere. Here's the amazing part: On beta versions of Windows 95, SimCity wasn't working in testing. Microsoft tracked down the bug and added specific code to Windows 95 that looks for SimCity. If it finds SimCity running, it runs the memory allocator in a special mode that doesn't free memory right away. That's the kind of obsession with backward compatibility that made people willing to upgrade to Windows 95.
Software would ship with shared DLL's, uninstalling an application would usually have a knock on effect.
MS-DOS was used a lot for small office servers. Whilst Windows NT4 was growing in popularity, it was an expensive option for firms. Plus it was hard to play games on NT4 due to memory protection issues.
A fable of Doom being needed to run a server in today's environment is ridiculous, however back then things were a lot less mature. The issue wasn't limited to just games. Any application with shared files was a nightmare, normally you just renamed files, rebooted, then if things worked you could delete the files.
Heck, back in the day I caught someone (thankfully not at the place I worked) running a game (some FPS) server on their exchange server box. Running Steam is well within the realm of possibilities.
At one building, friends and I rigged every machine to have hidden copies of Alien vs Predator and Everquest. I modified the system software to intercept keystrokes before they got to the game. One command crashed video, audio, and then whole system. I also set others to randomly crash around same time people walked in to supervise what was going on. Friends and I griped our machines were down about every day. Person in charge ordered us to keep using them and get no replacements because that served wiseasses like us.
Oh, yes it did. Served us well. (evil grin)
Note: Also embedded web browser into our business application in development-mode only. The GUI forms and such. Policy had IE locked down but embedded browser still worked lol. So, fast coders got the job done quickly then were bullshitting around on Internet till someone approached. One key stroke and back to boring UI testing. ;)
Since I alternate between developer and system admin jobs[1], you message hits me both as "Righteous" and "Dammit you $^%& developer". I am so conflicted.
1) welcome to the wonderful and horrible world of a journeyman in the middle
I try to stay in those grey areas where people sort of want to stop me but find my antics too useful or entertaining. :) Far as that setup, sysadmin was a pal of mine who hated the unreliable crap he had to manage. He had already made sure all the work sync'd to their Novell network's central storage. I also told people to make CD backups with the CD burners on the machines. With my help, people just lost time here and there with him not having to do any extra work.
So, sysadmin was thanking me for helping him deal with machines that were inexplicably always crashing "because Acer machines are garbage." You feel more or less conflicted now? :P
Sadly, these days, the Acer machines are the least problematic of the machines (looking at you H "100 hard drive failures out of 120 machines" P) I have to deal with.
[edit] I feel about the same, as a system admin, I get bit in the /\$$ way too often by good intentions. I hear they pave a road with them (I think I worked there).
You're right that's the story I was thinking of. I didn't remember all the details though, I guess I knew some old version of windows, some simulation game, and something involving memory. Turns out the actual details got mixed up in my head!
There are a lot of checks for specific apps in the Cocoa framework. It's pretty much what the undocumented CFExecutableLinkedOnOrAfter() is for (sometimes called in conjunction with a check for a specific bundle name).
When I worked at Apple before Steve came back there were tons of checks in MacOS for particular versions of apps, especially for Microsoft Word and Excel, working around their buggy behavior (or their workarounds for Apple's buggy behavior, a vicious cycle). While I have no idea if this person knows anything it would not be surprising.
Yeah. We port Windows applications to Mac at work. A couple years ago when Apple switched on a more stringent code signing requirement, we found many of our ports worked without the updated code signing, while some others would warn about an invalid signature. It was clear there was some internal whitelist for old, known signatures which had picked up many, but not all, of our ports. User friendly, I guess, but pretty ugly.
What's the alternative, users wait for some porting house to finally get around to releasing an update to be compatible? Oh, you don't have it in your contract to do that work, and the parent company isn't keen to pay you to do it, sorry users.
Maybe your update is now a paid update, so people can either pony up, or not upgrade, or abandon your software. Hello CS6. Was your latest update $10k? *major enterprise developer thanks you for the multi million dollar windfall your OS update gave them by forcing all their deploys to pay for a compatibility update, caused by "you".
Being a major platform developer is full of hard decisions balancing user experience and security, performance and future looking direction. It's not a problem most developers have to concern themselves with in your average app.
Horribly misleading title here. Blizzard is exempt from one tiny piece of the sandbox, namely the sandboxing around access(). Which is nearly irrelevant.
According to tips John Gruber got Blizzard had a bug in one of their updaters that would crash due to the sandbox. Apple put in a check to allow the call the updater was making to succeed, but didn't actually grant any access that the updater didn't have before.
Apple shipped an update to the sandbox and included a small, harmless fix to avoid issues in popular 3rd party software. Microsoft does this all the time.
Also according to those same birdies, the Blizzard fixed the bug a while ago so the 'exemption' may be removed soon as it's no longer necessary.
I'd speculate that access() was inadvertently left open before, Apple subsequently sandboxed it, this broke Blizzard, and Apple put in an exemption for them to avoid breaking millions of people's games.
This guy published an app that did jailbreak detection and some other stuff on the App Store, it was taken down, and has been rambling since then in a very very childish way about stuff like this: https://twitter.com/i0n1c/status/738286205708738560
Truth is--he knew what was going to happen, so this looks just like another excuse to rant.
He is known in the jailbreak scene as someone who cannot stay serious - he's always involved in some kind of drama.
If I recall correctly, the pangu dev team attended some of his sessions about iOS hacking and used this knowledge to create a publicly available jailbreak tool. He then started to rant about how they "stole" his technologies on twitter (see for example https://twitter.com/i0n1c/status/481020166483238912).
The problem at the time was that they had used his bug that he gave away only for training purposes to the people attending his class.
After the first release, pangu replaced his bug by one of theirs (and both bugs were fixed by apple in a subsequent iOS release.) He probably had to spend some time finding a new bug to use in his classes so it's understandable to be pissed.
I deleted the tweet with the picture of the sandbox because people start hyping it up without linking the clarification.
And the "clarification" tweet: https://twitter.com/i0n1c/status/738084828202053633
For those late to the party: the sandbox bypass exception for Blizzard only affects the access() family of syscalls - probably harmless
Edit: Original tweet screenshot http://imgur.com/c8RnYjo (it's still in Google cache… for now).