On 17 November 2009 I blogged about vulnerabilities with nsIScriptableUnescapeHTML.parseFragment() here – So much for nsIScriptableUnescapeHTML.parseFragment(). At the time, nsIScriptableUnescapeHTML.parseFragment() was being recommended by Wladimir Palant, Jorge Villalobos, and others, as the only way to display web content, within the trusted chrome context, while eliminating all potential security issues. Yeah right!
Not only were Wladimir Palant and Jorge Villalobos “selling” nsIScriptableUnescapeHTML.parseFragment() as the cure-all for potential security issues with displaying web content within the chrome context, but Jorge Villalobos even went as far as making this comment in Bugzilla: -
After reviewing these comments and the extension code, it is clear to me that the current effort to secure the add-on is misguided. You can’t just rely on ’sanitizing’ input and expect it to be “safe enough”, specially when there are clearly safer alternatives.
I have sandboxed all versions of Wizz RSS News Reader except the latest one, and all versions of Reader Lite, including the latest. Its trusted status has been revoked as well.
Mike, you have 2 weeks to correct your extension code to make it safe. You should upload the update on AMO and let us know so that we can review it. If you don’t comply by then, your latest version will be sandboxed as well. I also recommend you read our latest add-on policies (https://addons.mozilla.org/en-US/developers/docs/policies/) and make sure you
comply with all of them. For example, your current version doesn’t follow our namespacing guidelines, which makes your add-on a likely cause of compatibility problems.
Thanks to Roberto Suggi Liverani, who posted this link today – http://malerisch.net/articles/ParanoidFragmentSink_and_a_confusing_disclosure.html – it is now quite clear that my efforts were not misguided, and clearly Jorge’s “safer alternatives” weren’t safe at all!
Anyway, regardless of the stupidity of the little boys at Mozilla, nsIScriptableUnescapeHTML.parseFragment() has been fixed. It only took 16 months!
Wizz RSS hooks into nsIScriptableUnescapeHTML.parseFragment() for sanitizing web content. So, if you use a version of Firefox that includes the fixed version of nsIScriptableUnescapeHTML.parseFragment(), you’ll now be safe. Hmmmm… Well… Safer. It is pretty obvious that the self acclaimed “security experts” at Mozilla can’t be trusted, so we’ll just hope and pray that this time they actually got it right.
I have a couple issues…
1) Is it normal for WizzRSS to be really slow when moving between feeds? It takes anywhere between 5 and 20 seconds to load the feed, locking up Firefox in the mean time. I was hoping this would be fixed with version 4, but it’s about the same.
2) Often times, when I right+click and delete a link in the bookmarks tool bar, the last feed I was looking at in WizzRSS is deleted. Almost like WizzRSS is not releasing the focus to the bookmarks tool bar and the delete goes back to WizzRSS, but in a strange way because WizzRSS doesn’t popup the confirm dialog, it just deletes the feed.
I can create a couple quick screen casts if these problems aren’t already known.
Thanks…
@Bernie:
1) Please see this section of the online help – http://www.wizzrss.com/helpwiki/index.php/Clear_Watch_List_cache – It might make things a bit faster. Also, see this section of the online help – http://www.wizzrss.com/helpwiki/index.php/Retain_feed_items_for – Reducing the number of days to zero should make things much faster.
2) I’m already aware of some weirdness with the feed tree. As soon as FF4 becomes available for Ubuntu, I’ll look into it.