Closed Bug 504098 Opened 16 years ago Closed 15 years ago

Crash [@ nsAccessibilityService::OnStateChange(nsIWebProgress*, nsIRequest*, unsigned int, unsigned int)

Categories

(Core :: Disability Access APIs, defect)

Product:
Core
Component:
Disability Access APIs
Version:
1.9.1 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED WORKSFORME

People

(Reporter: MarcoZ, Unassigned)

References

Details

(Keywords: access, crash, Whiteboard: [sg:dos null-deref])

That would be somewhat odd; see the NS_ASSERTION in that method (which I've never seen firing). Any idea how to reproduce?
(In reply to comment #1) > That would be somewhat odd; see the NS_ASSERTION in that method (which I've > never seen firing). I saw the assertion in that method as well. That's why I decided to CC you and ask for input. :) > Any idea how to reproduce? Unfortunately not. I got this out of analyzing crash-stats, and AFAICS, there were no comments on any of the crashes indicating how this can be reproduced.
Crash stack, taken from bp-3a7373e7-fe34-4a67-8576-f86022090714: Frame Module Signature Source 0 xul.dll nsAccessibilityService::OnStateChange(nsIWebProgress*,nsIRequest*,unsigned int,unsigned int) accessible/src/base/nsAccessibilityService.cpp:189 1 xul.dll nsDocLoader::FireOnStateChange(nsIWebProgress*,nsIRequest*,int,unsigned int) uriloader/base/nsDocLoader.cpp:1259 2 xul.dll xul.dll@0x8aca6b
Severity: major → critical
Keywords: crash
That's not much of a stack... ;) The modules list for that incident shows QQHook.dll which is a known trojan that "monitors user Internet activity and private information. It sends stolen data to a hacker site". My best guess is it's built against a different Gecko version than the one being run and is jumping into the wrong place in some vtable... That said, I looked at some of the other similar crashes and they don't have that particular malware dll name, though all have the broken stack. PNRComponent.dll also looks suspicious to me, though, and is present in a lot of the crashes... Ted, any reason you can think of for the stack to be sad like that?
(In reply to comment #4) > That said, I looked at some of the other similar crashes and they don't have > that particular malware dll name, though all have the broken stack. > PNRComponent.dll also looks suspicious to me, though, and is present in a lot > of the crashes... This page says it belongs to Softomate: http://www.processlibrary.com/directory/files/pnrcomponent/ And this site says Softomate is (at least sometimes) malware: http://www.pctools.com/mrc/infections/id/Adware.Softomate/
Group: core-security
Sorry, I don't know why the stack would be munged like that. :-(
I took a look at the recent crash stacks and they are all painfully small. Hard to know how to proceed here... should we bail on a null aRequest in nsDocLoader::FireOnStateChange for non-debug builds?
Can you point me to these stacks? The only one I see offhand shows this method being directly called from nsWindow::WindowProc, and the line number is just a ProcessMessage call on an nsWindow. That looks like a virtual function call on bogus memory, basically, hence jumping into lala-land... bailing on null aRequest likely won't get you far in terms of not crashing in that situation.
Oh, and in that stack the null thing is aWebProgress, not aRequest.
(In reply to comment #8) > Can you point me to these stacks? I'm not a crash stat query whiz, but somehow I ended up here: http://crash-stats.mozilla.com/report/list?query_search=signature&query_type=contains&query=OnStateChange&date=&range_value=2&range_unit=weeks&do_query=1&signature=nsAccessibilityService%3A%3AOnStateChange%28nsIWebProgress*%2C%20nsIRequest*%2C%20unsigned%20int%2C%20unsigned%20int%29 Common stack is: 0 xul.dll nsAccessibilityService::OnStateChange accessible/src/base/nsAccessibilityService.cpp:189 1 xul.dll nsDocLoader::FireOnStateChange uriloader/base/nsDocLoader.cpp:1259 2 xul.dll xul.dll@0x8b0d7b
At least the top three crashes there have PNRComponent.dll in them. dbaron, what does your script have to say about this crash?
Here is a nicer 3.6b3 stack: http://crash-stats.mozilla.com/report/index/c9e2b513-e081-4437-b3af-cc0922091123 It seems like the request is truly going bad, but how? No PNRComponent.dll but there is a RocketDock.dll, which some claim does key monitoring... I suspect RocketDock does this for legitimate reasons, but that would also make a RocketDock.dll good target camouflage for a trojan.
There aren't enough reports of this to get statistically significant correlation data in daily samples.
Are we gaining anything by keeping this bug security hidden?
Whiteboard: [sg:watch]
(In reply to comment #14) > Are we gaining anything by keeping this bug security hidden? Not that I can see.
no recent crashes on fx 4, close as worksforme
See comment #17.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.