Microsoft RSS Blog : Security

Securing feed enclosures

rss — Thu, 21 Sep 2006 01:25:00 GMT

Greetings,

I am one of the developers on the RSS team, and to complement Sean’s and Walter’s recent postings on feed security, I would like to talk about one topic that didn’t get as much attention in recent discussions on feed security as perhaps it should have - feed enclosures. Enclosures are files “attached” to feed items, commonly used in podcasting and often automatically downloaded to user’s machine by aggregators.

In IE7 and the Windows RSS Platform, we have taken a number of precautions to protect users and developers against feeds which may attempt to use enclosures in malicious ways.

To begin with, when a user subscribes to a feed in IE7 enclosure downloads are turned off by default. Users can easily opt-in to enclosure downloads via the feed properties.

We also treat enclosures as inherently un-trusted files – in many ways similar to email attachments. We decided not to permit directly-executable (i.e. any file that would execute arbitrary code when double-clicked) or other dangerous files to be downloaded as feed enclosures (there are no common scenarios that require this today, and if it is absolutely necessary, it is possible to wrap an executable file in another format, so that it is no longer directly executable). For this we use the most flexible mechanism possible, the Attachment Execution Service (AES). In simple terms, the AES maintains a list of file extensions that are considered dangerous, including the directly-executable file types, which the RSS platform consults to decide whether or not to block a file.

Besides blocking the dangerous file types, AES also has a mechanism which allows security programs, such as anti-virus or anti-spyware, to integrate with it, allowing them to inspect files before we make them available to developers or users. Windows Defender has implemented this integration, so on Windows Vista (or if the user has installed Windows Defender on Windows XP), the user will gain that additional level of protection from the malicious files.

IE also has a mechanism to block file downloads on a per-zone basis, so before fetching the enclosure we also verify that downloads are allowed for the URL. You can find this per-zone setting in your Internet Options, under Security tab. The simplest way to prevent enclosure downloads from a site is to add it to the Restricted Zone, where downloads are disabled by default.

If an enclosure download does get blocked for security reasons, this is reported in the feed view as well as through the RSS platform’s LastDownloadError property.

Downloaded enclosures are stored in a subfolder of the Temporary Internet Files folder. The full path to the enclosures is different on every machine, preventing malicious feeds or other malicious code from using enclosure downloads as a vector to get known files on the system, as well as ensuring that other applications don’t unknowingly access enclosure files. If an application wants access to the downloaded enclosures it needs to obtain the path from the RSS platform.

To summarize: enclosures are treated as un-trusted files, and the following security mitigations are used:

Enclosure download is off by-default for all feeds.
Directly-executable files are blocked from being downloaded, using the Windows Attachment Execution Service (AES).
Anti-virus and Anti-spyware applications (like Windows Defender) can integrate with AES to dynamically block malicious files.
Files are stored in a variable location on each PC, ensuring that applications must opt-in to consuming the enclosures.

As before, we want to make sure all aggregator developers know that the tools we are using to make IE and the RSS platform more secure are available for their use as well:

AES can be utilized through the IAttachmentExecute interface.
To determine if file downloads are allowed, applications can invoke the ProcessUrlAction method to query for URLACTION_SHELL_FILE_DOWNLOAD.

Once again, we would like to reiterate our commitment to working with the community to improve feed security, and as always we are open for your feedback and questions.

Thank you,

Miladin

Update 9/25/2006: Added a summary paragraph for clarity

More on Feed Security

rss — Sat, 09 Sep 2006 03:31:00 GMT

Shortly after the SPI Dynamics presentation that sparked a renewed discussion on feed security in the community last month, James Snell developed a suite of tests (based on an earlier set by James Holderness), and generously made them available quietly to aggregator developers. He has now made the tests public.

I contacted James last month (via email as he requested) and he pointed me to the test suite, so we could test them against our own security mitigations. We have done full test passes using his test suite.

The result: IE7 passed all of the tests (which means that no script from the feeds executed successfully in IE, and that developers using the RSS platform would not have been vulnerable to the class of attacks in the tests). This confirms SPI Dynamic's findings that IE7 was not vulnerable to the attacks described in their paper.

I thought it might be useful to use this opportunity to talk about our commitment to security, the defense-in-depth strategy that we have taken, and how other aggregator developers might benefit from the work we have done.

Our commitment to security

To put it bluntly, we are keenly aware that IE is a target for security researchers and hackers. We know we cannot afford to be lax in how we approach security. It has therefore been our #1 guiding principle that we would aim for a secure experience first -- sacrificing functionality, if necessary, to achieve it.

Long-time readers may remember this post from last November, in which we announced that we would only support well-formed XML in feeds -- the post was the direct result of a long internal discussion about ways to securely handle malicious feeds. Refusing to handle malformed XML eliminates a large class of potential attacks.

Walter posted last month on the details of how IE7 and the Windows RSS Platform protect users and developers from script in feeds. To summarize what he wrote, IE7 employs a (roughly) two-level defense-in-depth strategy:

Sanitization: First, the Windows RSS Platform uses several techniques to strip out script (and several other variations of malicious HTML) before storing the feed content.
Restricted Feed View: Second, just in case the first step misses something, IE's feed view uses a variation on the Restricted Zone to show a feed, meaning that no script in a feed will run, even if made it through the previous step.

Each of the two defense-in-depth steps described above require a significant amount of code and investment, but security has been always important enough to us that they where the first major pieces of development that we did when we began implementing the RSS features. In fact, these security features have been in place since the first public release of the IE7 RSS platform features last February.

To give you a sense of what is involved -- at one point in development, the sanitization code accounted for fully one-third of all the code in the RSS platform. The code takes lessons from similar libraries used for years to clean the billions of messages that Hotmail receives, and used for a number of releases in various parts of Office. It includes a number of feed-specific additions (for example, if an element is supposed to only contain text, then we can remove all HTML, not just the script). We validate and sanitize every documented element in each format we support, as well as a set of common RSS extensions. This is all done before an item is ever stored on the system.

In IE itself, the "restricted feed view" was also a significant challenge because of the interactive nature of a feed view. We designed and developed a feed view that required no javascript for the various controls (subscribing, filtering, sorting, or searching) to work. In fact, the IE7 feed view implementation is effectively that described by Nick Bradbury in his recent post on feed security (using a script-less page, and manipulating the view from the hosting code).

The bottom line is that IE takes security very seriously. We have invested a great deal of time in hardening IE7 across the board, and nowhere more seriously than in our RSS features. It is an ongoing process, however, and we deeply appreciate the efforts of those in the community who have developed additional security tests and allowed us to use them.

Looking forward

We also look forward to continuing to work with the community to improve the security of all aggregators. To that end, we want to make a couple offers to developers of Windows aggregator developers:

First, you should feel free to contact us if you have questions that come up while implementing a fully restricted feed view using the techniques that Nick talked about in his post. If there is enough demand, we may write a blog post on how the IE feed view is built, so people can learn from what we’ve done.
Second, the Feeds API includes a utility function called Normalize(), which can be used to gain access to the platform's HTML sanitization code. Contact us if you'd like more information on how you could use this to supplement your own sanitization code.
Finally, I’ll make the obvious point that the entire platform is available for your use, including not just the security features described here, but storage and a suite of bandwidth management features. I understand, of course, that for many existing aggregator developers, switching storage and download engines may be too significant a change in their applications, but I do want to encourage developers of new applications to consider it.

Thanks for reading,
Sean

PS. Of course, there will be some readers who see this post as a challenge and start looking for exploits in IE's RSS features. If you do find any, please let us know! :) We know that no security is perfect, and that it is an on-going process.

Script in Feeds

rss — Mon, 07 Aug 2006 21:31:00 GMT

You might have read the c|net article "Blog feeds may carry security risk" which summarizes the presentation given by Robert Auger ~~and Caleb Sima~~ of SPI Dynamics. The presentation points to potential dangers of malicious script embedded in feeds. This has sparked some discussion in the community.

We think it's good for the RSS community and users that the potential dangers of malicious script in feeds are pointed out and thereby can be addressed by application developers before any attacks materialize.

In IE7 and the Windows RSS Platform we've implemented several mitigations that specifically address potentially malicious scripts in feeds:

Sanitization
When downloading feeds, the RSS Platform passes the feed through a sanitization process which among other things removes script from HTML fields like the description element. Also, text fields, like the title element, are treated as text and not as HTML, so HTML tags are entity encoded. These steps are performed before the feed content is accessible by application including IE7's Feed View. Further, the feed content is persisted in the Feed Store in the sanitized form, so that applications accessing the feed data benefit from the sanitization.

Feed View in Restricted zone
The IE7 Feed View displays feeds in the Restricted security zone, no matter where the feed originated, even if for example the feed came from a site in the Trusted Sites zone. By default script is disabled in the Restricted zone. In addition, the Feed View disallows URL Actions including script and active content.

We designed and implemented the RSS features using the principles of the Secure Development Lifecycle as embraced by Microsoft. One of the principles is defense in depth. The idea being, even if script somehow were to sneak by the first layer of defense, the impact that the script could have is restricted, if not entirely negated.

Hosting IE in Applications
The second mitigation above can be of interest to application developers who are hosting MSHTML inside their applications. When using MSHTML to render feeds, we recommend that the host application implements a custom security manager, which allows the application to control which URL Actions are permissible. In order to reduce the attack surface of the application it is advisable to limit the permissible URL Actions to the smallest number possible.

I hope this will spark even more discussion about security and RSS which will ultimately benefit users.

- Walter vonKoch

[Update 8/16] Peter Plamondon of SPI Dynamics provided the link to the paper itself in the comments.

[Update 8/17] As noted by Sean Kerner in the comments, the presentation was given by Bob Auger solo. I've correct the intro above. Thanks.