ADDENDUM : POSTED WRONG WINDEBUG CRASH REPORT.. Please ignore WINDBG output

Here is the correct WINDBG analysis : 0:000> !analyze -v ******************************************************************************* * * * Exception Analysis * * * ******************************************************************************* FAULTING_IP: nssdbm3!dbopen+3e63 60331fc3 0fb601 movzx eax,byte ptr [ecx] EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff) ExceptionAddress: 60331fc3 (nssdbm3!dbopen+0x00003e63) ExceptionCode: c0000005 (Access violation) ExceptionFlags: 00000000 NumberParameters: 2 Parameter[0]: 00000000 Parameter[1]: 059bb000 Attempt to read from address 059bb000 FAULTING_THREAD: 00000ae0 DEFAULT_BUCKET_ID: STATUS_ACCESS_VIOLATION PROCESS_NAME: firefox.exe ERROR_CODE: (NTSTATUS) 0xc0000005 - Die Anweisung in "0x%08lx" verweist auf Speicher in "0x%08lx". Der Vorgang "%s" konnte nicht auf dem Speicher durchgef hrt werden. READ_ADDRESS: 059bb000 NTGLOBALFLAG: 0 APPLICATION_VERIFIER_FLAGS: 0 PRIMARY_PROBLEM_CLASS: STATUS_ACCESS_VIOLATION BUGCHECK_STR: APPLICATION_FAULT_STATUS_ACCESS_VIOLATION LAST_CONTROL_TRANSFER: from 6032ec68 to 60331fc3 STACK_TEXT: WARNING: Stack unwind information not available. Following frames may be wrong. 0012bd68 6032ec68 059aeff2 fffff412 0038e6e0 nssdbm3!dbopen+0x3e63 0012bd80 7c921463 7c98b120 fffff412 0161d4a8 nssdbm3!dbopen+0xb08 0012bdbc 60321f89 0177c910 0012be1c 0012bdf0 ntdll!RtlpFreeDebugInfo+0x77 0012bddc 60322053 0012be1c 0012bdf0 00000000 nssdbm3+0x1f89 0012bdf8 603228fa 0012be1c 0012be98 0012beb8 nssdbm3+0x2053 0012be24 60326081 0177c8e0 0012be50 017ff6a0 nssdbm3+0x28fa 0012be7c 60322144 0012be98 0012be90 0012beb8 nssdbm3+0x6081 0012bea0 60326251 0177c8e0 60325f0b 0012beb8 nssdbm3+0x2144 0012bee0 60326a40 00000040 0bc08280 00000000 nssdbm3+0x6251 0012bf88 60326ae1 017ff6a0 0bc08280 0bb6dc80 nssdbm3+0x6a40 0012bfa8 60304565 017ff6a0 0bb6dc80 00000002 nssdbm3+0x6ae1 0012bfcc 602f79f7 01789640 0012c094 00000002 softokn3!NSC_ModuleDBFunc+0xdb10 0012bff8 602f7c4e 01789640 0012c094 00000002 softokn3!NSC_ModuleDBFunc+0xfa2 0012c018 602f7cee 01a4d800 0bc081a0 0012c094 softokn3!NSC_ModuleDBFunc+0x11f9 0012c048 603588e0 01000001 0012c094 00000002 softokn3!NSC_ModuleDBFunc+0x1299 0012c070 6035ce07 02e95000 0012c094 00000002 nss3!PK11_ReadRawAttribute+0x100 0012c0e8 6035c1cc 02e95000 00000000 041ff6d8 nss3!PK11_ListFixedKeysInSlot+0x72 0012c160 60952aae 0012c180 0012c18c 041ff6d8 nss3!PK11SDR_Decrypt+0x105 0012c1a8 608c36da 05f063d0 03c43440 00000034 xul!gfxWindowsFontGroup::InitTextRunGDI+0x2ead 0012c1dc 606568a3 05f063d0 00000034 0012c2b0 xul!NS_StringCloneData_P+0x6061 0012c1f8 604ea0cb 05f063d0 00000006 00000002 xul!NS_InvokeByIndex_P+0x27 0012c3d4 604e6c6e 00000000 00d620b0 04aef860 xul!NS_Realloc_P+0x2069b 0012c49c 6013277b 00d620b0 04a06740 00000001 xul!NS_Realloc_P+0x1d23e 0012c568 601214e4 00d620b0 00000001 0035c1ec js3250!js_Invoke+0x2bb 0012c6fc 6013283e 00d620b0 00deaca8 00d620b0 js3250!JS_DefineFunctions+0xbfb4 0012c7b8 604e5f23 00d620b0 00000004 0035bf88 js3250!js_Invoke+0x37e 0012c9dc 604d7798 04b894c0 078197c0 0000000d xul!NS_Realloc_P+0x1c4f3 0012caa8 606569f5 050be110 0000000d 0012cad0 xul!NS_Realloc_P+0xdd68 0012cac4 606568a3 050be110 0012cba0 0012cd70 xul!NS_InvokeByIndex_P+0x179 0012caf8 604ea0cb 050be110 0000000d 00000005 xul!NS_InvokeByIndex_P+0x27 0012ccd4 604e6c6e 00000000 00d620b0 017dca80 xul!NS_Realloc_P+0x2069b 0012cd9c 6013277b 00d620b0 056f1420 00000004 xul!NS_Realloc_P+0x1d23e 0012ce68 601214e4 00d620b0 00000004 0035bf68 js3250!js_Invoke+0x2bb 0012cffc 6013283e 00d620b0 013194e8 00d620b0 js3250!JS_DefineFunctions+0xbfb4 0012d0b8 604e5f23 00d620b0 00000004 0035bf50 js3250!js_Invoke+0x37e 0012d2dc 604d7798 03fbc5e0 03fbb7c0 0000000b xul!NS_Realloc_P+0x1c4f3 0012d3a8 606569f5 03f9ec50 0000000b 0012d3d0 xul!NS_Realloc_P+0xdd68 0012d3c4 606568a3 03f9ec50 0012d4a0 0012d670 xul!NS_InvokeByIndex_P+0x179 0012d3f8 604ea0cb 03f9ec50 0000000b 00000005 xul!NS_InvokeByIndex_P+0x27 0012d5d4 604e6c6e 00000000 00d620b0 014568c0 xul!NS_Realloc_P+0x2069b 0012d69c 6013277b 00d620b0 00d7b080 00000004 xul!NS_Realloc_P+0x1d23e 0012d768 601214e4 00d620b0 00000004 0035bf30 js3250!js_Invoke+0x2bb 0012d8f4 6013283e 00d620b0 00d620b0 0035bef0 js3250!JS_DefineFunctions+0xbfb4 0012d9b0 60133367 00d620b0 00000000 0035bef0 js3250!js_Invoke+0x37e 0012d9e4 60133f0f 00d620b0 0149ab20 014bb2a0 js3250!js_LookupProperty+0x257 0012da2c 60122797 0149ab20 0149ab00 0012da7c js3250!js_LookupProperty+0xdff 0012da5c 604ec080 03f58f50 03f58f40 0033adc0 js3250!JS_DefineFunctions+0xd267 00000000 00000000 00000000 00000000 00000000 xul!NS_CycleCollectorSuspect_P+0xa50 FOLLOWUP_IP: nssdbm3!dbopen+3e63 60331fc3 0fb601 movzx eax,byte ptr [ecx] SYMBOL_STACK_INDEX: 0 SYMBOL_NAME: nssdbm3!dbopen+3e63 FOLLOWUP_NAME: MachineOwner MODULE_NAME: nssdbm3 IMAGE_NAME: nssdbm3.dll DEBUG_FLR_IMAGE_TIMESTAMP: 49094cc6 STACK_COMMAND: ~0s ; kb FAILURE_BUCKET_ID: STATUS_ACCESS_VIOLATION_c0000005_nssdbm3.dll!dbopen BUCKET_ID: APPLICATION_FAULT_STATUS_ACCESS_VIOLATION_nssdbm3!dbopen+3e63 Followup: MachineOwner --------- 0:000> g Sat Dec 13 18:41:23.250 2008 (GMT+1): (d00.ae0): Access violation - code c0000005 (!!! second chance !!!) eax=8b73eaba ebx=00000000 ecx=059bb000 edx=f9f141fa esi=1fffe681 edi=0177c910 eip=60331fc3 esp=0012bd68 ebp=0038e6e0 iopl=0 nv up ei ng nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000286 nssdbm3!dbopen+0x3e63: 60331fc3 0fb601 movzx eax,byte ptr [ecx] ds:0023:059bb000=?? --- Second chance exception <-

Addendum : How may I delete the previous (erronous) windbg output ? I have no edit option ?

POC File

Yeah, no edit option. We'll figure it out, mshtml and jscript aren't likely to show up in a Firefox stack trace.

The content that is displayed above gives information away that is not patched in that piece of software. Hence, if you could please remove it would be great. Could somebody confirm this issue ?

I couldn't on a mac and was waiting until I could get my hands on a (non-VM) windows box. NSSRWLock_LockRead_Util is one of our current most common crash locations. Here's the relevant content from the initial description (since I'm hiding it per comment 6): > Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.4) > Gecko/2008102920 Firefox/3.0.4 > > This is a stupid problem, I felt it not being worth reporting however since > this somtimes triggered multiple memory corruption issues I decided to report > it. > > I played around witht the keygen tag and found that it reloads the document by > submiting the public key as an argument to the current URI. > > Combining this with a Javascript Body onload() (or meta refresh) results in an > neat endless loop blocking access to the UI. > > The memory corruption occured twice, after simulating a user that tries to > click on FF UI an Keygen dialog. > > http://crash-stats.mozilla.com/report/index/e029f179-d74c-4672-8b28-2c3f02081213 > http://crash-stats.mozilla.com/report/index/19d14c2b-e3d1-4447-bc04-4b7f32081213 > > Reproducible: Always > > Steps to Reproduce: > 1. Open Html file > 2. > 3. > Actual Results: > UI is non accessible to do blockin UI window : Non reproducably memory > corruption > > Expected Results: > Keygen should be generated once, or access to UI should be given.

I can definitely confirm the denial of service aspect, and there's a very minor memory leak (after 9 hours of CPU time memory use went from 60MB to 360MB). Haven't been able to reproduce a crash.

Advisory published: http://www.milw0rm.com/exploits/8822

In case there are more than one security modules used, FF forces to make a selection between two or more security modules every time. It's possible to save an open work, close the browser and the selection box thereafter. An easy work-around and temporary fix could to force selection even with one security module.

Advisory released : http://www.securityfocus.com/bid/35132/info CVE attributed : CVE-2009-1828 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-1828

Hello! As I wrote at my site (http://websecurity.com.ua/3194/), not just only Firefox, but also Internet Explorer, Google Chrome and Opera are vulnerable. After DoS vulnerability in Mozilla Firefox found by Thierry Zoller was posted, I checked it in other browsers and found that this Denial of Service vulnerability also exists in Internet Explorer and Google Chrome. And also I made new version of exploit which works in Opera. Attack belongs to type of DoS (http://websecurity.com.ua/2550/) via resources consumption (in all mentioned browsers), and also freezing or blocking (differently in different browsers). DoS: http://websecurity.com.ua/uploads/2009/Firefox,%20IE%20&%20Chrome%20DoS%20Exploit.html http://websecurity.com.ua/uploads/2009/Firefox,%20IE,%20Chrome%20&%20Opera%20DoS%20Exploit.html Firefox blocks (at that consumes CPU resources), so it's become impossible to use it and it's only possible to close it. IE consumes CPU resources and freezes. Chrome only consumes CPU resources. Opera blocks, at that consumes CPU resources (in second exploit).

Hi Mustlive, First thank you for giving credit. Secondly I have to make a few comments, bugzilla isn't really the place to discuss third party vendor bugs, but let me comment : - IE doesn't support the keygen tag at all (afaik), what you are doing is continuously submitting a form. In IE8 this leads to no blocking or anything to be considered a DoS. - In chrome I could not reproduce, I don't think they support the keygen tag (so see above) - Haven't tested Opera, maybe it's another DoS. Feel free to post it to Bugtraq or Fulldisclosure.

> Firefox blocks (at that consumes CPU resources), so it's become impossible to > use it and it's only possible to close it. I find you can close the keygen generation and close the problematic tab before it opens again. So it's not /that/ bad.

Hello Thierry! You are welcome. > bugzilla isn't really the place to discuss third party vendor bugs Before I wrote to bugzilla, I sent you a letter (to Thierry(at)Zoller.lu) with details about these vulnerabilities (my previous post was small version of that letter). So you could just answer on my letter :-). I understand that bugzilla is not appropriate place for such discussion, but here is why I did that post. First, in case if you didn't receive my letter, than you can view small version of it here. Second, to show Mozilla and other browsers developers that this is not just problem of one browser, but of many browser. Which must stimulate them to fix this hole in their browsers (multiple vulnerable browsers case must make some influence on all browser developer). Besides, I am glad that Mozilla (in the person of Daniel Veditz) very quickly answered on your bugzilla post (only after 3 days). For example on my last bugzilla post about <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=493858">Properties not-inheritance vulnerability in Mozilla Firefox</a>, which I made at 19.05.2009, there is no answer to present day. This situation brightly shows how Mozilla "fixing vulnerabilities in 10 days" (via just ignoring them).

Thierry, at my site and in my letter which I wrote to you, I wrote which versions of browsers are vulnerable. Vulnerable are Mozilla Firefox 3.0.10, Internet Explorer 6 (6.0.2900.2180), Internet Explorer 7 (7.0.6000.16711), Google Chrome 1.0.154.48, Opera 9.52 and previous versions of these browsers (and possible next versions). > IE doesn't support the keygen tag at all (afaik) Before your post I even didn't know about keygen tag at all (and so didn't know that any browser support it). As I checked IE6 vulnerable to this attack (regardless to support of this tag), and after my post about this vulnerability I found (at the end of last week), that IE7 is also vulnerable. > what you are doing is continuously submitting a form. It's in second exploit. It's to make blocking DoS in Opera. See my Classification of DoS vulnerabilities in browsers (http://websecurity.com.ua/2550/). I made a lot of such blocking DoS exploits for different browsers (Firefox, IE, Opera and Chrome) in last and this year. None browser vendor fixed any of these blocking DoS (like any other DoS hole which I found) in their browsers. > In IE8 this leads to no blocking or anything to be considered a DoS. Than IE8 is not vulnerable. Unlike IE6 and IE7. > In chrome I could not reproduce, I don't think they support the keygen tag (so see above) As I mentioned above, vulnerable Google Chrome 1.0.154.48 (and previous versions). And Chrome consumes CPU resources (regardless to support of this tag), so look at % of used CPU in Chrome or in Task Manager. > Haven't tested Opera, maybe it's another DoS. Feel free to post it to Bugtraq or Fulldisclosure. Opera is vulnerable to, as I wrote. I mostly not post to Bugtraq (there are very small number of my post to this list) and never posted to Fulldisclosure. Didn't post to Bugtraq about these vulnerabilities in Firefox, IE, Chrome and Opera, nor about my last post about vulnerabilities in Firefox, Internet Explorer and Opera (http://websecurity.com.ua/3216/), not about many other holes in browser which I found in 2007, 2008 and 2009. Except those posts about Saved XSS vulnerability in IE6 and IE7. But I'll think about it.

Nim! > I find you can close the keygen generation and close the problematic tab before it opens again. So it's not /that/ bad. When I was checking Thierry's exploit before posting about vulnerabilities in different browsers on last week, I also found possibility to close (quickly) keygen generation window, and so to eliminate this exploit (without closing of tab or browser). For this reason I made new version of exploit (look at my second exploit). Which is harder one (for all browsers) and also works in Opera. So try to use my second exploit mentioned above ;-).

I wasn't trying to substract importance to it, it's still a bug. And the fact that you can escape it, probably not intentional. A solution to it would simply be adding a Cancel button to the keygen window (not complete since you could produce a loop but a big step). (In reply to comment #18) > For this reason I made new version of exploit (look at my second exploit). > Which is harder one (for all browsers) and also works in Opera. So try to use > my second exploit mentioned above ;-). I wanted to close my browser anyway, so gave it a try :) So I tried both http://websecurity.com.ua/uploads/2009/Firefox,%20IE%20&%20Chrome%20DoS%20Exploit.html http://websecurity.com.ua/uploads/2009/Firefox,%20IE,%20Chrome%20&%20Opera%20DoS%20Exploit.html and they aren't difficuly to close. Thierry's POC at this bug url is harder. Just do Alt+F4 (keygen window closes) and close the tab. I also tried your http://websecurity.com.ua/uploads/2009/Firefox,%20IE%20&%20Opera%20DoS%20Exploit.html but I don't seem to be vulnerable. :) Firefox simply shows a parsing error (not element found), line 228891.

Hello Nim! > Just do Alt+F4 (keygen window closes) and close the tab. I do it with mouse only ;-). In any case (with keyboard or with mouse) you need to close keygen window and tab very quickly, because keygen generation process will begin again. And taking into account that 99,99% of Internet users have no such knowledge, then their browsers will be DoSed with this attack. > Thierry's POC at this bug url is harder. Nim, my first exploit it's the same Thierry's exploit (with my additional html codes, like title and comment). So it's your subjective opinion :-). Besides, my second exploit works in Opera. > I also tried your http://websecurity.com.ua/uploads/2009/Firefox,%20IE%20&%20Opera%20DoS%20Exploit.html > but I don't seem to be vulnerable. :) Man, Firefox is vulnerable (all versions). After that hole was found, Mozilla ignored it and didn't fix it in 3.0.9 and 3.0.10. If you get such result (just error message), then it's because not full xml file was loaded (and it's 228 KB). So just reload page (make full reload). Or download both html and xml file to your PC and run locally (you can download them from my site or download rar with these files from milw0rm). I had feelings that such situation (with error message) is possible. For this reason for attack is better to use fast server. P.S. As I recently checked in Firefox 3.0.11, these last two DoS vulnerabilities in it (which I mentioned above) were not fixed in version 3.0.11.

(In reply to comment #20) >> Thierry's POC at this bug url is harder. > > Nim, my first exploit it's the same Thierry's exploit (with my additional html > codes, like title and comment). So it's your subjective opinion :-). It's just a matter of the time between one run and the second. Obviously, the computer used matters here. > Besides, my second exploit works in Opera. That's a point for you. > > I also tried your > http://websecurity.com.ua/uploads/2009/Firefox,%20IE%20&%20Opera%20DoS%20Exploit.html > > but I don't seem to be vulnerable. :) > > Man, Firefox is vulnerable (all versions). (skip) > P.S. As I recently checked in Firefox 3.0.11, these last two DoS vulnerabilities in > it (which I mentioned above) were not fixed in version 3.0.11. I confirm the crashing bug in Firefox 3.0.11 However, in trunk it gives the 'Parsing error' I described above. Some parser change may be enmascarading it. I got it to crash once, but couldn't reproduce.

That duplicate is public, fwiw, which might have the effect of opening this bug up. :(

This bug's already open...

for reference, the crash listed is here: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/dbm/src/h_func.c&rev=3.2&mark=195,173,172#165 the caller is this: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/dbm/src/hash.c&rev=3.23&mark=784#762 So the signature is: [@ hash4 - hash_access] past that point, isn't particularly easy for me to rebuild (.dmp files are appreciated...). Assuming that the listed frame is noise, the next call site is here: 2100 keydb_Get(NSSLOWKEYDBHandle *kdb, DBT *key, DBT *data, unsigned int flags) 2110 ret = (* db->get)(db, key, data, flags); But without a .dmp file, it isn't worth it for me to spend time speculating. reporter: in the future, please consider looking at https://developer.mozilla.org/en/How_to_get_a_stacktrace_with_WinDbg the instructions would also enable you to get better crash reports for IE (comment 0). But they'd especially improve your ability to report issues to us.

(In reply to comment #25) > (...) > (comment 0). But they'd especially improve your ability to report issues to us. How about unhiding comment 0 here? Comment 6 (mentioned in Whiteboard field) was written half a year ago... I guess comment 0 includes the same information as is in URL field of this bug and/or bug 498919 comment 0, right?

No, it contains additional information that the reporter asked to remain hidden.

When FF3.5 is open, cpu eventually runs 99%, using over 100,000K of memory. Closing FF does not stop the cpu or memory usage. Closing with Task Manager is the only way to exit FF. Previous versions of FF all ran stable, problem started with 3.5. Closing and restarting does not solve the problem. Removing program and reinstalling clean does not solve anything. Same settings were used from previous version to install FF3.5. Once cpu maxes out, FF ties up entire computer.

I found the same bug today: (sorry didn't show up on search) https://bugzilla.mozilla.org/show_bug.cgi?id=546308 Although my approach was somewhat more extreme in the sense of the Key3.db gets clogged up. That alone is in my honest opinion a reason to have a good look at the issue, since I find it undesirable for having a JavaScript writing to Key3.db without limitation whatsoever (at least it seems that way).

reassign bug owner. mass-update-kaie-20120918

keygen is eventually going away, and there are other ways to DoS the browser by using up lots of memory.

Can we unhide comment 0 since this is now WONTFIXED?

comment 0 has a stack trace that is from something other than Firefox. At the reporter's request, we're leaving it hidden.