And here is the incentive - If you’d like Wizz RSS to stop displaying the nag page, make a donation through PayPal (no matter how small the donation), and you’ll be able to download a nag free version of Wizz RSS.

If you are unable to make a donation, you can still deactivate the nag page by following the step-by-step instructions outlined in this blog post. The nag free version of Wizz RSS contains exactly the same change as that outlined in the blog post. This means that no one is forced to make a donation to rid themselves of the nag page.

If you don’t mind living with the nag page, there are no other changes in the nag free version. So you will not be missing out on any changes, improvements, or bug fixes.

If you have already made a PayPal donation, you should receive an email asking you to claim your nag free version of Wizz RSS.

Over the years that Wizz RSS has been around, many people made donations through ClickBank. Unfortunately I no longer have access to the old ClickBank account, and am thus unable to add those donor email address to the database. So, if you made a donation through ClickBank, please get in touch with me, and I’ll add your email address to the donor database.

Bookmark It

Hide Sites

Anyway, all of the following should be working again. If it isn’t working correctly, please let me know so that I can fix it: -

1. Weather
2. Create Account
3. Change Password
4. Save Feeds to Server
5. Restore Feeds from Server

Bookmark It

Hide Sites

if (Date.parse(today) != readPref(”WizzRSSLastCheck”, “0″, 1)) {
    writePref(”WizzRSSLastCheck”, Date.parse(today), 1);
    //setTimeout(”checkUpdates()”, 30000);
}

7. Save the changes to toolbar.js
8. Re-zip everything and rename the resulting .zip to .jar
9. Restart Firefox.

Bookmark It

Hide Sites

Before installing either of these versions, please read the following, which applies to both of these patched versions: -

1. I have made absolutely no attempt to address the namespacing issue, and I have no intention of addressing it either. The namespacing issue has absolutely no impact whatsoever on the vulnerability issue. A non-technical explanation of the namespacing issue for the non-technical types: Because Wizz RSS does not comply with the namespacing guidelines, it is possible that Wizz RSS code could interfere with the workings of Firefox or with the workings of other add-ons you have installed. This is not a new issue! Wizz RSS code has always been like this.
2. I have implemented nsIScriptableUnescapeHTML.parseFragment() as recommended by Wladimir Palant. For the non-technical types, you can find out more about nsIScriptableUnescapeHTML.parseFragment() here.
3. Because nsIScriptableUnescapeHTML.parseFragment() doesn’t seem to work as advertised by the Firefox “security experts,” I have also retained the “blacklist-based input sanitizing at its best” (Wladimir Palant’s sarcastic words) - as poo pooed by Jorge Villalobos. The fact that nsIScriptableUnescapeHTML.parseFragment() doesn’t seem to work as advertised is borne out by the fact that removal of the “blacklist-based input sanitizing at its best” (i.e. Sole reliance on nsIScriptableUnescapeHTML.parseFragment()), causes vulnerabilities that were fixed in 2007 to reappear. Please read http://wizzrss.blat.co.za/2009/11/17/so-much-for-nsiscriptableunescapehtmlparsefragment/ for more details.

Hopefully, what I have done with the code will address the vulnerability issues for once and for all - But I sure ain’t no security expert, so I’m not going to guarantee that!

If you are using Firefox 3.5.n, you can install Wizz RSS 3.1.0.5 here Please note that I have not tested this distributable as I’m currently using Firefox 3.6b2, which I’m not going to uninstall. The fix in 3.1.0.5 is exactly the same as the fix in 3.2.0.0.

If you are using Firefox 3.6b1 or later, you can install Wizz RSS 3.2.0.0 here

Bookmark It

Hide Sites

My few hours of trying to implement nsIScriptableUnescapeHTML.parseFragment() have shown me that both Wladimir Palant and Jorge Villalobos are wrong!

Back in March 2007, Jefferson Ogata of NOAA Computer Incident Response Team (N-CIRT), lodged a vulnerability report with US-CERT (Details of the vulnerability report can be seen here and here) with regard to vulnerability discovered in Wizz RSS 2.1.7 (And earlier). Jefferson Ogata very kindly worked with me for quite a few weeks on plugging the vulnerability. Jefferson offered advice and I coded his recommendations. Jefferson would then test my fixes against a set of potentially malicious test cases, and when we were both happy that the vulnerability had successfully been plugged, version 2.1.9 was released and was made public.

So, while nsIScriptableUnescapeHTML.parseFragment() successfully deals with vulnerabilities in Wizz RSS uncovered by Wladimir Palant, it certainly does not deal with all of those uncovered by Jefferson Ogata in 2007!

Makes me wonder how may other Firefox extensions have implemented nsIScriptableUnescapeHTML.parseFragment(), believing that it would sanitize potentially malicious code? Also makes me wonder if the “security experts” actually know what they are talking about.

Bookmark It

Hide Sites

I know for a fact that many people ignore warnings that I have posted over the years. On two previous occasions I have posted warnings with regard to backing up feeds before upgrading to a newer version of Firefox, only to have people get on my case when their feeds went missing.

To those of you who have chosen not to uninstall Wizz RSS: Sorry for the inconvenience. I promise that it won’t continue forever. If only one single Wizz RSS user gets hacked because they didn’t see the notification about the vulnerabilities, I would probably be held responsible. When I’m happy that all ± 100 000 Wizz RSS users have seen and read the notification, I’ll turn the irritating notification off.

Bookmark It

Hide Sites

There has been an ongoing security issue with regard to the Wizz RSS code. The problem was first reported by Wladimir Palant in December 2008, and a Security Vulnerability Report was lodged by Nick Freeman of Security-Assessment.com in February 2009. The vulnerabilities were addressed by myself in accordance with Nick Freeman’s report (Which also covered the original vulnerability reported by Wladimir Palant), and a patched version of Wizz RSS (I can’t remember the version number) was made public.

In Wladimir Palant’s original report (Which I suspect very strongly was motivated an ulterior agenda - Which of course he denies) the recommendation was made that I use nsIScriptableUnescapeHTML.parseFragment() to plug the vulnerability. I tired unsuccessfully to apply nsIScriptableUnescapeHTML.parseFragment(), but being satisfied that the vulnerabilities reported by Nick Freeman had successfully been plugged, I didn’t worry about it.

Because the original report by Wladimir Palant was never closed, on 11 November Wil Clouser asked Jorge Villalobos to look into the matter. I responded to Wil Clouser’s request, saying that Wladimir Palant, as the original reporter of the problem, should check my reported vulnerability fix, which he eventually did. The result of Wladimir Palant’s check turned up another vulnerability, and another recommendation that I apply nsIScriptableUnescapeHTML.parseFragment(). Once again I unsuccessfully attempted to apply nsIScriptableUnescapeHTML.parseFragment(). Even though my attempt to apply nsIScriptableUnescapeHTML.parseFragment() was unsuccessful, I still managed to plug the new vulnerability and I made a patched version of the code available for further testing.

On 12 November Wladimir Palant offered a snippet of code explaining the implementation nsIScriptableUnescapeHTML.parseFragment(). Being very grateful for the snippet and explanation, I was about to apply it to the code when I read this comment by Jorge Villalobos (The final straw): -

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.

And here is my response to Jorge’s comment: -

@Jorge: Five years ago, when I first started working on this extension, there
were no namespacing guidelines. As far as I’m aware, there has never been any
request for older extensions (i.e. Those that don’t comply with the namespacing
guidelines) to be updated to conform with the namespacing guidelines. Perhaps,
if you want to be consistent with the namespacing guidelines that you want to
now enforce of me, you should take a look at all of the older extensions?

To be perfectly honest, I have much better things to do with my life than to
waste anymore of it on Firefox.

Bookmark It

Hide Sites

Anyway, once again I’m asking Wizz RSS users to test 3.2.0.0 on Firefox 3.6b1. I’m pretty sure that my request to test will, as is usually the case, fall on deaf ears. Of course testing is always someone else’s problem - WRONG! We’d all like to see a smooth upgrade to Firefox 3.6, so please help with testing!

Yes you can test! It doesn’t take any special skills! Just upgrade to Firefox 3.6b1 and install Wizz RSS 3.2.0.0 - Easy! If you find any bugs, report them into this blog and I’ll fix them as quickly as I can.

You can get 3.2.0.0 here

Bookmark It

Hide Sites

The Wizz RSS code is not at fault! I had to dig into the StumbleUpon code to find the real cause, and here it is: -

In stumbleuponOverlay.js you’ll find the following: -

var toolbars = document.getElementsByTagName("toolbar");
var i;
for (i = 0; i < toolbars.length; i++)
{
    if (! toolbars[i].hasAttribute("customizable"))
        continue;
    if (toolbars[i].getAttribute("customizable").toLowerCase() != "true")
        continue;
    su_is_item_in_toolbox(true, "su_toolbaritem", toolbars[i]);
    if (toolbars[i].id == toolbar_position)
        su_place_toolbaritem(toolbars[i], position_group);
}

If you understand JavaScript you’ll notice that the code gets all elements with the tag name toolbar. Regardless of whether these elements belong to StumbleUpon or not, the code then proceeds to check each toolbar element for the customizable attribute, and if the customizable attribute has any value apart from true, the code performs all sorts of nasty things to the toolbar in the su_place_toolbaritem() function.

And Wizz RSS’ crime? It sets the customizable=”false” attribute for its toolbar! The customizable attribute is perfectly admissible, and can be used by any toolbar - See Mozilla documentation at https://developer.mozilla.org/en/XUL/toolbar#a-customizable

So, all of you who have been experiencing toolbar weirdness, I suggest you get on StumbleUpon’s case

Bookmark It

Hide Sites

1. Install Wizz RSS version 3.1.0.4
2. Restart Firefox after installing 3.1.0.4 (The usual Firefox restart after installing an add-on)
3. The toolbar might still look weird after the restart. Wait a few seconds and restart Firefox again
4. After the 2nd restart, the toolbar should be back to normal, and hopefully, will stay that way

Bookmark It

Hide Sites