Rosyna Keller

@rosyna @mjtsai Or touch that file or whatever. But notice that Spotify isn't malicious, in the example it's hijacked and becomes malicious

@drewthaler @mjtsai That actually happened to Twitter for Mac OS X a few years ago due to an image parsing bug.

@rosyna @drewthaler Even for things that would never be approved in the Mac App Store, so that every Developer ID app can be sandboxed.

@mjtsai @drewthaler That's exactly how sandboxing works today on Mac OS X.

@rosyna @drewthaler And it doesn’t, AFAIK, address APIs that area available but behave differently when the app is sandboxed.

@mjtsai @drewthaler Which such APIs do that? There is a list of "temporary extensions" that are only temp for MAS https://developer.apple.com/library/mac/documentation/Miscellaneous/Reference/EntitlementKeyReference/Chapters/AppSandboxTemporaryExceptionEntitlements.html#//apple_ref/doc/uid/TP40011195-CH5-SW1 …

@rosyna @drewthaler For example, -[NSWorkspace openFile:]. The rules have changed several times w/ OS versions and are not documented.

@rosyna I’m familiar with that, but it seems like a relatively small risk compared with plain bugs (like Adobe’s) and malicious apps.

@mjtsai Small risk? It's the exploit type used the *most* because they can exploit common, trusted applications.

@rosyna In terms of actual problems affecting Mac users, I read a lot more stories about bugs and bad apps than this type of exploit.

@mjtsai I see the exact opposite. http://www.livehacking.com/tag/photoshop/  there are very few attacks that don't use RCEs or hijack an otherwise legit app.

@rosyna @mjtsai Rosyna's right. If Spotify has a remote code exploit, sending a maliciously crafted packet could inject code (remotely!)