Closed Bug 718831 Opened 13 years ago Closed 11 years ago

Block Firebug for Firefox 9 due to bug 712289

Categories

(Toolkit :: Blocklist Policy Requests, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: jorendorff, Assigned: jorgev)

References

Details

(Keywords: qawanted)

Bug 712289 causes Firefox 9 with Firebug to crash on some platforms. The bug is probably exploitable.

The bug affects all users of certain Firefox APIs; Firebug uses those APIs extensively. All versions of Firebug are affected.

The bug is fixed in trunk and is tracking-firefox10. That is, the fix is expected to land in mozilla-aurora and mozilla-beta soon. So Firefox 9 is the only release affected.
Jorge, please stage the block but don't pull trigger yet.

Jason, are you working with the Firebug team on this? We'll need to ensure there's proper messaging and the PR team is aware.
Assignee: nobody → jorge
(adding devtools people that we should always add to Firebug things like this)
The fix has already landed on aurora and beta, fwiw, so Firefox 10 will be fine.
Has this crash been reproduced on Windows? Do we want to blocklist for all platforms?
(In reply to Jorge Villalobos [:jorgev] from comment #4)
> Has this crash been reproduced on Windows? Do we want to blocklist for all
> platforms?

From the bugs blocking 712289, we only appear to have crash reports for Mac/Linux.

Given comment#3 (landing on 10) and the fact that these crashes are only intermittent, I don't know if a blocklist entry is our best option. I believe we should just hold off until FF10.
> From the bugs blocking 712289, we only appear to have crash reports for Mac/Linux.

Yes.  The bug did not affect the Windows builds. Only the 32-bit Linux and Mac builds were affected (so on Mac only 10.5 and whatever users are running 32-bit on 10.6).
oof. yellow.

So, to be clear, this is only going to block Firebug for Firefox 9 for Mac and Linux? Can we specify only 32 bit builds get blocked or is that a too-fine-grained level of control? It will suck having this turned off for all Macs when the number of 32 bit users is probably a pretty small fraction.
We can't specify 32 bit or 64 bit in a block, as far as I know.

Also, I'm leaning towards agreeing with comment #5 and just closing this bug as WONTFIX.
I would definitely like some guidance and opinions on this decision before it's made.

We know that it affects only a subset of Linux and Mac users.

Mac makes up about 14% of Firebug's user base. Linux another 7%.

That's 21% of Firebug's users if we blocklist.

Of those, a smaller number of users are actually affected. In the case of Mac users, even though we don't have data, the number of machines capable of running 32 bit versions of Firefox are pretty small. They're limited to the first set of MacBookPros released with Intel hardware and a couple of the plastic-shelled MacBooks. Afaik, every mac released after that year is a 64bit machine. Certainly Snow Leopard made 64 bits popular.

Linux, I don't have as keen a sense about. Maybe 50% are running 64 bits, give or take?

Now that I've conjectured and hypothesized at everyone, does any of that make a bit of difference?

If we don't blocklist:

We're shipping a (potential) vulnerability to a subset of our users that may or may not be exploitable. There is a 6 week window where this will be in the wild.

If we do blocklist:

We're blocking 21% of Firebug's userbase on Firefox 9. That could be something on the order of 1000000 users.
one more datapoint:

10 goes out next week. That leaves only another 7 days of vulnerability out there. That leads me to lean more in favor of wontfixing this bug after all.
> the number of machines capable of running 32 bit versions of Firefox are pretty small.

Every single Mac on the market can run the 32-bit Mac builds.  It's just an option that you can pick.  We even prompt the user to switch when particular plug-ins that only work with the 32-bit builds are used, iirc.  I suspect the majority of our users are in fact using the 64-bit builds, but we need the actual numbers.

> That leaves only another 7 days of vulnerability out there. 

Actually, once 10 is out the only argument for not blacklisting ("it'd break some users") goes away: those users can just update to 10.  So once 10 is out I think we should _definitely_ blacklist.
Here's what I think.

  - It's too bad we can't blocklist only 32-bit builds.

  - To reiterate, I think we should blocklist Firebug immediately.

  - Someone who actually knows our policy on blocking vulnerable addons should be
    driving this discussion to a conclusion. I'll try to recruit someone on IRC.
Jan/Jason - is there anything that can happen Firebug side in a chemspill fashion to make this a non-issue? It would be nice if a point release of Firebug could close this gap so that we could block the prior, vulnerable release early.
Jan can field this one.

Unfortunately the nature of the bug makes it hard to work around it narrowly. The fix would have to be along the lines of "avoid all use of JSD" (the JavaScript debugging interface) which, assuming it's possible at all, would most likely mean hiding the whole Script tab, if not more.
On the other hand, if we can do the blocking within Firebug, we can have it block itself only in 32-bit Firefox, leaving both Windows and 64-bit Mac unaffected.
For the record, I am OK with blocklisting Firebug on Firefox 9 for Mac and Linux if that's the safest course. Getting a finer-grained control with a Firebug point release would be helpful, but I'm not sure how soon we can get that.

Would love to hear Honza's thoughts.
> On the other hand, if we can do the blocking within Firebug,
> we can have it block itself only in 32-bit Firefox,
> leaving both Windows and 64-bit Mac unaffected.
Yes, I also think this would be the best solution.

Firebug 1.9.1b1 went out couple of weeks ago and 1.9.1 dot release is planned anyway. So, this is great opportunity to include also a fix that would avoid JSD usage for 32-bit Mac and 32-bit Linux.

Btw. is using Cc["@mozilla.org/xre/app-info;1"].getService(Ci.nsIXULRuntime) + XPCOMABI + OS fields the right way to check the OS version? Is there a solid way how to distinguish between 32 and 64 bits?

I need to check how to avoid JSD usage yet, but it definitely means:
- The Script panel would be disabled
- Some command line APIs wouldn't work (like monitor and unmonitor)
- Stack traces logged in the Console panel would be sometimes wrong (but mostly correct) - Bug 703519

The advantage of "in Firebug solution" is that Firebug can offer a message (in the Script panel) suggesting a solution for the user (something like: you can use Win or Mac/Lin 64 or Firefox 10, etc.)

I'll take a look on how to avoid JSD and see whether/how it's doable. Optimistic view is that I have a patch till Friday and 1.9.1 release goes out early next week. Would that work?

Honza
I did some progress on the patch. The biggest problem so far seems to be recognizing 32/64 bit systems. Asking here:
https://groups.google.com/d/topic/mozilla.dev.platform/-ih-o9Xj3VM/discussion

Any tips?

Honza
> just testing for "x86-gcc3" is fine.
Thanks Boris

So, my OS config check looks as follows:

function isJSDSafe: function()
{
    var info = Cc["@mozilla.org/xre/app-info;1"].getService(Ci.nsIXULRuntime);
    return (info.XPCOMABI == "x86-gcc3") ? false : true;
}

Does that sound correct?

Honza
That seems fine to me, at first glance.
One more question, the problem is related only to Firefox 9 so,
Firefox 8 and 10 are ok, correct?

Honza
That's correct.  Just 9 and 9.0.1
I just uploaded Firebug 1.9.1 including a workaround for this bug to AMO.
Jorge, can you please do a quick review?

Thanks!
Honza
I reviewed it about 15 minutes ago...
As I understand it, we should now be clear to blocklist Firebug 1.9 (and below?) on FF9 (not FF10+).

Jan: do you agree from the Firebug side? 
Alex: do you agree from the Firefox side?
Should we wait at least a few days for most users to update to either Firefox 10 or Firebug 1.9.1? This will minimize the disruption caused by the block.
(In reply to Johnathan Nightingale [:johnath] from comment #28)
> As I understand it, we should now be clear to blocklist Firebug 1.9 (and
> below?) on FF9 (not FF10+).
Firebug 1.9.1 doesn't allow to activate JSD (the Script panel is disabled) in case of Mac/Linux+32bit+Firefox 9 configuration. So, I don't think blocklisting is necessary.

Honza
(In reply to Kris Maglione [:kmag] from comment #27)
> I reviewed it about 15 minutes ago...
Great, thanks!
Honza
Version 1.9.0 now has roughly 25K ADUs across all operating systems. That's about 5K non-Windows users, doing some extrapolation from other Firebug stats.

I think we should block 1.9.0, now that users have no reason not to upgrade. Any objections?
(In reply to Jorge Villalobos [:jorgev] from comment #32)
> Version 1.9.0 now has roughly 25K ADUs across all operating systems. That's
> about 5K non-Windows users, doing some extrapolation from other Firebug
> stats.
> 
> I think we should block 1.9.0, now that users have no reason not to upgrade.
> Any objections?
OK for me.

How to blocklisting process actually works?
Honza
The block is done remotely, on AMO. We would block version 1.9.0 (if there are other vulnerable versions, I need to know this) for Mac and Linux. When the blocklist is updated, users will be notified via a popup message and the add-on will be disabled. Since most of these users should have the Firebug update pending installation, restarting will update Firebug and avoid the actual block.
The block is now in place: https://addons.mozilla.org/en-US/firefox/blocked/i50
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Anthony, can you please test and verify this block? It should block version 1.9.0 of Firebug, but not 1.9.1, on Mac OS X and Linux (not on Windows). I tried a minute ago and it looks like the blocklist hasn't been updated on the server yet.
Keywords: qawanted
Jorge: I just tried this using Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0.1) Gecko/20100101 Firefox/9.0.1 and Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20100101 Firefox/9.0 and it did not seem to block that Firebug version for me. Here are my STR:

1. Download and install 1.9.0 version of Firebug
2. Force a blocklist ping according to https://wiki.mozilla.org/Blocklisting/Testing
3. Restart the browser.

I don't get the add on block UI and when I check blocklist.xml I don't see the entry listed there.

Juan mentioned that he would try as well with a debug build to see if he can provide anything more useful.

One thing I did notice is when you paste the blocklist snippet it often gave me a certificate error for addons.mozilla.org.
I tried this on Mac and Linux using Firefox 9.0, and I don't see any indication of the block. I can keep using Firebug 1.9.0 on both of these platforms even after forcing the ping and restarting, and the blocklist files don't have any entries related to Firebug.
Depends on: 737927
I don't see it either, even after recreating the blocklist entry. I filed bug 737927 to look into this.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Is this block still necessary? Since bug 737927 never got any traction, this was sort of forgotten, and now the affected audience is probably much smaller.
Flags: needinfo?(jorendorff)
Yeah, never mind, as far as I'm concerned.
Flags: needinfo?(jorendorff)
so does this need to be closed?
Status: REOPENED → RESOLVED
Closed: 13 years ago11 years ago
Resolution: --- → WONTFIX
Product: addons.mozilla.org → Toolkit
Group: addons-security, client-services-security
You need to log in before you can comment on or make changes to this bug.