Apple To Patch Dashboard Vulnerability

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."

Comments

They should post an advisory

[mithras the prophet]

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, Apple really owes it to its users to warn them.

Re:They should post an advisory

[allgood2]

Apple's already warned users about the "run safe files" function before. The warning indicated that average users should turn the function off, unless you ONLY downloaded files from known, "safe" sites. I had thought that they had released an update that had switch the default in Safari to remove the check from the "open safe files" box, but either Tiger changed that, or I was wrong.

Re:They should post an advisory

[goombah99]

When I have downloaded application containing widgets they all came packaged as Zip files. the OS warned me that the file I was downloading contained an application. Safari then unzipped and the widget was autoinstalled into the dashbar. The first time I ran it it said this is the first time you are running this and gave me a warning dialog before executing it.

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

[NaugaHunter]

The only thing that was even vaguely troubling was that it was never stated the item would be auto-installed in the dashboard.

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.

A suggestion for improvement

[MobyDisk]

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. That would make it possible not only to secure against the exploit, but to catch the black hats who try to use it.

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

[amichalo]

Good idea but difficult to implement.

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

[geoffspear]

If I'm not mistaken, the "exploit" in question is the same technique used by many download sites (including, e.g., Sourceforge) to serve files. You navigate to a web page which displays HTML content and then triggers a download of a file while the page is being displayed.

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

[Have Blue]

an Apple patch may rewrite that piece of code so it cannot create that infinite loop scenario

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

[geoffspear]

It absolutely, positively, does NOT run them. It installs them in a directory, which is read when you click the big plus sign at the bottom of the Dashboard screen. They're only run if you click on them there.

Re:3 Dozen?

[rokzy]

"fixes" means little things mostly.

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

[Heisenbug]

The Dashboard behavior they're changing is the rough equivalent in Windows of visiting a web site and having an application (with disk access disabled) appear in your All Programs start menu without warning. If that happened, you can bet that we'd all be bitching about it, and it would be catching an awful lot of users off guard. By now it would be on all the juarez sites as a DDOS client, and probably doing some significant harm to sections of the internet ...

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

[argent]

Can you give me an example of a possible exploit?

According to this page:

Dashboard does not present a prompt before running a privileged widget that is one of the Library/Widgets folders, including our auto-installed widgets.

If a widget contains a native Mach-O executable, Safari will present a warning before downloading the widget. However, because widgets in ~/Library/Widgets can run shell commands with the widget.system() call, this protection is easily defeated.

And then, even if they fix this, are users going to refuse to allow what appears to be a system-provided widget to run?

When Dashboard encounters two or more widgets with the same bundle identifier, it only displays the last one loaded. And -- you guessed it -- widgets in ~/Library/Widgets are loaded after the system-supplied widgets in /Library/Widgets.

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.

Worst-case scenario for Dashboard malware?

[yardbird]

What's the worst that a malicious widget can do? Presumably it has access to the network, so it could be a DDOS client (as someone mentioned above). What can widgets do locally?

Quick little rebuttal

[daviddennis]

Someone discovers a nasty possibility, and in two days Apple announces a fix. It will be ready within a few more days and then the problem's gone for good.

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:If we were a Mac house...

[remahl]

when run in Dashboard they have all the same capabilities as local apps and need to be treated like any other applications.

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.

Learn from ActiveX?

[lbya]

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?

[argent]

Isn't this the same major (and irrevocable) mistake that Microsoft made when they let the ActiveX genie out of the bottle?

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?

[ciroknight]

You are blowing things way out of porportion.

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?

The only real mistake Apple made is...

[berndtj]

Automagically moving the downloaded widged directly into the dashboard widgets folder. Some of the responses here are suggesting that widgets in general are a securtity risk, well, so is every other application that you've installed on your machine. The assumption is that you won't install a malicitious application, well the same applies. It is up to the user to decide if an app is safe to install. What more do you want apple to do besides prompt the user and ask if they would like to install a downloaded widget? Yes, this is an issue right now, but I don't think this current issue, which will be fixed as mentioned above, makes Safari and Dashboard a security risk.

Well, that's the new one.

[argent]

[The only mistake Apple made is] Automagically moving the downloaded widged directly into the dashboard widgets folder.

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.