533108 - Creative Labs ctagent.dll causes a crash on closing browser window

Status: RESOLVED INCOMPLETE

(Toolkit :: Blocklist Policy Requests, defect)

Description

[IU]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20091205 Minefield/3.7a1pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20091205 Minefield/3.7a1pre

On closing a window with the linked URL, Firefox crashes.  No crash report is generated.  The URL was from a pop-up and it appears the crash is related to flash.  Google Chrome also indicated improper shutdown.

The crash does not occur if there is more than one tab and only the tab with the linked page loaded is the one that is closed.

I therefore wonder if this is some remnant from bug 520639, given bug 520639 comment 19, for which I did not see any follow-up comment indicating completion.  I don't have time to do any regression testing now, but can look into it later.

Also crashes with the attached test case, which is simply the zipped page.

I am attaching a Windbg log to this bug; however, I'm not sure if it was properly generated, because of Windbg complaining that the symbols are not correct.


Reproducible: Always

Steps to Reproduce:
1. Launch Firefox with a new profile and open a new window.  You should have two windows open (the purpose of this is mostly visual).
2. Load either the URL or attached web page in that single tab in the new window (i.e. there should be only one tab in the new window and the subject page should be the only one loaded).
3. Close the new window having the subject page.
4. Firefox crashes.  No crash report generated.

Comment 1

[IU]

Attachment: web page responsible for the crash

Comment 2

[IU]

Attachment: Windbg log of crash

Comment 3

[timeless]

ModLoad: 74e30000 74e9d000   C:\WINDOWS\system32\RichEd20.dll

RichEd20 is really an unloaded.... i don't know why it was loaded, but it's basically their fault. offhand, i blame pgp. try disabling/uninstalling it. if the problem goes away, let us known and file a bug against them.

Comment 4

[IU]

Definitely NOT PGP.  I just completely uninstalled PGP and rebooted and I still get the crash.  How did you come to the conclusion that it was PGP?

Comment 5

[timeless]

> STACK_TEXT:  
> WARNING: Frame IP not in any known module. Following frames may be wrong.
> 0012f164 20534e45 41524150 4b524f20 202c5455 <Unloaded_Ed20.dll>+0x4152414f
> 0012f254 6014967f 00000000 0307a980 60305f95 <Unloaded_Ed20.dll>+0x20534e44
> 0012f260 60305f95 03124740 01b1b600 0012f298 MOZCRT19!free+0x1f [e:\builds\moz2_slave\mozilla-central-win32-nightly\build\obj-firefox\memory\jemalloc\crtsrc\jemalloc.c @ 6017]
> 0012f298 609d9df5 0468beb4 0012f328 0012f310 nspr4!PR_DestroyLock+0x15 [e:\builds\moz2_slave\mozilla-central-win32-nightly\build\nsprpub\pr\src\threads\combined\prulock.c @ 214]
> 0012f2bc 00a213ca 0001043f 00000008 0307a980 > xul!nsWebShellWindow::HandleEvent+0x23ed41
> 0012f580 7e428eec 00822b40 00000010 00000000 PGPhk!CBTProc+0x30a
>                                              ^^^^^

can you provide a new log?

Comment 6

[IU]

In reply to comment #5)
> can you provide a new log?

I've reinstalled PGP.  Is that going to be a problem?  I'm also going to check to see if this is a regression.

Comment 7

[timeless]

it doesn't bother me, but if it turns up in STACK_TEXT again, then you'll have to leave it off until you provide a new log.

Comment 8

[IU]

Attachment: Windbg log of crash #2 (PGP uninstalled)

Here's a new log, generated with PGP uninstalled.

Comment 9

[IU]

By the way, I also verified it is not a regression.  Furthermore, this crash is reproducible in safe mode.

Comment 10

[timeless]

So, this will be painful (i'm writing these instructions from a mac, and don't really have the time to play with them).

when you first run firefox, you get:
> ModLoad: 605c0000 605c7000   C:\Program Files\Internet\firefox\xpcom.dll
> (938.91c): Break instruction exception - code 80000003 (first chance)
> eax=00191eb4 ebx=7ffdb000 ecx=00000005 edx=00000020 esi=00191f48 edi=00191eb4
> eip=7c90120e esp=0012fb20 ebp=0012fc94 iopl=0         nv up ei pl nz na po nc
> cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
> ntdll!DbgBreakPoint:
> 7c90120e cc              int     3
> 1:002> 
         ^
we're going to do something different here.

> .call MOZCRT19!malloc(2048); g

that should give you a number/address thing that's "returned", we'll use it later where i have "__this_came_from_malloc__"

(for people watching from the peanut gallery: yes, i'm going to leak this memory, it's 2k, and i need it more than firefox does.)

> bp kernel32!FreeLibrary "kp; .call kernel32!GetModuleFileName(@ebp, __this_came_from_malloc__, 2047); g; ds __this_came_from_malloc__; g"

this is my crude attempt at figuring out who is unloading what, where, why.

note that it unfortunately isn't tested (i'm writing this from memory, sorry). if you have problems getting this stuff to work, you can visit irc.mozilla.org and ask for help, someone can either help expand this or point you to me.

fwiw, '.hh topic' in that command prompt will ask windbg to explain a topic, so if you're curious, you can always do that.

roughly, in order:

.call = set up a stack frame to call a function with the given arguments
@ebp = a register, pointing to the stack frame -- if i'm right, it will have the first and only parameter to FreeLibrary -- if i'm wrong, this is where i messed up
g = go (let the program continue operating until something interrupts it)
kp = dump a stack trace (with parameters)
ds = display (string)
bp = break (at address; do command sequence)

anyway, if this works, your next log will have some useful paths mixed in, especially you should see 'C:\WINDOWS\system32\RichEd20.dll' somewhere.

oh, and yeah, running firefox in safe mode is probably worth it, as it will reduce the number of strange things for me to worry about. when you open executable, you can provide commandline arguments, use "-safe-mode".

Comment 11

[IU]

Thanks for the detailed instructions.  I haven't yet to run it, but I have identified the responsible module.  I will still attempt to run through your steps and generate the log; however, I'm now wondering if this needs to be changed to a security bug, before I attach what you are requesting.  Please let me know if there is risk of leaking sensitive information.

As for the crash, the responsible module is: C:\WINDOWS\system32\ctagent.dll v.1.0.0.5.  It's a Creative Technology file -- installed as part of the driver pack for my SoundBlaster Live! audio card.  I used to use the Microsoft drivers, but they weren't fully compatible, so I installed the OEM drivers on November 8.  The card is no longer supported by Creative (I believe last driver release was in early 2003); so, hopefully there is something that can be done with Firefox.

To isolate, what I did was pick likely suspects from the list of modules at the beginning of the "Exception Analysis" section of the log.  I then used Process Hacker to list the modules associated with firefox.exe and unloaded ctagent.dll.  With that module no longer present Firefox no longer crashes with the STR.

I wonder why it crashes on that page but not on any others.

Comment 12

[IU]

Attachment: Windbg log of crash #3 (PGP uninstalled); run in safe mode

With safe mode, I didn't get any breakpoints, so wasn't able to perform your steps.

Comment 13

[timeless]

there shouldn't be anything sensitive, as for security, well.... third party libraries which are evil and do stupid things are a risk, but they're relatively hard to exploit as long as they don't enable random web content to get into the affected places. I think it's relatively unlikely, but not impossible. The only thing my commands should reveal is paths, and afaik those paths are already exposed in the logs you've provided.

we could blocklist the library you listed (and probably should). it'd kinda help if you could figure out why it wants to be in our process in the first place. i.e. is there any harm in us never allowing it to load? if there's no harm in always blocking it, that simplifies matters from our perspective.

either way, it'd be nice to actually get a smoking gun so that you could take it to creative labs and complain to them. -- I believe that if my instructions do what i want, then they'll provide the evidence we need.

Comment 14

[IU]

(In reply to comment #13)
> there shouldn't be anything sensitive, as for security, well.... third party
> libraries which are evil and do stupid things are a risk, but they're
> relatively hard to exploit as long as they don't enable random web content to
> get into the affected places. I think it's relatively unlikely, but not
> impossible. The only thing my commands should reveal is paths, and afaik those
> paths are already exposed in the logs you've provided.

I believe the breakpoint you suspected was actually related to the Java plug-in.  I disabled Java and I got no more breakpoints, as seen in the third log I attached; thus, I am unable to run through the additional steps you provided.
 
> we could blocklist the library you listed (and probably should). it'd kinda
> help if you could figure out why it wants to be in our process in the first
> place. i.e. is there any harm in us never allowing it to load? if there's no
> harm in always blocking it, that simplifies matters from our perspective.

I believe it should absolutely be blocklisted.

From what information I have been able to find online, I can't imagine why ctagent.dll *needs* to hook into any browser.  One forum poster complained about that file persistently wanting access to the Internet: http://www.driverheaven.net/general-discussion/151-alternative-creative-drivers-kx-project-site.html#post4898

And as far as the purpose of the file goes, here's what little Creative provides about the reason for its existence: http://ask.europe.creative.com/SRVS/CGI-BIN/WEBCGI.EXE?New,Kb=ww_english_add,Company={D0F19C16-3B20-4E69-BC69-7F708173173D},VARSET=ws:http://dev-enduserRevamp.cle.creaf.com,VARSET=ws:http://fr.creative.com,case=3805

> either way, it'd be nice to actually get a smoking gun so that you could take
> it to creative labs and complain to them. -- I believe that if my instructions
> do what i want, then they'll provide the evidence we need.

Unless there's a different way to implement your instructions, of course... but I hate dealing with large manufacturers.  Unless you have a business relationship, they can't even be bothered to even begin to care less.  So, based on available information, I believe blocklisting is the most fruitful option.  In the context of web browsing, the file is not needed.  Seems it's merely piggybacking off web browsers to do whatever it wants.

Comment 15

[IU]

Attachment: Creative's description of purpose of ctagent.dll

Comment 16

[IU]

Any way to get action on this?

Comment 17

[Wayne Mery (:wsmwk)]

UI, do you still see this crash?

Comment 18

[IU]

I'll close since I no longer have any Creative Labs device.