665775 - Blocklist Extensions and dlls to prevent datamngr.dll crashes

Status: RESOLVED WONTFIX

(Toolkit :: Blocklist Policy Requests, defect)

Description

[Marcia Knous [:marcia]]

Spunoff from Bug 622140 Comment 16. This crash has high enough volume that we would like to go forward with a blocklist. In the last week there are 11,284 crashes across all Firefox versions of each signature in Bug 622140.

Module:
datamngr.dll (Imesh)  version: 1.0.0.1 (risk to blocklist other valid dlls, see Bug 622140 comment 3 and comment 8)

Extensions (hijacker/adware categories):
* {1FD91A9C-410C-4090-BBCC-55D3450EF433} all versions (jZip.Toolbar, see http://forums.spybot.info/showthread.php?t=62634)
* {c2d64ff7-0ab8-4263-89c9-ea3b0f8f050c} all versions (MediaBar, see http://www.spywareremove.com/removeBearShareMediabar.html)
* {28387537-e3f9-4ed7-860c-11e69af4a8a0} all versions (MediaBar)
* {99079a25-328f-4bd4-be04-00955acaa0a7} all versions (Searchqu toolbar, other name of MediaBar)

Comment 1

[Asa Dotzler [:asa]]

Can we get some movement here please?

Comment 2

[Justin Scott [:fligtar]]

Please provide more details -- I need Firefox versions and add-on versions to be blocked.

Kev, do you have any contacts at the above?

Comment 3

[Scoobidiver (away)]

(In reply to comment #2)
> I need Firefox versions and add-on versions to be blocked.
Add-on versions were given in comment 0.
Firefox versions: all versions

Comment 4

[Kev Needham [:kev]]

Discordia Ltd. is the parent org of all of these toolbars (they also are the parent of Bandoo and lphant), and only makes a contact address available via postal mail. We have no formal contacts, but I'll send a note to their privacy addresses.

Is this not just a candidate for Firefox 4+? Glancing at the bugs I didn't see a lot of mention of 3.x.

I'd go ahead and BL when ready, but not sure it's appropriate to block in older versions of Firefox.

Comment 5

[Scoobidiver (away)]

(In reply to comment #4)
> Is this not just a candidate for Firefox 4+? Glancing at the bugs I didn't
> see a lot of mention of 3.x.
Right for Firefox 4+ if the purpose of the add-on blocklisting is only to add stability.

Comment 6

[Marcia Knous [:marcia]]

This shows up in the top 20 non plugin reports for 5.0: https://crash-analysis.mozilla.com/chofmann/20110627/top-5.0.html. I am trying to work to get a better list of Firefox versions, but a cursory glance showed that 3.6, 4.0.x and 5.0 were affected.

Comment 7

[Robert Kaiser]

https://crash-stats.mozilla.com/topcrasher/byversion/Firefox/5.0/7 says that [@ @0x0 | datamngr.dll@0xd2d1 ] happens in the following Firefox versions:
7.0a1, 6.0a1, 6.0a2, 5.0a2, 5.0, 4.0a1pre, 4.0, 4.2a1pre, 4.0b9pre, 4.0b9, 4.0b8pre, 4.0b8, 4.0b7pre, 4.0b7, 4.0b6, 4.0b5pre, 4.0b5, 4.0b4, 4.0b3, 4.0b2pre, 4.0b2, 4.0b13pre, 4.0b12pre, 4.0b12, 4.0b11pre, 4.0b11, 4.0b10pre, 4.0b10, 4.0b1, 4.0.1, 3.6.18, 3.7a5pre, 3.7a5, 3.7a4webm, 3.7a3, 3.7a2, 3.7a1pre, 3.7a1, 3.6b5, 3.0, 3.6b4, 3.6b3, 3.6b2, 3.6b1, 3.6.9, 3.6.8, 3.6.7, 3.6.6, 3.6.4, 3.6.3plugin1, 3.6.3, 3.6.2, 3.6.17, 3.6.16, 3.6.15pre, 3.6.15, 3.6.14, 3.6.13, 3.6.12, 3.6.11, 3.6.10, 3.6, 3.5b99, 3.5b4, 3.5.9, 3.5.8, 3.5.7, 3.5.6, 3.5.5, 3.5.4, 3.5.3, 3.5.2, 3.5.19, 3.5.18, 3.5.17, 3.5.16, 3.5.15, 3.5.13, 3.5.11, 3.5.10, 3.5.1, 3.5, 3.1b3, 3.1b2, 3.1b1, 3.0b5, 3.0b4, 3.0b2, 3.0b1, 3.0a8, 3.0.9, 3.0.8, 3.0.7, 3.0.6, 3.0.5, 3.0.4, 3.0.3, 3.0.19, 3.0.17, 3.0.16, 3.0.15, 3.0.14, 3.0.11, 3.0.10, 3.0.1

Judging from that, I think all Firefox versions should be in the blocking.

Comment 8

[Justin Scott [:fligtar]]

(In reply to comment #3)
> (In reply to comment #2)
> > I need Firefox versions and add-on versions to be blocked.
> Add-on versions were given in comment 0.
> Firefox versions: all versions

This was filed as a crash block, so all extension versions in all versions of Firefox is too extreme. Given our problems not being able to unblock things in the past, I'm not willing to use that range for a crash block.

Comment 9

[Asa Dotzler [:asa]]

Justin, can you explain this further. Why is this too extreme?

Comment 10

[Scoobidiver (away)]

(In reply to comment #6)
> This shows up in the top 20 non plugin reports for 5.0:
> https://crash-analysis.mozilla.com/chofmann/20110627/top-5.0.html. I am
> trying to work to get a better list of Firefox versions, but a cursory
> glance showed that 3.6, 4.0.x and 5.0 were affected.
With combined signatures, it is:
* #4 top browser crasher in 5.0 (4696 crashes/week)
* #5 top browser crasher in 4.0.1 (4657 crashes/week)
* #18 top browser crasher in 3.6.18 (972 crashes/week)
So if the add-on blocklisting is restricted to the top-10 crashers, it's Firefox 4 and above, to the top-20 crashers, it's all Firefox versions.

(In reply to comment #8)
> This was filed as a crash block, so all extension versions in all versions
> of Firefox is too extreme. Given our problems not being able to unblock
> things in the past, I'm not willing to use that range for a crash block.
These extensions are known as hijacker and will stay as that for future versions. It's probably the hijacking process that makes Firefox crash.
But, anyway, here are the current versions:
* {c2d64ff7-0ab8-4263-89c9-ea3b0f8f050c} (MediaBar): 4.3.0.00
* {28387537-e3f9-4ed7-860c-11e69af4a8a0} (MediaBar): 4.3.0.00
* {99079a25-328f-4bd4-be04-00955acaa0a7} (Searchqu toolbar): 4.3.0.00
In recent crash stats, I see no longer correlations with jZip.Toolbar, so don't blocklist it.

Comment 11

[Justin Scott [:fligtar]]

I've staged softblocks for the 3 guids in comment #10 for versions <= 4.3.0.00 in all versions of Firefox. Please test: https://wiki.mozilla.org/Blocklisting/Testing

Comment 12

[Marcia Knous [:marcia]]

fligtar: Sorry I missed the bugmail on this. I will test this today.

(In reply to comment #11)
> I've staged softblocks for the 3 guids in comment #10 for versions <=
> 4.3.0.00 in all versions of Firefox. Please test:
> https://wiki.mozilla.org/Blocklisting/Testing

Comment 13

[Marcia Knous [:marcia]]

I was able to test {c2d64ff7-0ab8-4263-89c9-ea3b0f8f050c} so far and confirm that the soft block works for that GUID. But I am having trouble locating the searchqu and the other GUID for Media Bar. I will udpate the bug when I have confirmed both of those.

Comment 14

[Marcia Knous [:marcia]]

When I download Bandoo version 7, I get 4.3.1.00 of searchqu {99079a25-328f-4bd4-be04-00955acaa0a7}. I have not yet been able to locate the earlier version of that toolbar or the other version of the mediabar.

Comment 15

[Kev Needham [:kev]]

Are we softblocking by design, or might this be a better hardblock candidate given comment #8 and unblocking.

Comment 16

[Sheila Mooney]

Asa, we want to get these blocked since it adds up to a lot of crashes. We have only been able to verify one of the versions since Marcia has had trouble installing the earlier ones. Do we go ahead and just block the 3 anyhow? What do you think?

Comment 17

[Marcia Knous [:marcia]]

Asa asked me about volume - the combined signatures make it harder to give it an overall ranking, but a quick crash stats query of "contains" datamngr.dll shows roughly 7000 crashes in the last week across all versions. If you look at a span of 4 weeks across all versions the total is 46K. So I think that would be a pretty compelling reason to blocklist this dll.

Comment 18

[Justin Scott [:fligtar]]

Blocked in production.

Comment 19

[Scoobidiver (away)]

Now the latest version is 4.3.1.00 as crashy as the blocked 4.3.0.00: no change in crash ranking.
It would haven't happen if all versions have been blocked as requested in comment 0.

Comment 20

[Sheila Mooney]

So for all these dlls we end up with over 700 a day. What is the next level of blocking we can do here. Do we have to block everything? Is there an intermediate step?

Comment 21

[Justin Scott [:fligtar]]

I've updated the block to cover 4.3.1.00.

Why are they still releasing new versions that crash? Can we try outreach again?

Comment 22

[Robert Kaiser]

(In reply to comment #21)
> I've updated the block to cover 4.3.1.00.
> 
> Why are they still releasing new versions that crash? Can we try outreach
> again?

We never could outreach as they don't have a useful contact. And this is as far as we know malware, they surely will always just bump the version when they find out it doesn't work as they like.

Comment 23

[roi]

Hello, I'm with the dev team of Bandoo and we are trying hard to resolve the problem you report
The datamngr.dll bug which caused the reported crashes was already fixed and released couple of weeks ago. As more users get the fix we should see less crashes

The different toolbars which were blocked are independent from the datamngr.dll 
Blocking the toolbars is not going to prevent or reduce crashes

The latest version of Bandoo available at http://bandoo.com/ has the fixed component along with toolbar version 4.3.1.0

This is not malware, we don't want to bump the version number up just to make it work, we want to fix the problem and keep the users' systems stable
Can you confirm that our latest release has indeed solved the reported bug and remove the toolbar from the blacklist?

Comment 24

[Scoobidiver (away)]

The datamngr dll has not been blocklisted, only MediaBar and Searchqu toolbars.
Anyway, the new datamngr.dll still makes Firefox crash.

Here are 5.0 correlations per module and crash signature over the last day:
* @0x0 | datamngr.dll@0x1b661|EXCEPTION_ACCESS_VIOLATION_EXEC (266 crashes)
    100% (266/266) vs.   3% (3427/99477) datamngr.dll
         82% (218/266) vs.   3% (3112/99477) 1.0.0.1
         18% (48/266) vs.   0% (315/99477) 3.0.0.42011
* @0x0 | datamngr.dll@0x1b661|EXCEPTION_ACCESS_VIOLATION_READ (49 crashes)
    100% (49/49) vs.   3% (3427/99477) datamngr.dll
         80% (39/49) vs.   3% (3112/99477) 1.0.0.1
         20% (10/49) vs.   0% (315/99477) 3.0.0.42011

Comment 25

[roi]

I believe we did fix the problem but we did not update the file version which is 1.0.0.1 and as a result you see crash reports from users with this file version.
We will update the file version and check again that it fixes the problem.

In any case, this dll has nothing to do with the blocklisted toolbars.  
Blocking these toolbars will not prevent the reported problem

Are the blocklisted toolbars causing any crashes?
If not, can you remove them from the block list?

Comment 26

[Scoobidiver (away)]

(In reply to comment #25)
> I believe we did fix the problem but we did not update the file version
> which is 1.0.0.1 and as a result you see crash reports from users with this
> file version.
18% of datamngr.dll users crashes with version 3.0.0.42011, which is the latest.

> In any case, this dll has nothing to do with the blocklisted toolbars.  
> Blocking these toolbars will not prevent the reported problem
You're right. Indeed, since the toolbar blocklisting, correlations with these toolbars dropped down:
*  @0x0 | datamngr.dll@0x1b661|EXCEPTION_ACCESS_VIOLATION_EXEC (266 crashes)
     29% (76/266) vs.   1% (866/99477) [e-mail] (5.1)
     14% (38/266) vs.   7% (6763/99477) {1E73965B-8B48-48be-9C8D-68B920ABC1C4}
*  @0x0 | datamngr.dll@0x1b661|EXCEPTION_ACCESS_VIOLATION_READ (49 crashes)
     18% (9/49) vs.   1% (866/99477) [e-mail] (5.1)
     14% (7/49) vs.   6% (6114/99477) [e-mail]
     29% (14/49) vs.  22% (22244/99477) {CAFEEFAC-0016-0000-0026-ABCDEFFEDCBA} (6.0.26)
      6% (3/49) vs.   0% (129/99477) {99079a25-328f-4bd4-be04-00955acaa0a7}
      6% (3/49) vs.   1% (926/99477) {51a86bb3-6602-4c85-92a5-130ee4864f13}

Can we have a relationship between crashy datamngr dll versions and crashy toolbar versions so that bad toolbar versions are blocklisted?

Comment 27

[roi]

The toolbars are not causing crashes
The component which caused a crash is the dll
We are working to figure out if the fix we released solves the problem and to update the dll version number
In any way, I suggest you remove the toolbars blocklisting as this is not preventing crashes

Comment 28

[Scoobidiver (away)]

(In reply to roi from comment #23)
> This is not malware
Searchqu toolbar ({99079a25-328f-4bd4-be04-00955acaa0a7})
http://www.spywareremove.com/removeSearchqu.html

Firefox protects against malware in websites:
http://www.mozilla.com/en-US/firefox/phishing-protection/

Right now, the add-on blocklisting is only used against crashes caused by add-ons, not against malware in add-ons. I think it should.

Comment 29

[Robert Kaiser]

I agree that we should remove the blocking for the add-ons and instead block a version range of the DLL. Which versions should we apply this to, roi?

Comment 30

[Marcia Knous [:marcia]]

I did some quick math and the combined signatures for the last week across all Firefox versions eclipse 10K. If we are going to pursue the DLL version range we need versions - Roi can you help? In Comment 25 you said you were going to update the file version, but lots of the crash reports I see still have version 1.0.0.1.

Comment 31

[Scoobidiver (away)]

(In reply to Marcia Knous [:marcia] from comment #30)
> In Comment 25 you said you were going to update the file version, but lots of the crash
> reports I see still have version 1.0.0.1.
According to crash correlations, datamngr.dll versions below 3.0.0.46593 must be blocked:
  @0x0 | datamngr.dll@0x1b661|EXCEPTION_ACCESS_VIOLATION_EXEC (283 crashes)
    100% (283/283) vs.   4% (3842/103991) datamngr.dll
         80% (227/283) vs.   3% (3280/103991) 1.0.0.1
         18% (50/283) vs.   0% (287/103991) 3.0.0.42011
          0% (1/283) vs.   0% (18/103991) 3.0.0.46362
          1% (3/283) vs.   0% (133/103991) 3.0.0.46577
          1% (2/283) vs.   0% (124/103991) 3.0.0.46593
  @0x0 | datamngr.dll@0x1b661|EXCEPTION_ACCESS_VIOLATION_READ (35 crashes)
    100% (35/35) vs.   4% (3842/103991) datamngr.dll
         77% (27/35) vs.   3% (3280/103991) 1.0.0.1
         20% (7/35) vs.   0% (287/103991) 3.0.0.42011
          3% (1/35) vs.   0% (18/103991) 3.0.0.46362
          0% (0/35) vs.   0% (133/103991) 3.0.0.46577
          0% (0/35) vs.   0% (124/103991) 3.0.0.46593

Comment 32

[Sheila Mooney]

So whatever we have done is not working. We still get a ton of these crashes and it's significant when we add up all the signatures. The bandoo guy confirmed that the toolbars are not causing crashes so blocking those does nothing. We need to block the dlls, correct? 

Can someone make a call on this? I know that blocking dlls is something that don't want to do. It's been sitting around for a long time and causing lots of crashes for our users. Who is the right person to own making this call?

Over 9000 crashes in the past week - combining all signatures across all versions.

Comment 33

[Justin Scott [:fligtar]]

I think Johnath has the call on DLL blocking. Note that DLL blocks are code-based, not server-based.

Comment 34

[Johnathan Nightingale [:johnath]]

I can r+ a patch here (which basically anyone can write - c.f. http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsWindowsDllBlocklist.h), we just need clarity on:

- Should we blocklist particular version ranges or all versions?
- Are there legitimate DLLs using the same name that we risk killing in the process?

Comment 35

[Marcia Knous [:marcia]]

One thing I noticed is (and I am not sure if it makes a difference) is that the debug identifier picked up in crash stats is not the same particular versions, for example

Version 1.0.0.1
Debug Indentifier: 19ADB0ADE5BC4EDBACDC5E5E1E42D39A1 in one report and D47143A82BCD4315B8CDDA354BC410471 in another

I am rolling up the versions that have the highest number of crashes right now.

Comment 36

[Marcia Knous [:marcia]]

I looked at a sample let of data from chofmann's latest report: https://crash-analysis.mozilla.com/crash_analysis/20110926/20110926_Firefox_7.0-interesting-modules-with-versions.txt.gz. From that it looks as if what Scoobidiver noted in Comment 31 stands.  The only version that appears in this set of data that did appear in Comment 31 was 3.0.0.49236 

10% (1/10) vs.   5% (1307/27381) datamngr.dll
          0% (0/10) vs.   4% (1076/27381) 1.0.0.1
          0% (0/10) vs.   0% (46/27381) 3.0.0.42011
          0% (0/10) vs.   0% (3/27381) 3.0.0.46362
          0% (0/10) vs.   0% (94/27381) 3.0.0.46577
         10% (1/10) vs.   0% (66/27381) 3.0.0.46593
          0% (0/10) vs.   0% (22/27381) 3.0.0.49236

@0x0 | datamngr.dll@0x1b661|EXCEPTION_ACCESS_VIOLATION_EXEC (69 crashes)
    100% (69/69) vs.   5% (1307/27381) datamngr.dll
         83% (57/69) vs.   4% (1076/27381) 1.0.0.1
         14% (10/69) vs.   0% (46/27381) 3.0.0.42011
          1% (1/69) vs.   0% (3/27381) 3.0.0.46362
          0% (0/69) vs.   0% (94/27381) 3.0.0.46577
          1% (1/69) vs.   0% (66/27381) 3.0.0.46593
          0% (0/69) vs.   0% (22/27381) 3.0.0.49236

I think we still need to get clarity on Jonathan's questions in Comment 34 in regard to the question of blocklisting all versions or particular versions ranges and whether we are sure they aren't dlls using the same ID. I guess in thinking about it more there would be more risk in blocking version ranges in that case.

Comment 37

[Marcia Knous [:marcia]]

I asked chofmann his thoughts regarding this and he mentioned maybe just blocking on the name and 1.0.0.1 will catch the right stuff and avoid anything legitimate.

Comment 38

[Randell Jesup [:jesup] (needinfo me)]

Did we ever do anything about blocking the DLL?  Do these crashes still occur?

Comment 39

[Scoobidiver (away)]

(In reply to Randell Jesup [:jesup] from comment #38)
> Did we ever do anything about blocking the DLL? 
An answer to comment 34 is expected.

> Do these crashes still occur?
There are now only 4200 crashes per week while the blocklisting bar is 10.000 crashes per week.

Comment 40

[Randell Jesup [:jesup] (needinfo me)]

So we need a patch for jonath to review.  I assume the 4200 number includes all the addons using datamngr.

Comment 41

[Alex Keybl [:akeybl]]

(In reply to Johnathan Nightingale [:johnath] from comment #34)
> - Are there legitimate DLLs using the same name that we risk killing in the
> process?

I don't believe so - here's what I could come up with.

Imesh datamngr.dll - http://www.fix-dllerrors.com/how-to-fix-datamngr-dll-error.htm
Bandoo Media (SearchQu) datamngr.dll - http://systemexplorer.net/filereviews.php?fid=6744394
"Datamngr.dll is related to Windows Searchqu Toolbar(another name is BearShare Mediabar" - https://encrypted.google.com/url?q=http://www.spywareremovalhelp.org/spyware-removal-help/what-is-datamngr-dll-how-to-fix-datamngr-dll-error.html&sa=U&ei=ypZOT-zlH9PaiQKkn5W0Cw&ved=0CA8QFjAA&sig2=3liQJUqfFuSkO8XdA603iA&usg=AFQjCNEGTIPDfNlo_iIHDOs9_1xTJK8aeQ

"BearShare MediaBar", "SearchQu Toolbar", "iMesh Toolbar". Given how many people are trying to uninstall these across the internet, I'd even be OK with blocking all versions outright.

Remaining tasks:

1) Create a blocklist patch for datamngr.dll
2) Have QA test a try build with the toolbars above to make sure we don't cause new crashes when blocking the DLL
3) Go for it

Comment 42

[Randell Jesup [:jesup] (needinfo me)]

I agree: go for it!  The web is full of people trying (and failing) to remove these, and virtually none of them appear to know where they got them (surprise).


From the top 100 addon Etherpad (no particular order):

- DataMngr (???) - http://www.google.com/search?q=%7B1FD91A9C-410C-4090-BBCC-55D3450EF433%7D
-----------------------------------------------------------------------------
- Notes: jZip Toolbar - it and the searchqu addons all use DataMngr dll.
Silently installed adware: http://forums.spybot.info/showthread.php?t=62634


? MediaBar - {28387537-e3f9-4ed7-860c-11e69af4a8a0} - http://www.google.com/search?q=%7B28387537-e3f9-4ed7-860c-11e69af4a8a0%7D
-----------------------------------------------------------------------------
- Notes: Closely related if not identical to {99079a25-328f-4bd4-be04-00955acaa0a7} (searchqu.net, see below)


? searchqu.net - {99079a25-328f-4bd4-be04-00955acaa0a7} - http://www.google.com/search?q=%7B99079a25-328f-4bd4-be04-00955acaa0a7%7D
-----------------------------------------------------------------------------
- Notes: This is a virus-like toolbar that resists removal (see Bug 665775)


? {c2d64ff7-0ab8-4263-89c9-ea3b0f8f050c} - http://www.google.com/search?q=%7Bc2d64ff7-0ab8-4263-89c9-ea3b0f8f050c%7D
-----------------------------------------------------------------------------
- Notes: This is BearShare MediaBar, closely related if not identical to {99079a25-328f-4bd4-be04-00955acaa0a7} (searchqu.net, see above)

Comment 43

[Alex Keybl [:akeybl]]

Johnathan - would you happen to know who puts together blocklist patches these days? I know Kev put together our last DLL blocklist patch, but I doubt it should be his responsibility to patch and create try builds. Thanks in advance.

Comment 44

[(no longer active)]

Attachment: Patch (v1)

Comment 45

[(no longer active)]

Try build: https://tbpl.mozilla.org/?tree=Try&rev=a1bd00172de6

Comment 46

[Scoobidiver (away)]

The following extension blocklist description should be updated accordingly:
https://addons.mozilla.org/firefox/blocked/i39
https://addons.mozilla.org/firefox/blocked/i40
https://addons.mozilla.org/firefox/blocked/i41

Comment 47

[Alex Keybl [:akeybl]]

(In reply to Ehsan Akhgari [:ehsan] from comment #45)
> Try build: https://tbpl.mozilla.org/?tree=Try&rev=a1bd00172de6

Thanks Ehsan and bsmedberg. Adding qawanted to do exploratory testing around the software in

https://bugzilla.mozilla.org/show_bug.cgi?id=665775#c41
https://bugzilla.mozilla.org/show_bug.cgi?id=665775#c42

with this try build. We want figure out whether we need to blocklist any associated add-ons and make sure we're not leaving users in a worse position than before the blocklist.

Comment 48

[juan becerra [:juanb]]

Using Fx11b5: When I look at the loaded dlls associated with the firefox.exe process (using Process Explorer) I see a datamngr.dll loaded. The toolbars are also loaded.

Using try-build: The datamngr.dll is still loaded as well as the other toolbars. The only add-on not loaded is the DataMngr 1.0 because it's not compatible with the nightly.

Both builds seem stable with all those toolbars, though.

Comment 49

[Alex Keybl [:akeybl]]

(In reply to juan becerra [:juanb] from comment #48)
> Using try-build: The datamngr.dll is still loaded as well as the other
> toolbars. The only add-on not loaded is the DataMngr 1.0 because it's not
> compatible with the nightly.

Ehsan/Benjamin - any ideas why the blocklist didn't seem to have had an effect on whether datamngr.dll was loaded?

Comment 50

[(no longer active)]

Juan, can you please try to see if that DLL is listed under this registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs

We are not yet capable of blocking DLL loads which are listed in that registry path.  If the DLL is not listed there, I don't know why the blocklisting has not worked.  Can you please verify that the DLL file on the disk has the exact same name?

Comment 51

[juan becerra [:juanb]]

(In reply to Ehsan Akhgari [:ehsan] from comment #50)

Only the datamgr.dll was listed in the registry (on WinXP) associated with the BearShare directory. On Win7 there were no entries in the registry.

Comment 52

[(no longer active)]

(In reply to juan becerra [:juanb] from comment #51)
> (In reply to Ehsan Akhgari [:ehsan] from comment #50)
> 
> Only the datamgr.dll was listed in the registry (on WinXP) associated with
> the BearShare directory.

If the DLL is listed in that registry key, we will not be able to blocklist it.

> On Win7 there were no entries in the registry.

Does Firefox still load that DLL in Windows 7 with the try build in this bug?

Comment 53

[juan becerra [:juanb]]

On Win7 the dll is not in the registry, and the dll is not loaded in neither Fx11b5 nor the try build.

Comment #48 was using XP, where the dll is in the registry and it is loaded in both Fx11b5 and the try build.

Comment 54

[(no longer active)]

(In reply to juan becerra [:juanb] from comment #53)
> On Win7 the dll is not in the registry, and the dll is not loaded in neither
> Fx11b5 nor the try build.
> 
> Comment #48 was using XP, where the dll is in the registry and it is loaded
> in both Fx11b5 and the try build.

OK, in that case, this is not a problem which we can solve by blocklisting.

Comment 55

[Jorge Villalobos [:jorgev] (he/him)]

(In reply to Ehsan Akhgari [:ehsan] from comment #54)
> (In reply to juan becerra [:juanb] from comment #53)
> > On Win7 the dll is not in the registry, and the dll is not loaded in neither
> > Fx11b5 nor the try build.
> > 
> > Comment #48 was using XP, where the dll is in the registry and it is loaded
> > in both Fx11b5 and the try build.
> 
> OK, in that case, this is not a problem which we can solve by blocklisting.

Should we just drop this bug and pursue another approach? Is there a way to patch Firefox to prevent this DLL from loading?

Comment 56

[(no longer active)]

Not sure what needs to happen here any more.

Comment 57

[Jorge Villalobos [:jorgev] (he/him)]

We're looking into this again on bug 812456, but things aren't looking very promising. I don't think there's more we can on this bug.