Last month I promised to talk about the exploits that James Snell uncovered which left feed readers vulnerable to some very annoying script-based attacks. I didn’t want to provide details of the exploits until other feed readers had patched them, but now that James has published his test suites, I figure it’s time to open the kimono. But before I go any further, I should first make two things clear:
- Every one of the vulnerabilities was fixed in FeedDemon 220.127.116.11.
- FeedDemon’s newspapers operate in the Internet Zone rather than the local zone, so any script that makes it into a feed would not be able to access your local machine (ie: your data).
Now that that’s out of the way, some details…
Like most feed readers, FeedDemon has always stripped potentially unsafe content from feeds, but James found several ways to get around this and was able to trick FeedDemon (and other feed readers) into displaying popups, toggling read status, and performing other annoying actions. The big “gotchas” that bit me were:
- I failed to handle HTML entities that aren’t separated with semi-colons. Ex:
- I failed to cleanse the xml:base attribute in Atom feeds. Ex:
At first glance it may seem that people would simply unsubscribe from any feed that contains an annoying exploit, but the risk goes beyond that. For example, an attacker could hijack a popular site (yes, it is possible) and inject malicious script into that site’s feed. That way everyone subscribed to that feed would be exposed to the attack (ruining the site’s reputation in the process).
The current crop of feed readers (including FeedDemon) protect from this with ultra-aggressive parsing and cleansing of feed content, but that’s a never-ending battle. People will always find holes and exploit them, forcing aggregator developers to put out a steady stream of patches. I don’t think any aggregator developer looks forward to that future, so let’s come up with a better solution.
So, if you’re developing a Windows-based feed reader which uses Internet Explorer’s WebBrowser object, here’s what I recommend:
- Enable the local zone lockdown feature to prevent script from accessing the local machine.
- Use the DLCTL_NO_SCRIPTS flag to completely disable scripting when viewing a page generated from your application. You can intercept the BeforeNavigate2 event to re-enable scripting before navigating to an external page.
I’ve talked with a couple of aggregator developers about this approach, and they agree that it should work (and testing here shows that it does). You can expect FeedDemon to follow this approach soon.
As an aside, it may seem odd that I’d help my competitors by sharing this information, but I figure security flaws are an industry-wide problem, and not something that each developer should tackle alone. If we’re going to prevent RSS from becoming as annoying as email, we need to work together on this.