UW Computer Security Research and Course Blog

The Mac OS X Dashboard is a platform for developing small applications, or Widgets, that can be accessed and hidden quickly at any time within the OS. Common widgets tasks include simple calendars, calculators, games, weather tracking, and system monitoring. There are thousands of user created widgets available for download through apple.com and other sites. Widgets are built using standard web technologies such as CSS, HTML and Javascript. However, they also contain hooks into the local system, allowing them file system access, access to compiled C code, and shell command access. These hooks are facilitated by the operating system running the widget instances and create a plethora of security concerns.

Widgets allow for a very convenient and easy-to-develop platform for creating light weight applications with encapsulated functionality. However, many people regard widgets as benign and harmless applications, when they actually have the potential to run any commands or any files at the user level. The two assets that come into question when reviewing dashboard widgets are the protection and privacy of the user’s machine who installs the widget and the integrity of the widget code itself. Widgets have the ability to compromise both system stability and privacy of user data. By allowing widgets file system access, the widget can potentially delete important files, or execute unstable C code that will cause the widget or other applications to crash. The widget can also potentially view private files or other data and secretly send that data to a server specified by the widget developer. Users can also modify widgets by opening up the source code, modifying it, and relaunching the widget. Because widgets have direct access to the web and many of them make requests to external websites for content, allowing users to modify them may open up the potential for abuse that the widget developer did not intend.

A malicious author may write a widget that once installed can steal user passwords or private data from the file system. This can be done through compiled C programs that included in the widget bundle or by accessing the widget’s Javascript hooks to execute shell commands. C code exploits are hard to detect by reading the source of the widget and the Javascript source could be obfuscated or compressed. An even trickier attack would be to make a part of your widget’s source code included from a web source. This would mean that at any time, a malicious author could modify the web source code and that would propagate to all widgets installed on computers. This strategy would make malicious widgets harder to detect because the bundled source code does not contain the malicious code.

The other vulnerability would be exploited by a malicious widget user and would involve that user modifying the source code of a widget to act differently from the author’s intent. For example, if a widget were to post scores of a game to a central server to keep track of everybody’s high score, this would not be possible to keep secure with the Dashboard’s current architecture. This is because a user could open the source and modify the number sent to the server to create false high scores. A specific example of this vulnerability is found in the OnTour widget, which using your personal iTunes library will find artists that are playing shows in your local. This widget also serves advertisements. I opened up the widget, found the code to display the advertisements, deleted it, relaunched the widget and presto! the adds are gone.

The simple defenses I see are to ensure widgets that you are downloading are from a trusted source do not have more than necessary access privileges. I personally open the source of all the widgets I download to see if anything obviously shady is going on. Because this is not something that most OS X users should be expected to do, we need to rely on the content provider (i.e. apple.com) to ensure they are posting safe widgets. This is difficult, because Apple does not actually provide the bandwidth for the widget, instead the files are directly linked from Apple to the author’s website. I would hope that Apple ensures the file they are linking is identical to the file they link. This would be possible because submitting a widget requires the author to upload a copy and provide a link, which would allow Apple to perform a security check of the widget. Even verifying the widget content does not prevent the author from changing dynamically linked content from a web source as mentioned above.

A few further defenses would be do not allow javascript to be included from external sources. This would mean no SCRIPT tag could have an SRC attribute referencing anything outside of the widget bundle. This would also mean that any content incoming from an XMLHttpRequest would not be allowed to generate events for objects. This is an extreme solution and would be an incredibly difficult and invasive change to the way that Javascript is interpreted by the OS X WebKit. It would also limit a lot of potentially valuable widget functionality.

To defend against these vulnerabilities, Apple introduced a component called the “Dashboard Advisory” that phones home daily to ensure that the widgets installed on the user’s machine match those stored on Apple’s database. This was in attempt to ensure the integrity of the widgets. However, the community went up in arms about this fix because Apple did not announce they were adding this component and users felt their privacy and licenses were being violated. In truth, there is no feasible way for Apple to ensure that all widgets they are serving are trustworthy. It is up to the user to be cautious and suspicious and for people who are more savvy to report widgets that are performing malicious operations.

Further reading
MacWorld Article on Dashboard (in)security

Dashboard Advisory blog thread

Google Widget security flaw exposed