Slashdot Mirror


Malicious Web Pages Can Install Dashboard Widgets

bonch writes "If you're running Safari on OS X Tiger and go to this website, a 'slightly evil' Dashboard widget will be automatically downloaded and installed and can't be removed without manually removing the file from the Library folder and rebooting the computer. The widget is called Zaptastic and is a demonstration by the author of how easy it is to exploit Dashboard for nefarious purposes. The essay, released under the Creative Commons License, goes on to describe the many ways users can be taken advantage of--imagine porn sites auto-installing adware widgets without your knowledge." So if you're on a Mac, it would be smart to view that page with something other than Safari.

4 of 610 comments (clear)

  1. Re:widgets limited by antibryce · · Score: 5, Interesting


    True, but widgets can run external programs if certain permissions are set. The most insane part is that the widget itself sets the permissions it's allowed to have. Putting a key in the Info.plist file with "AllowFullAccess" set to "Yes" will allow the widget to run anything, access the network, etc. Basically at that point it's a full featured app. How hard would it be to make a widget that's invisible but periodically queries Safari's browser history, or songs played in itunes, or do a spotlight search for "password" and email the results to some guy in Russia? The widget could even be invisible to the user, with a 1x1 transparent gif as it's screen.

    It seems really really dumb in this light to have Safari not only automatically download zip files, but uncompress them and if it finds a Widget bundle inside to install it. All without user intervention.

  2. Dashboard: Slightly OT but worth a look by uprock_x · · Score: 3, Interesting

    Click OnLine, BBC's tech show:

    http://stream.servstream.com/ViewWeb/BBCWorld/File /worl_click_030505_show_hi.rm?Media=60506

    Cole asks Apple manager: is Dashboard a big rip off of Konfabulator?

    Apple manager's response:um, er...Desk..Accessory...um...things......from before....like

  3. Didn't work on my system by 1nhuman · · Score: 5, Interesting

    I do use Tiger and Safari, but it didn't work on my system. Primarily because in Safari > System Preferences > General, I Unchecked the check box that automatically open's up Safe files, which includes archives (which I do not consider safe).

    Another thing I did, was to redirect downloads to a special download folder which has a special Folder Action attached that scans new files for viruses and then changes new files permissions to "No Access" (even if there are no viruses). If I want to open/read a downloaded file I have to change it permissions to read/write, for which I made a single-click Apple script that I dragged in the Finders top bar thingie. Ok I'm slightly paranoid, mainly because IT security is my thing (btw the reason why I switched to Mac OS X last year), But it works.

    --
    The glass is half-full. With poison. And there are cracks in the glass. The dirty, dirty glass.
  4. Re:widgets limited by Arrgh · · Score: 4, Interesting
    It's not a bad idea per se to automatically download and run stuff from the Internet, but any software designed to do so had better be designed and implemented properly. The dozens (hundreds?) of "cross-site scripting" bugs that have surfaced in popular browsers in the past few years are evidence that this is rarely done well. Java's 10 year old sandbox design has been quite successful, and Flash has followed a substantially similar design.

    Unfortunately, code signing, as currently implemented and (mis)understood by users, is an all-or-nothing proposition. There are certainly legitimate uses for privileged mobile code, but most users don't really read or understand security warning dialogs, they just think "I just clicked the Start Game button, and now it's asking me if I really want to Start the Game. How stupid."

    Marimba actually came up with a good partial solution ages ago. When their framework loaded and executed a Java app, the framework would closely manage exactly what resources could be exploited by the app. Each application's ability to read and write files was restricted by default to its own tiny corner of the filesystem, and the amount of space it could occupy with its files was constrained as well.

    Note that Java's security manager infrastructure has allowed these sorts of fine-grained controls since 1.2 (circa 1998), but no one to my knowledge has yet found a way to effectively communicate to a user:

    • what resources a given piece of mobile code will want to exploit;
    • what the risks of running it might be;
    • some assurance that the code is published by someone they trust;
    ...While maintaining some degree of user-friendliness. It's a tough problem.

    MSIE's concept of local policies set according to centrally defined security zones was a step in the right direction; it's too bad its development stalled when the Browser War was "won."