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 2.0.0.25.
- 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 whitespace in the word “javascript:” when used inside HTML attributes. Ex:
javas cript:window.alert('gotcha') - I failed to handle HTML entities that aren’t separated with semi-colons. Ex:
javasc - I failed to cleanse the xml:base attribute in Atom feeds. Ex:
xml:base="javascript:window.alert('gotcha')"
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.
The real problem for desktop feed readers is that most of them can’t simply disable script since they rely on JavaScript to interact with the browser (for example, FeedDemon’s newspapers use JavaScript to change an item’s appearance, among other things). However, it is possible to access the DOM through your application code directly, which means there is a way to block all script-based attacks without limiting the feed reader from interacting with the browser.
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.
- Access the DOM through application code via the various IHTMLDocument interfaces rather than through JavaScript (since script will no longer work after taking the previous step).
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.