If you've visited here before you may want to jump straight to the latest additions:
A year ago, my description of the URL scheme security hole took a few weeks. Therefore I had labeled it "a work in progress" at this site's home page. It seemed long fixed, so archiving it as a stable document had been on my to-do list for quite a while. And now suddenly, it in fact appears to still be a work in progress after all. Good thing I give my to-dos such low priority ;)
Under Mac OS X 10.4 "Tiger", Safari by default is configured to "open safe files automatically". One of the file types it considers "safe" 10.4.0's Safari considered safe are Dashboard widgets. "Opening" them means they get installled (into ~/Library/Widgets/) and are immediately available in the Dashboard's UI.
A newly installed widget is not automatically executed. The user will have to still activate the Dashboard and click the new widget in the Dashboard's 'cheese grater', at the bottom, to activate it.
Remember the META HTTP-EQUIV="Refresh" from our old friend, the URL scheme security hole? Yup, using that, a malicious Web site can install a Dashboard widget without the user being aware of it. (And of course a server-side redirect could do the same.)
Note that there is no step involved that people generally label "downloading" or "installing". All it takes is 'clicking' 1 link. That link doesn't have to be in a Web page. It can just as well be a link in an email, Instant Message, on Usenet, where ever.
I don't know exactly how secure the Dashboard 'sandbox' is. Apple obviously considered security, but even assuming Dashboard is 100% secure (nothing ever is), as I understand it, all a user is protected by from granting a widget Admin rights is a user-friendly dialog box asking for permission. However, in reality no such dialog appears... I believe it is the same dialog that Apple provided as the 'fix' for the URL scheme security hole.
Even if the widget doesn't get Admin rights, it'll still have enough rights to be able do harm. This proof of concept demonstrates that a Dashboard widget can grant itself permission to access the network and to execute a 'unix binary' without any user intervention when installed automatically. The author of that POC seems to suggest shows that a thusly installed widget can grant itself Admin rights even. If this really is the case, t This is just plain insane.
Even it it would work, a user-friendly dialog box asking for permission is not good enough protection. Suppose the user activates Dashboard hours, days, weeks or even months after having been attacked. He'll at some time notice the widget, but has no reason to suspect it could possibly be malicious. Due to the fact that it was installed without his knowledge, he'll assume the widget came pre-installed with the OS. So when he activates it, and is asked to grant it (even Admin) permissions, he'll likely do so, thinking: This widget must have come with Tiger. Surely Apple can be trusted.
This also shows how poor Apple's fix for the URL scheme security hole was. More of a hack than actual security design. A reason that that fix seemed acceptable at the time was that with the URL scheme security hole, the code would (have to) be executed while visiting the malicious site. So as a user, you might smell the fish. But with this widget attack, it might take a long time before you activate Dashboard. Less users will think twice when they get that warning dialog then.
There are a few ways to protect yourself. I would suggest just using the first. I list the others mostly for completeness' sake only.
If you suspect a Dashboard widget may have installed itself without you knowing it, then:
The widget will be in ~/Library/Widgets/ (the tilde [~], is unix speak for "the current user's home folder"). All Apple-provided widgets are in /Library/Widgets/ (that's the Library folder at the root of the startup disk), so there's no risk of accidentally deleting those.
Perhaps the worst of it is that this problem is so very much like last year's URL scheme security hole. IIRC, at the time Apple even suggested people switch off Safari's option to automagically open 'safe' downloads.
An occasional security problem is to be expected. Especially with complicated new technologies like LaunchServices, which was the issue a year ago. But to have what I believe is more or less the same security hole return only 1 year later, this time even in something that's really just a toy compared to some of the other new stuff that's in Tiger, is truly pathetic.
Given how much Apple hyped Dashboard compared to how little it is (as compared to Tiger's extendable file attributes, Spotlight, ACLs, etc.), suggests that perhaps much of Dashboard sprang from the minds of Apple's sales people. (It certainly wouldn't be the first time sales people tried to sit in the engineer's chair - just ask Dilbert ;)) At least I would like to think that the engineers who designed extendable file attributes, Spotlight, ACLs, etc. would not have shipped such an obvious securtity hole.
Or it might 'just' be that different divisions at Apple are floating too much in their own space - that no one is overseeing the bigger picture. I really don't want to believe that to be the case. You can't secure a box without a detailed overview of and control over all its contents.
Thanks to stephan.com for bringing this to our attention.
Dashboard's security model is still broken in 10.4.1.
Mac OS X 10.4.7 introduces a new process, dashboardadvisoryd, that appears (Apple hardy ever provides details about their software updates) to be a Dashboard Widgets security measure. It seems to attempt to check if your Dashboard Widgets aren't tampered with, by contacting Apple's server on a regular basis.
Whether it only looks at Apple's Widgets or also those of third-parties, how it does the check, what it does when it decides it finds a 'bad' Widget... who knows? Apple hasn't provided any information aside from You can now verify whether or not a Dashboard widget you downloaded is the same version as a widget featured on (www.apple.com) before installing it.
.
According to Apple, Mac OS X 10.4.2 adds a routine that warns the user when there is a user-installed Widget in ~/Library/Widgets that identifies itself as an Apple-provided Widget.
I suppose it's better than nothing, but it seems as lame a sort of protection as Apple's 'fix' for the URL scheme security hole. I've seen mortal users respond to that message: "Eh?" and then hit OK to get it out of the way. Such a message only helps those very few users who are aware of the particular security hole.
10.4.1 does not address the issue of widgets' self-assigned access to things like network, cli executables, 'the system', etc. My testing shows that Mac OS X 10.4.1 still allows Aaron's 'mailicious' Stickies.wdgt to grant itself access to whatever it wants (simply by setting AllowSystem to true in its info.plist).
Apple has done nothing about Dashboard's broken security model in 10.4.1. The current documentation still says widgets must declare the level of access they want, but when they do that access is automatically granted. How does that make sense? Either executables must ask for permission, or they don't. Maybe I'm missing something, but the current Dashboard 'security model' looks like rubbish to me.
Starting with Mac OS X 10.4.1, when you download a zipped widget Safari will display a warning (if you have Safari's option to "open safe downloads" enabled) saying the file is an executable and asking if you are sure you want to continue dowloading it. This fixes the immediate risk of this security hole.
Apple has quietly changed its on-line documentation concerning Dashboard's security model. Both the HTML and PDF versions of the Dashboard documentation until about yesterday (May 11) contained this sentence:
"If your widget is working with resources that pose a security threat to the user, the user must approve before access is granted."
This sentence has now completely vanished.
If you have the Develeoper Tools, "XCode 2.0" installed, you have the original text on disk. Otherwise, the version containing this sentence is still availbale through Google's cache. Just in case that disappears, here's a PDF of that very Google cache.
This was really the one thing describing how the user is protected from being attacked. It clearly didn't work (the only way I ever managed to get a warning dialog from a widget was when I double-clicked it in the Finder from another location than ~/Library/Widgets). And now its official description too has disappeared.
I honestly don't know what to make of this.