Securing feed enclosures
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.
Update 9/25/2006: Added a summary paragraph for clarity