Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Blizzard Exempt from iOS and MacOS Security Sandbox

twitter.com

Post reply on HN
Print view View original

61–69 of 69 posts

Re: Blizzard Exempt from iOS and MacOS Security Sandbox

#61

Post by stevehawk »

Jtsummers wrote: post #53
atomic_lock wrote: post #18

Earlier quoted context omitted.

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.

How do you own a bug? Was the bug something in iOS? Wouldn't that be Apple's bug? A sibling post said they took his code. That's a fair complaint, was it clear when they saw it that it was not code that they could reuse?

Actually, I believe that's the next (or current) big debate in software due to privacy/search warrants/recent FBI vs Apple iPhone unlock debacle.

Re: Blizzard Exempt from iOS and MacOS Security Sandbox

#62

Post by [deleted] »

AimHere wrote: post #19
chillacy wrote: post #2

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) * Can anyone set…

Okay, nitpick time. Your story about the game is surely wrong. Rollercoaster Tycoon was developed for Windows 95/98. Perhaps you meant it's a later version of Windows, or the game's spiritual predecessor, Theme Park, which ran in DOS.

[deleted]

Re: Blizzard Exempt from iOS and MacOS Security Sandbox

#63

Post by chillacy »

brynedwards wrote: post #22
AimHere wrote: post #19

Earlier quoted context omitted.

Okay, nitpick time. Your story about the game is surely wrong. Rollercoaster Tycoon was developed for Windows 95/98. Perhaps you meant it's a later version of Windows, or the game's spiritual predecessor, Theme Park, which ran in DOS.

Probably SimCity, there's a bit about Microsoft adding a workaround for a bug in the game in this article http://www.joelonsoftware.com/articles/fog0000000054.html Edit: Maybe not this since it's unrelated to virtual memory but it's along the same lines, going to some lengths to keep software compatible

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!

Re: Blizzard Exempt from iOS and MacOS Security Sandbox

#64

Post by tomlogic »

LeifCarrotson wrote: post #59
JoachimSchipper wrote: post #56

Earlier quoted context omitted.

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. And that string is the Blizzard identifier: https://www.virustotal.com/en/file/bd…

Not odd to include the null terminator if you want to ensure another string is "equal to", not just "starts with" the string you're comparing it to.

Re: Blizzard Exempt from iOS and MacOS Security Sandbox

#65

Post by mzs »

tomlogic wrote: post #64
LeifCarrotson wrote: post #59

Earlier quoted context omitted.

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. And that string is the Blizzard identifier: https://www.virustotal.com/en/file/bd…

Not odd to include the null terminator if you want to ensure another string is "equal to", not just "starts with" the string you're comparing it to.

Dang it, I counted the \0 but miscounted the characters in the string.

Re: Blizzard Exempt from iOS and MacOS Security Sandbox

#66

Post by [deleted] »

protomyth wrote: post #41
spacecowboy_lon wrote: post #33

Earlier quoted context omitted.

No Sysadmin shoud be playing games on the systems he/she uses for admin work.

Oh, I so wish that were true. 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.

[deleted]

Re: Blizzard Exempt from iOS and MacOS Security Sandbox

#67

Post by dkuntz2 »

briane80 wrote: post #57
spacecowboy_lon wrote: post #33

Earlier quoted context omitted.

No Sysadmin shoud be playing games on the systems he/she uses for admin work.

I once heard a (probably apocryphal) story of a developer who had been playing Doom installed on a server. The sysadm caught him playing it and promptly unistalled the game. However the important business application hosted on the server then stopped working and no one could figure out why. Nothing would work... even after lots of debugging, error log analysis and redeploying. The developer suggested installing Doom…

If someone tells you that story, they have to explain why.

Re: Blizzard Exempt from iOS and MacOS Security Sandbox

#68

Post by nextweek2 »

dkuntz2 wrote: post #67
briane80 wrote: post #57

Earlier quoted context omitted.

I once heard a (probably apocryphal) story of a developer who had been playing Doom installed on a server. The sysadm caught him playing it and promptly unistalled the game. However the important business application hosted on the server then stopped working and no one could figure out why. Nothing would work... even after lots of debugging, error log analysis and redeploying. The developer suggested installing Doom…

If someone tells you that story, they have to explain why.

It was actually a common problem back in the day.

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.

Re: Blizzard Exempt from iOS and MacOS Security Sandbox

#69

Post by cyphar »

personjerry wrote: post #8
Aissen wrote: post #6

Tweet has been deleted: https://twitter.com/i0n1c/status/738258436161449984 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…

I Google'd and here is one result, showing at least one theoretical security vulnerability of access(): http://stackoverflow.com/a/14333217/3650441 If an attacker knows what files Blizzard is calling access() on, they could likely use this exploit and execute arbitrary code.

> I Google'd and here is one result, showing at least one theoretical security vulnerability of access(): http://stackoverflow.com/a/14333217/3650441

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.

Post reply on HN