Apple To Patch Dashboard Vulnerability 99
bonch writes "Apple has quickly patched a previously reported security hole that allows websites to auto-install potentially malicious widgets without prompting the user. The fix is one of over three dozen miscellanous fixes to be included in OS X 10.4.1, code-named 'Atlanta', and may appear by the end of the week. Users will now be prompted before a widget downloads to their hard drive."
Come again? (Score:2, Interesting)
Re:Come again? (Score:3, Funny)
What, too obscure? (Score:1)
Re:Come again? (Score:1)
My guess is that it's close to the Coke Museum [woccatlanta.com]. Coding up 10.4.1 probably took a few coke-filled nights...
Re:Come again? (Score:1)
They should post an advisory (Score:5, Insightful)
It's pretty stupid that Apple's policy prevents them from discussing the issue before they have a patch for Safari. They really ought to post an advisory urging users of their shiny new operating system to turn off the ``open safe files after downloading" preference in Safari. Considering that it's now established that malicious widgets can replace the Apple-supplied widgets, run with full user privileges once activated, and execute arbitrary binary code [columbia.edu], Apple really owes it to its users to warn them.
Re:They should post an advisory (Score:5, Informative)
Re:They should post an advisory (Score:1)
So, shoudln't Apple have provided this function already in off as default? Lucky me I use Firefox.
Re:They should post an advisory (Score:3, Interesting)
The right thing to do is to not consider widgets to be "safe", and it looks
Re:They should post an advisory (Score:4, Insightful)
So really I had my warnings. If you are worried that people get inured to click through warnings then you might as well worry about people running any application they downloaded.
The only thing that was even vaguely troubling was that it was never stated the item would be auto-installed in the dashboard. Thus even though I was not in danger of running something I did not ask for, I was in danger of installing something in the dashbar I did not understand that I was approving when I allowed it to unzip.
So the advisory you want is pretty pointless. if people dont listen to the warnings of their own computer then why an advisory. The advisory is more likely just to make people needlessly fearful.
Re:They should post an advisory (Score:4, Interesting)
It's only 'vaguely troubling' because you aren't used to it being done. Installing known files for the user is a good idea in concept. The problem is leaving safeguards so the 'bad files' don't get installed.
They are kind of caught between a rock and a hard place here. They want to move forward and make things easy for the user to get and install without needing to understand how things are done, but they still need to prevent 'bad things'. And yes, power users want to control every step and don't mind decompressing and moving files by hand, but they are trying to get the more casual user with the 'It just works' paradigm.
Re:They should post an advisory (Score:2)
The guy said himself, it's unlikely to cause the widget to actually do anything harmful. But rather it would just be annoying.
He gave an example, and even a sample widget. The widget was simply just the goatse guy as the icon for the widget.
Now, considering that you can't uninstall, delete, or otherwise remove widgets without manipulating the files directly, I call that pretty damned anno
They should fix Safari properly. (Score:2)
That would be a start.
Better would be to quit shipping Safari with that option turned on by default.
Best would be to take that capability out completely, because it's inconvenient as often as it's convenient and it creates an opportunity for exploits that doesn't need to be there.
Re:They should post an advisory (Score:1, Flamebait)
The real problem here is not Apple's handling of the advisory. It's that Apple created a culture where users aren't supposed to worr
A suggestion for improvement (Score:5, Interesting)
So if a site tries to use the Mozilla/XPI script exploit to install a rogue extension, Mozilla should send a report to mozilla.org. Then they can blacklist the site, or even pursue legal action.
This would be GREAT for anti-spyware programs. When someone tries to auto-install spyware on to IE, Microsoft could get a report and the spyware company would feel the wrath of a monopolistic giant crushing them.
Re:A suggestion for improvement (Score:5, Interesting)
I think that when a company releases a patch for this type of thing, they should also make the patch report attempts to abuse the exploit.
One problem is that many of the exploits rely on a series of steps being taken, some of which may be perfectly acceptable but in concert, create the exploit.
If forinstance, an exploit overflowed a buffer with an infinite loop, an Apple patch may rewrite that piece of code so it cannot create that infinite loop scenario. All of a sudden, the exploit code no longer exploits anything, but there is no way to know that it would have since the code has changed.
I don't know about other programmers, but I find creating good error handling routines to be one of the most challenging aspects of software development because you have to plan for every eventuality, be it expected, malicious, or just a bug.
Re:A suggestion for improvement (Score:5, Funny)
Hey, if Apple wants to solve the halting problem as part of their security initiative, that's fine with me. Now that's dedication!
Re:A suggestion for improvement (Score:1)
Re:A suggestion for improvement (Score:1)
Buffer overflow within infinite loop?
Is that like a bad parking experience when visiting Steve at Apple headquarters?
Re:A suggestion for improvement (Score:1, Insightful)
If you wrote a code to watch for such a thing, you would probably be so flooded with false positives that the detection system would be rendered useless.
Re:A suggestion for improvement (Score:5, Insightful)
In Safari, if the file happens to be a widget, it gets installed for you so you can activate it from within Dashboard. If it's a disk image containing an application, the disk image gets opened (in Tiger, with a warning) so the user can take the right steps to install the application.
There are substantial non-abusive uses of this technology and, right now, basically one abusive use of it (sending a file that will auto-install without having the website actually ask the user if he/she wants to install it.)
It's perfectly legitimate to have a site that contains a "Download my widget" link which sends the user to a page like this. Whether the widget can be harmful or not is irrelevant; there's nothing Apple can reasonably do to prevent someone from distributing malicious software to users who trust the person distributing it and intentionally install it.
Removing the auto-install of widgets, replacing it with a "Are you sure you want to install this widget" dialog, is the reasonable solution, and brings it in line with how Safari acts when any other executable is downloaded.
Re:A suggestion for improvement (Score:2)
Re:A suggestion for improvement (Score:1, Funny)
Re:A suggestion for improvement (Score:2)
Installing the widgets in a directory that Dashboard uses to make them available for use within its GUI without asking the user is definitely a bug (the one that's being fixed in the patch that's the subject of this article), but it's not as harmful as some people have suggested, and it's really not much different than offering a normal executable for download, and then sticking it somewhere that the use
Re:A suggestion for improvement (Score:1)
Re:A suggestion for improvement (Score:4, Informative)
Re:A suggestion for improvement (Score:2)
It does NOT autrn them.
I'll repeat that because it is a very important point.
IT DOES NOT AUTORUN THEM.
It autoinstalls, yet, but does NOT autorun - the user still has to go to Dashboard and select and activate the widget.
So no, it is NOT possible to cause the widgetto be RUN without the user doing it.
Re:A suggestion for improvement (Score:1)
"Microsoft could get a report and the spyware company would feel the wrath of a monopolistic giant crushing them."
This brings up the brain-bending picture of Bill Gates as the Monopolistic Green Giant talking to Sprout...
"Gee, Mr Giant!" cried Sprout. "How was I to know my computer had a virus that caused it to attempt to violate thousands of browsers? Is there any way we can settle out of court?"
(background chorus) "Owe Owe Owe -- Green Giant!"
Re:A suggestion for improvement (Score:3, Informative)
So I don't think there is any real "offending code". The whole thing of a download commencing when you visit a page is used for a lot of download sites (instead of
Re:3 Dozen? (Score:1)
Re:3 Dozen? (Score:5, Insightful)
Apple releases a new OS and the biggest thing people can find to bitch about is that if you have the auto-open option set, it auto-opens.
MS releases a new OS claiming great security and within a couple of months the internet is crippled by Blaster.
compare and contrast.
don't dismiss this one so fast (Score:4, Informative)
I do think Apple handles security better than Microsoft, but in this case they simply were lucky that no one bothered to exploit their hole.
Re:don't dismiss this one so fast (Score:2)
but I don't get this widget thing. are they starting a download of a zipped widget, in which case you get a warning even with auto-open enabled, or a widget file on its own, in which case it would not install or run without explicit actions?
Re:don't dismiss this one so fast (Score:2)
I can understand not worrying too much about this issue if that hasn't happened to you. Having watched it, it definitely set off alarm bells in my head, and
Re:don't dismiss this one so fast (Score:1)
However, if you wanted to display the search results in a custom list, which would require custom scripting, then a dialog would pop up saying something along the lines of "This is the first time 'Widget Name Here' is running on y
Re:don't dismiss this one so fast (Score:2)
And that's not OK, because Dashboard isn't really a proper sandboxed environment. It is too dangerous for Apple to treat it as the same kind of sandboxed environment as Safari, it's a general purpose application platform and installing a widget should be treated as the same kind of serious action as running an application is.
Re:don't dismiss this one so fast (Score:1)
Can you give me an example of a possible exploit? If you can't access any of the dashboard-only calls without a user granting permission, what's the problem?
For my comment above, it might not be the javascript that's the limiting factor. It might that your plist has to request access to the system-altering routines, but in any case, it should be relatively safe.
Unless, I'll run my own thought experiment, you're suggesting s
Re:don't dismiss this one so fast (Score:4, Informative)
According to this page [columbia.edu]:
And then, even if they fix this, are users going to refuse to allow what appears to be a system-provided widget to run?
And finally, a sandboxed environment is one in which dangerous things are not possible. Not one in which dangerous things are only possible if a user approves them. And Dashboard's "sandbox" is the latter kind of environment, not the former.
Re:3 Dozen? (Score:2)
3 dozen fixes in a single point release? This is peanuts... a Microsoft service pack is a wholly different animal.
The last combined updates for 10.3 were in the neighborhood of 80-100 megabytes, encompassing every fix from 10.3.1 to the present.
Service pack 2 for Windows XP was, what, 450MB or something?
I smell cluelessness....
Re:3 Dozen? (Score:3, Interesting)
Microsoft releases patches for thousands of problems at once. They are called service packs.
The only updates they release the rest of the time are security updates.
Quick little rebuttal (Score:5, Insightful)
I don't think it's hypocrtiical to praise that kind of fast response. If my memory serves, the problems that allowed the Blaster Worm and others to work were publically known for months and MS didn't do anything about them. That's where the condemnation of Microsoft comes from.
D
Re:Quick little rebuttal (Score:3, Informative)
Re:Quick little rebuttal (Score:1)
Re:Quick little rebuttal (Score:2)
Microsoft had a patch for Code Red and Blaster available for 3 months or so before the attacks happened. You can't blame Microsoft if their users don't install the patches.
Re:Quick little rebuttal (Score:2)
Why not? They have created an environment where people need to ask "Is this going to break my installed apps?"
If people are reluctant to install a patch because of previous bad experiences, where do you lay the blame?
Re:Quick little rebuttal (Score:1)
Some engineer/manager at Apple decided that Widgets are safe. Hence this is an architectural blunder. The buffer overflow that Blaster took advantage of was a simple programming error. I don't care whether you prefer one over the other. The point is, that the two issues are very different.
great! (Score:3, Insightful)
Re:great! (Score:2)
Re:great! (Score:1)
Try Taboo [ocdev.com]. It's a free little app that a) warns you before closing a window that has tabs open, and b) disables the nag when downloading a .dmg file.
If they're SAFE FILES, why are you bugging me? (Score:2)
Re:great! (Score:1)
Worst-case scenario for Dashboard malware? (Score:3, Insightful)
It could fsck your hard drive (Score:2)
Seriously though it could do anything any script or application could do; use your imagination. It could delete everything in ~/ - that would not be fun. It could send emails to everyone in your address book announcing your engagement to Michael Jackson.
If we were a Mac house... (Score:1, Informative)
It's not the slam-dunk that it was for Internet Explorer back in the '90s, when I managed to get IE and Outlook banned just in time to dodge the flood of viruses that resulted from Microsoft's broken security model. The individual problems in Safari and LaunchServices are not nearly as obviously bad as Microsoft's security zones, but they're of the same nature.
This is what Appl
Re:If we were a Mac house... (Score:5, Informative)
They don't actually. They only get complete system access after the user has acknowledged that the widget is being run for the first time.
Re:If we were a Mac house... (Score:3, Interesting)
1. That's not true. There is an attempt at a sandbox but it doesn't apply to Widgets that were installed through the hole in Safari and even if it did there's a hole in the sandbox you can drive a Perl interpreter through.
2. It wouldn't matter if they did, because confirmation dialogs aren't enough. Opening a document or other object in an unsandboxed environment must require an explicit r
Re:If we were a Mac house... (Score:2)
Everything else I would say has already been said by others. Yes it's a problem if Safari copies widgets to ~/Library/Widgets.
In my opinion installation of Widgets should be handled in very much the same way as installation of screen savers. You double click it where-ever it is and are prompted 'install for you or for everybody', it asks you
Re:If we were a Mac house... (Score:2)
As I understand it: whether you declare these flags in your plist or not, you can't open a Widget in an arbitrary WebCore environment and get any of these rights. Only Dashboard or another fr
Widget-Sec (Score:2)
Yes, I think we agree. I think the one addition to point out is that Dashboard will only honor requests in the code for certain methods of the widget object based on the security level specified in the plist. The document I referenced explains this as: if you try to widg
Re:Widget-Sec (Score:2)
Yeh, this is Dashboard's pseudo-sandbox. What I'm getting at is that this pseudo-snadbox doesn't actually provide any useful security, because most widgets require additional rights to function so allowing a widget those extra rights is a normal operation that someone is going to expect to do when running a widget. Addition
Re:Widget-Sec (Score:2)
For example, there's no reason to distinguish "running an embedded Cocoa component" and "making a system() call" because both of these grant you full local-user control.
Well there's no reason for 'average folks'. You and I can both tell the difference between a 'do shell script' and running a plugin and is this: It's trivial to open up the bundle and looking at the script for system calls (plain text and all) vs. trying to determine what a widget or web plugin does befor
Re:Widget-Sec (Score:2)
It's REALLY AMAZING how close the kind of Javascript that some virus writers write is to binary. Really. I've seen whole applications encrypted and wrapped up with an obfuscated decryption routine
Re:If we were a Mac house... (Score:2, Interesting)
Re:If we were a Mac house... (Score:2)
It doesn't matter. 10.3.9 still has all the other problems I mentioned. Apple has been putting bandaids on symptoms instead of fixing the deeper problems since their security "fix" last June.
Oh, yes, compared to what Microsoft has been doing it's a tiny little problem. But they're applying the same technique to fixing the problem that Microsoft did, and
Learn from ActiveX? (Score:3, Insightful)
Actually in my mind this Dashboard security hole, while perhaps minor, is one of the most disappointing things Apple has ever done. The line continues to blur between surfing and running code -- or between documents and executables -- and this trend, while important, of course presents serious, inherent security challenges, since it places the user in a passive position with respect to the code being executed on their computer. It's disturbing that Apple apparently didn't think much at all about that very well-known issue, before creating an auto-install, auto-execute system for Javascript apps with file system access.
Isn't this the same major (and irrevocable) mistake that Microsoft made when they let the ActiveX genie out of the bottle? If Apple is going to walk into the same traps that Microsoft walked into years ago, it makes me question the purpose of OS X. Plus as an invention Dashboard isn't even as useful as ActiveX.
Re:Learn from ActiveX? (Score:5, Insightful)
No, not quite. While it's a step along the dark path it's a long way from ActiveX, for a couple of reasons.
First, it's not QUITE autoexecute. It's close enough that a naive user could easily step off the cliff, it doesn't actually push them over. It can be avoided if you're wary.
Second, it's not irrevocable. Apple can disable "open safe files" and remove the code from Safari that autoinstalls widgets without breaking anyone's software. It's not like these capabilities are core elements of a desktop-browser integration like ActiveX is in Microsoft.
Dashboard isn't the problem, if it's treated as "a new way to write applications" and the token attempt at sandboxing doesn't lead Apple to take it lightly.
Re:Learn from ActiveX? (Score:4, Insightful)
First of all, the VERY first patch to this new operating system, 10.4.1, will fix this bug. Developers can't always catch everything, and honestly, I wouldn't even have thought about it, so I can't blame Apple for not thinking about it. I'm just happy to know when my laptop arrives with Tiger installed that the very first thing that will happen is it will patch all of the holes they let slip in 10.4.0.
Second of all, deadlines like this are vicious. If you ask me, they rushed the release of Tiger a bit just to counteract some of the press Longhorn betas and Longhorn reviews were getting, and to help the sells of Mini Macs. So some of the things they released were a little broken.
Lastly, you said it yourself. Dashboard isn't even as useful as ActiveX, and is entirely deniable. You can turn it off and not ever use it if you choose, making any bugs like this completely null to you. ActiveX quickly became something that wasn't deniable; if you weren't running ActiveX, your bank's website would refuse to do business with you. Now doesn't that mean a flaw in ActiveX is a lot more critical than a flaw in some easily ignorable post-it note board?
Until this actually ships... (Score:2, Informative)
1. Run "Folder Actions Setup" (in the Applications/Applescript folder).
2. (if it's not already on) Turn on "Enable Folder Actions".
3. Click the (+) button below the folder column to add
Why? (Score:2)
How do you figure? What does "Open Safe Files" do for you that it's worth even a little risk? Even if it was entirely safe I'd turn it off because it's annoying to download a file and end up with two or three extra icons on my desktop because Safari ran Stuffit which unpacked it and then mounted the DMG inside... or if I configure Stuffit to delete the original now I've lost the file I ac
Re:Why? (Score:1)
Re:Why? (Score:2)
And it was to those that I was addressing my question, because I honestly don't get it.
I do find it useful to have pdfs opened for me without sloshing through my download folder
That's not been a problem for me for a long time...
But in any case Firefox does it better, by letting you see the file in your download manager and open it from there. That makes i
Re:Why? (Score:1)
Safari has exactly that same ability. Double click on the little icon and it opens for you, click on the magnifying glass it shows the file. Which I guess shows how I could (and have done) open those files w/o having that option checked. So, how exactly is Mozilla/FF doing this any better? (not trying to dis
Re:Why? (Score:2)
Oh. Right. It's been too long since I used it. I'm addicted to the Flashblock extension, but that's another kettle of user interface goodness.
It's doing it exactly the same, and that's more of why I don't "get" this "open safe files" thing.
As for the plugin, well, Acr
Re:Until this actually ships... (Score:2)
Well your configuration is a good step, it could be better. I'd recommend changing the permissions on you existing widgets so that they cannot be overwritten by a malicious version (which you would then have to find and replace).
Re:Until this actually ships... (Score:1)
Re:Until this actually ships... (Score:2)
Ahh, I did not realize it was a problem of co-existing widgets with the same name. I haven't installed Tiger yet, as I'm still waiting for Cisco to fix their VPN client. Thanks for the clarification.
Re:Until this actually ships... (Score:1)
iMac:/Library/Widgets ka-klick$ ls -la
total 16
drwxrwxr-x 17 root admin 578B May 11 21:33
drwxrwxr-x 53 root admin 1K May 5 00:03
-rw-rw-r-- 1 ka-klick admin 6K May 11 21:33
drwxr-xr-x 12 root admin 408B May 4 06:16 Address Book.wdgt
drwxr-xr-x 12 root admin 408B Mar 23 19:49 Calculator.wdgt
drwxr-xr-x 12 root admin 408B May 4 06:16 Calen
The only real mistake Apple made is... (Score:4, Interesting)
Well, that's the new one. (Score:4, Informative)
That's the NEW mistake they made.
The other mistake is the one they made in Safari 0.9 that they haven't yet fixed, and that is to let Safari "open safe files" automatically.
What more do you want apple to do besides prompt the user and ask if they would like to install a downloaded widget?
I want them to do less than that, actually. I want them to just download the widget and wait until the user chooses to install it, or not, and in the meantime leave it sitting in their Downloads folder not bothering anyone.
Because dialog boxes asking users to confirm actions just annoy the user and train them to automatically answer "yes" when a dialog comes up. I see it happen all the time on Windows, some of my users have been infected after reflexively answering "yes" multiple times. NOBODY, though, has ever been infected after manually opening a downloaded virus more than once... because it's more of a deliberate conscious act than clicking on a "yes" button in a dialog you just want to get out of the way.
Re:Well, that's the new one. (Score:2)
Let Safari? How about letting me do this? I happen to prefer having PDFs, disk images and a few other things open automatically, without my having to: 1) locate the tiny download window, 2) scroll down in it to the file I just downloaded, 3) click on the tiny "Show in Finder" button, and 4) double click on the file in the Finder.
Re:Well, that's the new one. (Score:2)
OK, that's what Firefox does better, then.
When you download, it opens the download window for you, scrolls down to the file as it's downloading, and you can just double-click on the file to open it.
That way you get conv
Apple could go one step further (Score:2)
Another problem, besides "auto-install on download" is that Dashboard's "warning" to a user on newly-installed widget launch is a simple yes/no proposition without any indication of the access sought by the widget.
It would be nice to see Apple adopt something similar to Amnesty Widget Browser [mesadynamics.com], which presents the following dialog [yumahouse.com] on newly-installed widget launch.
Apple should back up a step instead. (Score:2)
The fact is, Dashboard shouldn't be doing this check at all. The check implies that Dashboard is a "safe" environment, and it's not any such thing, so all it does is provide an illusion of security that encourages people to treat Widgets cavalierly... and it's truly ironic that the first victim of this illusion is Apple themselves. Same thing with Amnest