Bug 469565 (CVE-2009-1828)

Keygen Tag endless loop and (not always reproducable) Memory corruption [@ NSSRWLock_LockRead_Util]

RESOLVED WONTFIX

Status

()

Core
Security: PSM
--
critical
RESOLVED WONTFIX
10 years ago
2 years ago

People

(Reporter: Thierry Zoller, Unassigned)

Tracking

(Blocks: 1 bug, {hang})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:dos] comment 0 hidden per comment 6, URL)

Attachments

(1 attachment)

(Reporter)

Comment 1

10 years ago
ADDENDUM :
POSTED WRONG WINDEBUG CRASH REPORT.. Please ignore WINDBG output
(Reporter)

Comment 2

10 years ago
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 <-
(Reporter)

Comment 3

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

Comment 4

10 years ago
Created attachment 352923 [details]
POC file

POC File
(Reporter)

Updated

10 years ago
Summary: Keygen Tag endleess loop and Memory corruption (non repro) → Keygen Tag endless loop and (not always reproducable) Memory corruption
Summary: Keygen Tag endless loop and (not always reproducable) Memory corruption → Keygen Tag endless loop and (not always reproducable) Memory corruption [@ NSSRWLock_LockRead_Util]
Yeah, no edit option. We'll figure it out, mshtml and jscript aren't likely to show up in a Firefox stack trace.
(Reporter)

Comment 6

10 years ago
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.
Blocks: 432687
Whiteboard: comment 0 hidden per comment 6
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.
Assignee: nobody → kaie
Status: UNCONFIRMED → NEW
Component: Security → Security: PSM
Ever confirmed: true
Product: Firefox → Core
QA Contact: firefox → psm
Whiteboard: comment 0 hidden per comment 6 → [sg:dos] comment 0 hidden per comment 6
Duplicate of this bug: 495626
Keywords: hang
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.

Updated

9 years ago
Alias: CVE-2009-1828

Comment 13

9 years ago
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).
(Reporter)

Comment 14

9 years ago
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.

Comment 15

9 years ago
> 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.

Comment 16

9 years ago
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).

Comment 17

9 years ago
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.

Comment 18

9 years ago
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 ;-).

Comment 19

9 years ago
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.

Comment 20

9 years ago
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.

Comment 21

9 years ago
(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.

Updated

9 years ago
Duplicate of this bug: 498919
That duplicate is public, fwiw, which might have the effect of opening this bug up. :(
This bug's already open...

Comment 25

9 years ago
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.

Comment 28

9 years ago
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.

Comment 29

9 years ago
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).

Updated

9 years ago
Duplicate of this bug: 546308

Comment 31

6 years ago
reassign bug owner.
mass-update-kaie-20120918
Assignee: kaie → nobody
keygen is eventually going away, and there are other ways to DoS the browser by using up lots of memory.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
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.
You need to log in before you can comment on or make changes to this bug.