User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20081201 Minefield/3.1b3pre (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20081201 Minefield/3.1b3pre (.NET CLR 3.5.30729) I just visited a site that sent me over 40 cookies (different sites). It took time to clear the thing and go on browsing, since FF does not allow to go one until the dialogs are gone.. a sort of thing that can be extend to a little "DoS". The repro code like this (not good one, but still): <script> var i=0; for(i=0;i<1000;i++) { var x=new XMLHttpRequest(); x.onreadystatechange=chg(x); x.open("GET", "http://<mailiciousurl>/maliciouspage.aspx",true); x.send(null) } function chg() { } </script> will crash FF. In the lesser extent it can open hundreds of cookie dialogs.. and it can also kill the machine. Reproducible: Always Steps to Reproduce: 1. Create a page that sends cookies 2. Create a page that uses the script above to get the cookie page 3. Run it (just to be sure, open a few tabs, empty ones do fine too) Actual Results: In this chas, loop of 1000, it crashed FF (crash id f81b005d-0e37-4435-9921-eed142081202).. a loop of 100 opened 100 dialogs (just did not click all of them, but an average user maybe would, cursing loudly I'd guess) Expected Results: no crash, no unusable browser.. If I get 1000 of cookies, something is wrong, and FF should shield the user from the consequences.

Step 1 in the "Steps to Reproduce" should probably be to set the preference for cookie confirmation, which is not set by default. I'm not even sure where it is in the UI. Did you set it in about:config?

The preference is network.cookie.lifetimePolicy which should be set to 1 to prompt the user each time a site wants to set a cookie. This corresponds to the UI preference: Privacy > Cookies > Keep until: ask me every time. I'm unable to reproduce this issue. I set up a test page that sets a random cookie when requested and I am able to load the testcase which opens a XHR to the cookie-setting page 1000 times. Even with the "ask me every time" pref set, I can still click through the Allow dialog each time without seeing a crash. We store the 50 most recently set cookies as per our cookie limit per domain. Is there some other behavior that your maliciouspage.aspx is doing that we should be accounting for?

This sounds like a relatively harmless DoS, right? Would be nice to know more about the crashing you're seeing, but this isn't much different than a while (true) { alert() } loop in practice.

@David: As Brandon wrote, yes, I have a non default "ask me every time" cookie setting. But I don't think that my settings are that uncommon. @Brandon: I made a little repro on our servers. The links are: http://nettest.trilogica.it/cookietest100.aspx for 100 cookies and http://nettest.trilogica.it/cookietest1000.aspx for 1000 cookies (the one that crashes at least my FF3.1b3pre). The page that is being called does nothing special, just sends 2 cookies. Nothing else. Just remember we do not have unlimited bandwidth.. :) @Gavin: I agree with you, it is relatively small DoS, in a way. But my trouble is that it can be extended to kill even the OS (maybe for resource exhaustion or something). Need to repro that too. The crash id for the 1000 cookies case is f81b005d-0e37-4435-9921-eed142081202. I still think that somehow, even that the user has not set "ask me every time" pref on, FF should prevent this kind of "misuse". IMHO, that is.

I'm still not able to reproduce this issue using the latest nightly build: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081203 Shiretoko/3.1b3pre I let the 1000 cookie test case run to completion, and I didn't get a crash. I clicked through about the first 100 cookie prompts manually, and then told the browser to use the same decision for all subsequent cookies. I don't have a Vista machine to test this on, so perhaps someone else can confirm this.

bp-f81b005d-0e37-4435-9921-eed142081202 is a stack overflow crash, but the threads don't look recursive so that's going to be highly dependent on the OS and how much memory you have. nsScriptSecurityManager::CheckPropertyAccessImpl does seem like an odd place to crash with a stack overflow though, and we're not going to start a thread with js_ValueToString. xul.dll nsScriptSecurityManager::CheckPropertyAccessImpl caps/src/nsScriptSecurityManager.cpp:812 xul.dll nsScriptSecurityManager::CheckObjectAccess caps/src/nsScriptSecurityManager.cpp:516 js3250.dll InitExnPrivate js/src/jsexn.cpp:287 js3250.dll js_ErrorToException js/src/jsexn.cpp:1249 js3250.dll js_ReportErrorNumberVA js/src/jscntxt.cpp:1215 js3250.dll JS_ReportErrorNumber js/src/jsapi.cpp:5716 js3250.dll js_TryMethod js/src/jsobj.cpp:4936 js3250.dll js_DefaultValue js/src/jsobj.cpp:4178 js3250.dll js_ValueToString js/src/jsstr.cpp:3041 The testsite seems to be unavailable so I couldn't try to repro the crash myself, but I can definitely confirm the annoyance of multiple dialogs spawned off commercial sites with these settings.

we really should just remove the feature. it's available as a basic feature in microb, and the only thing it does is let our testers rack up crashes faster than anything else. (so much so that my diablo translation calls the feature "Crash or nag me"). that said, there's a real bug in the stack. but I don't want to fix it here. I've filed bug 481784 for it. I believe the reason we crashed in CheckPropertyAccessImpl is because we were very low on stack space, so low that js_TryMethod wanted to report we were out of stack space in 4936, and well... sadly, we really did run out of stack space while thinking about reporting we were out of stack space. It's kind of like crashing allocating memory to report we ran out of memory allocating memory (and yes, we do that too, also from js, but in that case it's xpconnect which crashes, because it uses C++...).

This could be fixed by adding a "deny all cookies for this session" or "treat all cookies for this session as session cookies" button to the cookie dialog. But then it would have 5 buttons, making it need to die (bug 469260) even more.

comment #6: More frequently, you have a stack of ask dialogs, and you try to click one before all incoming cookies have displayed, hoping the all-cookies checkbox will stop the rest - but more pop up, and you eventually click BESIDE a button of a newly-visible dialog that just covered the one you tried to click. You are then facing a tower of Hanoi challenge - find the one to click next, 100 times - a user-UI-DoS - because the only dialog you can click is no longer visible. The all-cookies checkbox fails regularly - mentioned on several other bugs. It should close all dialogs from that site - but until the active modal dialog stays on top, you still could not use it! (But the choice between being tracked by every site you visit, or remembered by nobody, is still not acceptable) One bar listing all cookies, as https://wiki.mozilla.org/Cookies:prompting_ui suggests, is what we need - but in bug 469260 comment #14 please find my suggestion for a smaller bar - but we still need the choices suggested in comment #9. (For now, a listbox of choices on the dialog would be smaller - and could also offer similar choices per site. for more choices we need, see #11 of bug 420155 Large number of cookies come in and the active dialog does not always have the focus see also bug 420512 The Cookie LEARN option cannot be stopped at once and begs many times until website stops setting cookies bug 426114 – Multiple accept popups for the same cookie. bug 427184 replace pop-up cookie prompt dialog with use of information bar bug 434971 Multiple cookie "confirmations" requested for same site with "ask me every time" bug 430006 – Infinite dialog loop for cookie permission bug 515521 – All pending cookie popups for a given domain should be handled when one of them is in the cookie confirmation dialog bug 616843 A number of modal prompts should be made tab-modal bug 633763 Cookie confirmation dialogs should be tab-modal

removed ask me everytime option