Last Comment Bug 370445 - (CVE-2007-0981) embedded nulls in location.hostname confuse same-origin checks (Zalewski XSS vulnerability)
(CVE-2007-0981)
: embedded nulls in location.hostname confuse same-origin checks (Zalewski XSS ...
Status: RESOLVED FIXED
[sg:high] xss
: verified1.8.0.10, verified1.8.1.2
Product: Core
Classification: Components
Component: Networking (show other bugs)
: 1.8 Branch
: All All
: -- major with 4 votes (vote)
: ---
Assigned To: Daniel Veditz [:dveditz]
:
Mentors:
Depends on:
Blocks: 370501
  Show dependency treegraph
 
Reported: 2007-02-14 15:23 PST by Daniel Veditz [:dveditz]
Modified: 2007-02-26 18:51 PST (History)
50 users (show)
dveditz: blocking1.8.1.2+
dveditz: wanted1.8.1.x+
dveditz: blocking1.8.0.10+
dveditz: wanted1.8.0.x+
bzbarsky: in‑testsuite?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Stop hostname attack (2.87 KB, patch)
2007-02-15 05:51 PST, Daniel Veditz [:dveditz]
no flags Details | Diff | Review
sledgehammer approach to fix ::SetSpec (3.30 KB, patch)
2007-02-15 12:07 PST, Daniel Veditz [:dveditz]
no flags Details | Diff | Review
more limited null squashing in setSpec (3.57 KB, patch)
2007-02-15 13:14 PST, Daniel Veditz [:dveditz]
no flags Details | Diff | Review
Third patch + dbaron's comments (4.00 KB, patch)
2007-02-15 14:00 PST, Daniel Veditz [:dveditz]
bzbarsky: review+
darin.moz: review+
dbaron: superreview+
jaymoz: approval1.8.1.2+
jaymoz: approval1.8.0.10+
Details | Diff | Review

Description Daniel Veditz [:dveditz] 2007-02-14 15:23:29 PST
Michal Zalewski sent the following mail to security@mozilla.org, full-disclosure and bugtraq:
- - - - - - - - - - - - - - - - - - - - -
There is a serious vulnerability in Mozilla Firefox, tested with 2.0.0.1,
but quite certainly affecting all recent versions.

The problem lies in how Firefox handles writes to the 'location.hostname'
DOM property. It is possible for a script to set it to values that would
not otherwise be accepted as a hostname when parsing a regular URL -
including a string containing \x00.

Doing this prompts a peculiar behavior: internally, DOM string variables
are not NUL-terminated, and as such, most of checks will consider
'evil.com\x00foo.example.com' to be a part of *.example.com domain. The
DNS resolver, however, and much of the remaining browser code, operates on
ASCIZ strings native to C/C++ instead, treating the aforementioned example
as 'evil.com'.

This makes it possible for evil.com to modify location.hostname as
described above, and have the resulting HTTP request still sent to
evil.com. Once the new page is loaded, the attacker will be able to set
cookies for *.example.com; he'll be also able to alter document.domain
accordingly, in order to bypass the same-origin policy for XMLHttpRequest
and cross-frame / cross-window data access.

A quick demonstration is available here:

  http://lcamtuf.dione.cc/ffhostname.html

If you want to confirm a successful exploitation, check Tools -> Options
-> Privacy -> Show Cookies... for coredump.cx after the test; for the demo
to succeed, the browser needs to have Javascript enabled, and must accept
session cookies.

The impact is quite severe: malicious sites can manipulate authentication
cookies for third-party webpages, and, by the virtue of bypassing
same-origin policy, can possibly tamper with the way these sites are
displayed or how they work.

Regards,
/mz
Comment 1 Ben Bucksch (:BenB) 2007-02-14 15:30:42 PST
The bug is filed under Networking: Cookies. It depends on the code, but the way I understand the bug is that Mozilla thinks the data comes from coredump.cx although it actually comes from dione.cc. Cookies are just one victim of this misbelief, but there are probably more implications.
Comment 2 Anbo Motohiko 2007-02-14 20:18:04 PST
How many sites use setting 'location.hostname'?
Workaround: deny setting location.hostname.

user_pref("capability.policy.default.Location.hostname.set", "noAccess");
Comment 3 Boris Zbarsky [:bz] 2007-02-14 22:24:36 PST
> How many sites use setting 'location.hostname'?

You tell me.  There are stats on this sort of thing out there, last I checked.

We should probably just sanitize location.hostname.  Or rather nsStandardURL::SetHost should do whatever it is that SetSpec does wrt nulls, no?
Comment 4 Bill Privare 2007-02-14 23:18:06 PST
This is cute.  I made a comment an hour or more ago, and it does not appear here.  I can only infer that there is moderation going on (in the strictest sense of the word). Because my training is security, in addition to application development, is my technical assessment less valued?

If it was a burp in the bugzilla software, then "never mind" :-)

I'll stand by my comments - this is a very serious issue, please don't dismiss it or treat it with flip comments.  There are millions of Firefox users, some of them are going to be victimized - not just "at risk".

Thanks for listening.
Comment 5 :Gavin Sharp [email: gavin@gavinsharp.com] 2007-02-14 23:21:48 PST
Comments on this bug and all other bugs on bugzilla.mozilla.org are not moderated in any way. If you posted a comment and it doesn't appear here, there must have been a problem with your submission.
Comment 6 Boris Zbarsky [:bz] 2007-02-14 23:40:07 PST
Ah, so SetSpec() doesn't so much deal with this either.  It produces some inconsistent state.  In particular, all the segment offsets/lengths are relative to the original URI string, while the mSpec is truncated at the null due to http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/base/src/nsStandardURL.cpp&rev=1.95&mark=640#640 at the end of BuildNormalizedSpec.

I think we should consider just throwing from all this stuff if an unexpected null is found after escaping, etc...
Comment 7 Daniel Veditz [:dveditz] 2007-02-15 05:51:43 PST
Created attachment 255211 [details] [diff] [review]
Stop hostname attack

This stops the attack in the bug.

There's some pre-existing weirdness involving setting .hash and .search, but they handle nulls OK and don't affect the domain.
Comment 8 Daniel Veditz [:dveditz] 2007-02-15 06:03:07 PST
(In reply to comment #0)
> Once the new page is loaded, the attacker will be able to set
> cookies for *.example.com; he'll be also able to alter document.domain
> accordingly, in order to bypass the same-origin policy for XMLHttpRequest
> and cross-frame / cross-window data access.

This allows document.domain to be set maliciously which can be used to attack pages that explicitly set the same document.domain. That will limit a same-orgin violation attack considerably, although it only takes one document.domain-setting page on a site to make the whole site vulnerable.

XMLHttpRequest is always based on the original location, ignoring any document.domain so this vulnerability does not enable arbitrary XMLHttpRequest attacks. If you find a page that sets document.domain you could inject the XHR into that page and abuse that site, but not sites that do not use document.domain.
Comment 9 Michal Zalewski 2007-02-15 07:23:16 PST
Oh, yup, you are correct - contrary to some sources, XMLHttpRequest() indeed pays no attention to document.domain in FF. Strike that then. The cross-domain frame attack is somewhat less relevant, anyway: the ability for a malicious site to inject previously acquired, known session cookies into the browser, so that the victim then authenticates within attacker's session, is nasty.

Side note: there are several other unusual problems in how document location updates work. I stumbled upon these, but did not research them in any detail. The one where a script suddenly seems to have document.location in about: namespace may have some implications. A quick demo page can be found there: http://lcamtuf.coredump.cx/fftests.html

Comment 10 Boris Zbarsky [:bz] 2007-02-15 08:11:36 PST
Comment on attachment 255211 [details] [diff] [review]
Stop hostname attack

Do we want to address the SetSpec issue too?
Comment 11 Boris Zbarsky [:bz] 2007-02-15 08:18:47 PST
> http://lcamtuf.coredump.cx/fftests.html

The "about:" button on that page just gives me an infinite number of alerts.  All of them say "data:....." in current trunk.  Is that the expected "correct" behavior?  Seems a little odd.  ;)  In any case, that testcase seems to be about bug 337260.  Running script in about:blank (which is what happens on branch here) is safe, for what it's worth.
Comment 12 Wolf Peuker 2007-02-15 12:04:57 PST
in reply to Comment #2:
> user_pref("capability.policy.default.Location.hostname.set", "noAccess");

(How) can I use this workaround as firefox user? 
Is it accessible via about:config?

Thanks for the help
Comment 13 Daniel Veditz [:dveditz] 2007-02-15 12:07:30 PST
Created attachment 255245 [details] [diff] [review]
sledgehammer approach to fix ::SetSpec

This works for ::SetSpec, but a global check like this kills all nulls and most parts of the URI are perfectly happy to encode them.

Another way to do it would be to rely on the encoding routines for the rest of the spec and check the hostname specifically in BuildNormalizeSpec() right before the NormalizeIDN call.
Comment 14 jay garcia 2007-02-15 12:16:34 PST
(In reply to comment #12)
> in reply to Comment #2:
> > user_pref("capability.policy.default.Location.hostname.set", "noAccess");
> 
> (How) can I use this workaround as firefox user? 
> Is it accessible via about:config?
> 
> Thanks for the help
> 

Add the line to your user.js file. If you don't have one, create one in notepad for example and name it user.js and put it in your profile directory where prefs.js is located. 


Comment 15 Wolf Peuker 2007-02-15 12:48:04 PST
(In reply to comment #14)
> (In reply to comment #12)
> > in reply to Comment #2:
> > > user_pref("capability.policy.default.Location.hostname.set", "noAccess");
> > 
> > (How) can I use this workaround as firefox user? 
> > Is it accessible via about:config?
> > 
> > Thanks for the help
> > 
> 
> Add the line to your user.js file. If you don't have one, create one in notepad
> for example and name it user.js and put it in your profile directory where
> prefs.js is located. 
> 

Thanks a lot,
before adding a user.js, I had a look in file prefs.js and there was the line already!
  My first intention (before comment #12) was to add it in about:config via
  context popup > new > string
  name: capability.policy.default.Location.hostname.set
  value: noAccess
this seems to work, at least I think so.(?)
Comment 16 Daniel Veditz [:dveditz] 2007-02-15 13:14:38 PST
Created attachment 255249 [details] [diff] [review]
more limited null squashing in setSpec

I think I like this better than attachment 255245 [details] [diff] [review] -- nulls in other parts of the URI get escaped to %00 as before, just in case anyone's relying on that behavior.
Comment 17 Daniel Veditz [:dveditz] 2007-02-15 13:17:50 PST
Comment on attachment 255249 [details] [diff] [review]
more limited null squashing in setSpec

We don't need both patches, either the narrow first one or this slightly broader one. sticking different reviewers on just to get more attention.
Comment 18 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2007-02-15 13:17:51 PST
Comment on attachment 255245 [details] [diff] [review]
sledgehammer approach to fix ::SetSpec

>Index: netwerk/base/src/nsSimpleURI.cpp
> NS_IMETHODIMP
> nsSimpleURI::SetScheme(const nsACString &scheme)
> {
>+    const nsPromiseFlatCString &flat = PromiseFlatCString(scheme);
>+    if (!net_IsValidScheme(flat)) {
>+        NS_ERROR("the given url scheme contains invalid characters");
>+        return NS_ERROR_UNEXPECTED;
>+    }
>+

I wonder whether this should be NS_ERROR_MALFORMED_URI.

It seems like nsSimpleURI::SetSpec should probably also have a net_IsValidScheme check -- and maybe even additional null-byte checks -- although I'm not sure what the behavior of NS_EscapeURL is on embedded nulls (does it escape them?).  From a quick glance it seems like nsSimpleURI stores the escaped URL and nsStandardURL stores the unescaped URL, although I'm not looking too closely (yet).

>Index: netwerk/base/src/nsStandardURL.cpp
>+    if (strlen(spec) < specLength)
>+        return NS_ERROR_UNEXPECTED; // embedded null
>+
>     // filter out unexpected chars "\r\n\t" if necessary
>     nsCAutoString buf1;
>     if (net_FilterURIString(spec, buf1)) {

I wonder whether this should be NS_ERROR_MALFORMED_URI, and also whether we should instead just make net_FilterURIString filter out the nulls just like the other chars in the code quoted.

>+    if (host && strlen(host) < flat.Length())
>+        return NS_ERROR_UNEXPECTED; // found embedded null

Likewise about the error code.

>Index: netwerk/base/src/nsURLHelper.cpp
>     for (; schemeLen && *scheme; ++scheme, --schemeLen) {
>         if (!(nsCRT::IsAsciiAlpha(*scheme) ||
>               nsCRT::IsAsciiDigit(*scheme) ||
>               *scheme == '+' ||
>               *scheme == '.' ||
>               *scheme == '-'))
>             return PR_FALSE;
>     }
> 
>+    if (schemeLen != 0)  // found embedded null
>+        return PR_FALSE;

It would be simpler to just replace:

>-    for (; schemeLen && *scheme; ++scheme, --schemeLen) {
>+    for (; schemeLen; ++scheme, --schemeLen) {

and maybe comment that you want to forbid embedded nulls.
Comment 19 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2007-02-15 13:25:02 PST
But, yeah, I think I like the third patch better than the second, and I think that makes my net_FilterURIString comment obsolete.
Comment 20 Daniel Veditz [:dveditz] 2007-02-15 14:00:12 PST
Created attachment 255252 [details] [diff] [review]
Third patch + dbaron's comments

nsSimpleURI::SetSpec was null-safe because of the NS_EscapeURL() call (esc_OnlyNonAscii escapes 00-1f also), but I added the net_IsValidScheme check anyway because the current code accepts other invalid schemes like "me$$y:". Not strictly part of this bug and probably wasn't harmful.

Other than that I changed the error codes and the for() condition in net_IsValidScheme.
Comment 21 Boris Zbarsky [:bz] 2007-02-15 14:06:47 PST
Comment on attachment 255252 [details] [diff] [review]
Third patch + dbaron's comments

r=bzbarsky given that we need a fix on branches, but I do think that darin or biesi should look at this too... they know this code a lot better than I do.
Comment 22 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2007-02-15 14:22:12 PST
Comment on attachment 255252 [details] [diff] [review]
Third patch + dbaron's comments

>+    // nsCStrings may have embedded nulls -- reject those too

might want to say "counted strings" rather than "nsCStrings"


Anyway, sr=dbaron, although I'd also say it would be good to get darin and/or biesi to look at this when possible.  (e.g., I don't really know whether you should be returning NS_ERROR_UNEXPECTED or NS_ERROR_MALFORMED_URI or whether it matters, etc.)
Comment 23 Andreas Otte 2007-02-15 15:27:18 PST
NS_ERROR_MALFORMED_URI seems the logical choice to me, NS_ERROR_INVALID_HOSTNAME never made it into the tree.
Comment 24 Jay Patel [:jay] 2007-02-15 15:59:14 PST
Comment on attachment 255252 [details] [diff] [review]
Third patch + dbaron's comments

Approved for both branches, a=jay
Comment 25 Daniel Veditz [:dveditz] 2007-02-15 17:13:58 PST
Comment on attachment 255252 [details] [diff] [review]
Third patch + dbaron's comments

Would like an eventual look-see from Darin on this.
Comment 26 Daniel Veditz [:dveditz] 2007-02-15 17:14:46 PST
Fix checked into trunk, 1.8 and 1.8.0 branches
Comment 27 Darin Fisher 2007-02-15 22:42:35 PST
Comment on attachment 255252 [details] [diff] [review]
Third patch + dbaron's comments

r=darin

could similar tricks be played with the userpass field?
Comment 28 (not reading, please use seth@sspitzer.org instead) 2007-02-15 23:53:30 PST
> could similar tricks be played with the userpass field?

darin, do you mean by embedding nulls into the value passed into location.href?

Comment 29 Darin Fisher 2007-02-16 00:02:26 PST
> darin, do you mean by embedding nulls into the value passed into location.href?

yes, or via XMLHttpRequest.open
Comment 30 georgi - hopefully not receiving bugspam 2007-02-16 02:06:23 PST
0 in window.open() terminates the whole string.
0 in iframe.src sets the location to about:blank on latest trunk but src still contains 0.
Comment 31 Daniel Veditz [:dveditz] 2007-02-16 11:50:02 PST
If you try to mess with the userpass by setting location.href it gets escaped in BuildNormalizedSpec. If you try to set a null-containing userpass using location.hostname it gets caught and rejected.
Comment 32 Jordan M. 2007-02-16 12:26:03 PST
(In reply to comment #30)
> 0 in iframe.src sets the location to about:blank on latest trunk but src still
> contains 0.
> 

Does this have any effect on the effectiveness of the patch? Or is this not a security issue?
Comment 33 Jordan M. 2007-02-16 13:12:39 PST
(In reply to comment #9)
> http://lcamtuf.coredump.cx/fftests.html
> 

Are all of these issues with locations.hostname? Are number 3 and 4 anything to worry about, or has no one investigated those two?
Comment 34 Daniel Veditz [:dveditz] 2007-02-16 14:11:53 PST
#1 (both versions) is just an "oddity" as the page says, perfectly safe.
perhaps we should reconsider our policy of showing nothing when the location is "about:blank", or at least if the document is not completely empty. In normal use modified "about:blank" pages are in frames with nothing that would show their location anyway.

#2 is a bug, but harmless (neutered privileges)

#3 is fixed by this patch.

#4 is a JavaScript performance problem dealing with strings 131072 characters long.
Comment 35 Jordan M. 2007-02-16 14:27:57 PST
(In reply to comment #34)
> #1 (both versions) is just an "oddity" as the page says, perfectly safe.
> perhaps we should reconsider our policy of showing nothing when the location is
> "about:blank", or at least if the document is not completely empty. In normal
> use modified "about:blank" pages are in frames with nothing that would show
> their location anyway.
> 
> #2 is a bug, but harmless (neutered privileges)
> 
> #3 is fixed by this patch.
> 
> #4 is a JavaScript performance problem dealing with strings 131072 characters
> long.
> 
Thanks, just wanted to make sure everything was being honored here.
Comment 36 Boris Zbarsky [:bz] 2007-02-16 14:36:51 PST
> #4 is a JavaScript performance problem dealing with strings 131072 characters
> long.

I can't even reproduce the issue on trunk; is that problem branch-only (or only if error pages are disabled) or something?
Comment 37 Michal Zalewski 2007-02-16 14:58:38 PST
(In reply to comment #34)
> #1 (both versions) is just an "oddity" as the page says, perfectly safe.

Actually, probably not, see my demos at:
http://lcamtuf.coredump.cx/ffblank/

But I filed this as a separate bug 370555.

/mz
Comment 38 Brendan Eich [:brendan] 2007-02-16 16:02:57 PST
(In reply to comment #34)
> #4 is a JavaScript performance problem dealing with strings 131072 characters
> long.

No, it's not a JS performance problem.

/be
Comment 39 Jay Patel [:jay] 2007-02-16 16:45:36 PST
v.fixed on both branches with:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2) Gecko/20070215 Firefox/2.0.0.2
and
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.10) Gecko/20070216 Firefox/1.5.0.10

Original exploit testcase http://lcamtuf.dione.cc/ffhostname.html and test #3 from http://lcamtuf.coredump.cx/fftests.html both pass with the latest rc builds.  

Tests #1 and #2 from http://lcamtuf.coredump.cx/fftests.html are being discussed in bug 370555 and test #4 needs more investigation to determine whether it is an JS issue or something else.
Comment 40 Daniel Veditz [:dveditz] 2007-02-17 01:07:35 PST
(In reply to comment #38)
> No, it's not a JS performance problem.

It's a performance problem with code written in JavaScript, did not mean to impugn the JS engine itself.

It appears to be in the safebrowsing code, the stack always seems to have nsXPCnsUrlClassifierCallbackWrapper::HandleEvent in it. Setting browser.safebrowsing.enabled to false seems to clear the problem.
Comment 41 Michal Zalewski 2007-02-17 14:30:29 PST
(In reply to comment #34)
> #2 is a bug, but harmless (neutered privileges)

[...fetting off-topic for that bug entry, but hey...]

This one might be not that harmless after all, either. The general problem seems to be that when a "blocking" Javascript event is taking place (alert(), prompt(), synchronous XMLHttpRequest.open, etc), other scripts running at that time will have limited permissions, including browser code - that nevertheless retains some of its privileges because of the namespace it originates from.

Consider this: body onload handler on a malicious page updates document.location to foo.cgi, which pauses for 1 s, then returns application/octet-stream .exe file; the same handler also sets a 100ms timeout to a function that issues a synchronous XMLHttpRequest.open() to bar.cgi, which pauses for, say, 2 seconds, and returns some text; as a result, a toothless but still partly operational download prompt will be rendered (the "privileged" code will be not able to declare event handlers, access keys, etc - disabling some of the anti-phishing security measures - but will be able to perform actions such as running an external application). Although this example is not particularly "exploitable", races like this are likely to have security implications.

Browser code aside, two unrelated pages can apparently interfere with the ability for the other page to carry out certain actions without getting NS_ERROR_DOM_XPCONNECT_ACCESS_DENIED, no ability to create event handlers, access keys, etc. 
Comment 42 Michal Zalewski 2007-02-17 14:32:56 PST
(In reply to comment #41)

Testcase: http://lcamtuf.coredump.cx/tx/
Comment 43 Boris Zbarsky [:bz] 2007-02-18 16:45:15 PST
> The general problem seems to be that when a "blocking" Javascript event is
> taking place (alert(), prompt(), synchronous XMLHttpRequest.open, etc)

I'm curious that you're lumping those together.  While synchronous XMLHttpRequest does have the problem you describe (see bug 326777) it should not be an issue for alert() and prompt().
Comment 44 Boris Zbarsky [:bz] 2007-02-18 18:06:26 PST
I filed the performance bug as bug 370860.
Comment 45 downie 2007-02-18 22:57:28 PST
I tried the workaround putting 
user_pref("capability.policy.default.Location.hostname.set", "noAccess");
in user.js in ~/library/Mozilla/Profiles/default/vg9m3khy.slt/
but M.Zalewski's still shows FF as vulnerable even after restarting.
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-GB; rv:1.8.0.9) Gecko/20061206 IE
Hope the update is available soon.
Thanks for the hard work on this.
BTW I assume 'document.location=' is covered by the same fix.
Comment 46 Michal Zalewski 2007-02-19 01:22:51 PST
(In reply to comment #43)
> I'm curious that you're lumping those together.  While synchronous
> XMLHttpRequest does have the problem you describe (see bug 326777) it should
> not be an issue for alert() and prompt().

I can't see that and many some security-related bugs mentioned here and in related reports, sorry. The example given in my fftests.html testcase seems to affect about:neterr in a very similar manner through alert('') popup.

Comment 47 Fred Yontz 2007-02-20 11:30:35 PST
I tried the quick demo of this bug in comment #1, and got a return of "YOUR BROWSER IS VULNERABLE" in my SeaMonkey 1.1 browser.  So Firefox doesn't stand alone on this, but I am surprised that no mention was made of SeaMonkey in the 46 comments already entered.
Comment 48 Boris Zbarsky [:bz] 2007-02-20 11:47:31 PST
All the code in question is shared, so there's no need to talk about every single Gecko-based browser separately.
Comment 49 Fred Yontz 2007-02-20 20:57:42 PST
This would be obvious to the persons working on this bug, the "in" crowd if you will.  But for less technical, less involved users I don't think this would be a clear assumption; I certainly didn't take it for granted.  

You say all the code 'in question' is shared, but that implies that some other code may not be common among all browsers, and if that is true, if the different Mozilla family browsers differ in some respects, in some code segments, then I don't think it's reasonable to expect all readers of these bug reports to know the difference.  It seems a small addition to clarify if a bug affects all in the family, or spell out which ones are included.
Comment 50 Brendan Eich [:brendan] 2007-02-20 22:40:00 PST
Fred Yontze, please read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html and study http://www.mozilla.org/bugs/ -- you should also read https://bugzilla.mozilla.org/describecomponents.cgi if you haven't yet -- and stop spamming this bug.

This bug is in the Core product, Networking component. That's enough for anyone who is at all familiar with bugzilla and Mozilla's use of it to know this bug is about the shared "core" code at the center of all XUL applications. Your job as a newcomer is to learn this other than by complaining in comments in bugs.

/be
Comment 51 Brendan Eich [:brendan] 2007-02-20 22:41:05 PST
(Fred: sorry for misspelling your name -- typo)

/be
Comment 52 Boris Zbarsky [:bz] 2007-02-26 18:51:08 PST
> seems to affect about:neterr in a very similar manner through alert('') popup.

Indeed.  I filed bug 371858 on that issue.

Note You need to log in before you can comment on or make changes to this bug.