Slashdot Mirror
Revealed: Chrome Really Was Exploited At Pwnium 2013
Freshly Exhumed writes with an "inconvenient truth" as reported at Internet News: "Google Chrome running Chrome OS was hailed as being a survivor in the Pwnium/Pwn2own event that hacked IE, Firefox and Chrome browsers on Windows. Apple's Safari running on Mac OS X was not hacked and neither (apparently) was Chrome on Chrome OS. Google disclosed [Monday] morning that Chrome on Chrome OS had in fact been exploited — albeit, unreliably. The same researcher that took Google's money last year for exploiting Chrome, known publicly only as 'PinkiePie' was awarded $40,000 for exploiting Chrome/Chrome OS via a Linux kernel bug, config file error and a video parsing flaw." Asks Freshly Exhumed: "So, was it really Google Chrome, or was Linux to blame?"
Saying that Safari on MacOS "was not hacked" is slightly misleading. Nobody attempted to hack it, so contrary to some reports (and posts) it didn't survive anything.
Of course, but let's make it a polarized finger-pointing issue anyway! That's the American way!
Yeah, it's Chrome's fault for letting the untrusted code claim to be somewhat trusted. It's the kernel's fault for letting that questionable code become fully trusted. It reminds me of one of my favorite exploits where the kernel would helpfully drop core dumps in any directory the application said it was running from... including /etc/cron.d. A crafted program segfaulting could run a cron job to do aything as root. The attack didn't really exploit either program's faulty behavior, but rather the interaction between them.
You do not have a moral or legal right to do absolutely anything you want.
PinkiePie is one of the My Little Ponies. That handle's kinda cute, considering that that those that are pwn'd are sometimes called Pwnies and there are the Pwnie Awards. And all the bronies know that PinkiePie is the funniest of the ponies... not that I'd admit watching the show... wink, wink... ahem...
http://www.beanleafpress.com
the problem being that when apple sandboxes, it doesn't give the program the option to offer the user the ability to access files elsewhere or to raise its priviledges. It just defaults to "no" and there's no way to change it to "yes," even if you want to. So yes, it's evil because it assumes you'll never be smart enough to make the choice "yes" instead of "no."
Total nonsense. Apple's approach to sandboxing is centered around giving users the very power you claim they're denying. Say a user wants to open a file in a sandboxed app, and that file doesn't reside inside the app's private storage area (the isolated chunk of filesystem where it is free to create/open/delete files at will). The user uses the "open" command from the menu or the keyboard, same as any pre-sandbox GUI app. But instead of presenting its own UI for file opening, the sandboxed app makes a library call telling the OS to present the standard file picker UI. The OS does so, using a separate process heavily guarded against outside interference (so it can be sure that the user is the one choosing the file). Once the user has picked a file, the OS opens a hole in the sandbox permitting the app to access the file. So it all works, using the same flow users always used to pick files before. (It doesn't even look any different.)
That said, this approach isn't perfect. It works well for application types which need access to user-created documents, but not so well for apps which might want to touch a large quantity of files outside the app's sandboxed directory without requiring the user to pick each and every one. So there's a lot of cases where it doesn't work too well yet. It's clearly a work in progress. (Which is why Apple isn't denying the ability to install and run non-sandboxed apps, despite all the sky-is-falling paranoia.) But to claim that Apple is denying users the ability to raise an app's privilege? Just shows you have no fucking clue what you're talking about.