621320 - Proxifier does not work with Firefox because installer sets LSP_CATEGORIES for firefox.exe

Status: RESOLVED DUPLICATE of bug 636088

(Firefox :: Installer, defect)

Description

[Sergey Konovalov]

User-Agent:       Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; GTB6.6; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; Creative AutoUpdate v1.40.01)
Build Identifier: 4.0b8

Many Winsock LSPs like antiviruses and firewalls has LSP_SYSTEM category set to be loaded into all processes on the system.
For example: LSP_INSPECTOR | LSP_SYSTEM

Since recently Firefox specifies LSP_CATEGORIES (defines.nsi.in(24)) on install which should allow all categories.

But according to the strange Microsoft logic LSP that has no categories set or LSP_SYSTEM specified will never be loaded into Firefox.
For more info please see:
http://msdn.microsoft.com/en-us/library/bb513664(VS.85).aspx

This effectively means that Firefox will not work with a number of third party products like  firewalls, antiviruses, parental control and etc.

I guess the only possible solution is to remove LSP_CATEGORIES manipulation from installer at all.
This will provide a maximum compatibility.

Personally I do not see any reasons to deal with LSP_CATEGORIES for Firefox. It tries to specify all categories anyway.
Also Microsoft designed WinSock the way that LSP_CATEGORIES will be completely ignored if Firefox.exe is started with a parameter at the command prompt e.g. firefox.exe www.google.com

As far as I understand to fix the problem one should just comment the following line at installer.nsi (line 379):
${SetAppLSPCategories} ${LSP_CATEGORIES}

To test the above problems you can use our product called Proxifier www.proxifier.com
Free trial: http://www.proxifier.com/distr/ProxifierSetup.exe

Please also feel free to contact me at email.


Reproducible: Always

Steps to Reproduce:
1. Install and use some LSP based software e.g. Proxifier www.proxifier.com (just install and keep it running)
2. Install Firefox 4.0b8 on Vista or Win7

Actual Results:  
Firefox completely bypasses LSP based software. Becouse LSP module is not loaded into firefox.exe by Windows becouse installer sets LSP_CATEGORIES.

In case of Proxifier, Firefox connections will not appear in the connection list.

Expected Results:  
Firefox works properly with LSP based software.

In case of Proxifier, Firefox connections appear in the connection list.

Comment 1

[Robert Strong (they/them - no direct email)]

Do you know of other LSP applications this affects?

Comment 2

[Jo Hermans]

Bug 523410 was the one that has set LSP_CATEGORIES in the first place. Read the comments in that bug to see why.

Comment 3

[Sergey Konovalov]

(In reply to comment #1)
> Do you know of other LSP applications this affects?
 
Yes. I have just reproduced the above problem with ProxyCap (an Proxifier analog), DrWeb (a popular antivirus/firewall), Vista Parental control. In all cases Firefox 4.0b8 completely bypassed the LSPs.

(In reply to comment #2)
> Bug 523410 was the one that has set LSP_CATEGORIES in the first place. Read the
> comments in that bug to see why.

Thanks. I have read the whole discussion. Now I understand the goal of this change. You wanted to protect firefox.exe from buggy/harmful LSPs.
Unfortunately your implementation has two sever problems:
1. Virtually no currently available LSPs get categorized. Almost nobody knows about this API.
2. Even if some LSPs get categorized. In some cases it is impossible to match firefox.exe conditions e.g. an antivirus with LSP_SYSTEM | LSP_INSPECT.

Unfortunately the second problem cannot be solved at all. Look at DrWeb LSP.  It must be categorized as LSP_SYSTEM | LSP_INSPECT. But it will not be loaded by firefox.exe because of LSP_SYSTEM. What should DrWeb developers do to support Firefox?

Another bad thing: these problems can remain unnoticed for a long time. It is extremely confusing and it can make a lot of harm in case of antivirus/firewall/parental control. Suppose you use DrWeb and think that you are protected when you are actually not.

Also LSP categories will not work (by design) if you run firefox.exe with a command line parameter or change the firefox.exe path. Imagine that there is a buggy LSP on the computer. Normally it doesn’t affect Firefox because of the LSP categories. Some time user opens a local html-file with "firefox.exe file.html". The buggy LSP gets loaded and eventually crashes Firefox. It will be extremely difficult to investigate this case.

I strongly discourage you to deal with LSP categories. There are some obvious design flaws in this API done by Microsoft. At least it would make sense to add a special processing for LSP_SYSTEM. I guess Microsoft had other consideration to add this functionality. Basically they wanted to protect system critical processes from buggy LSPs that can hang the whole computer or even cause a BSOD. Another goal is to provide a way to settle the conflicts between multiple LSPs. You can read more on this at:
http://blogs.msdn.com/b/wndp/archive/2006/02/09/529031.aspx

The final argument to remove LSP_CATEGORIES for firefox.exe is that there is no a single user application from Microsoft that use LSP categories. They are for services only.

If you want an ultimate way to get control over LSPs I guess you can use the following approach:
1. Use WSAEnumProtocols to enum available TCP providers.
2. Use WSCGetProviderPath to get LSP dll path.
3. Decide whether or not to use the specific LSP. You can even evaluate LSP file digital signature and check its category.  You can use some kind of white/black lists here.
4. If LSP is bad – use a system base provider.
5. Finally you should just pass WSAPROTOCOL_INFO of selected provider to WSASocket() call.

Comment 4

[timeless]

1. is so not our problem. if you have an app which is not Vista friendly, file a bug against the app saying it doesn't work with firefox because it isn't Vista friendly.

2. i presume it's possible for a product to have multiple libraries each with their own sets of categories, one category which would be acceptable to firefox.

3. As for these "problems" going unnoticed, that's not true. We noticed an improvement in our crash reports. They were noticed nearly immediately. For any vendor which thinks its product is important, it's that vendor's job to test with major applications.

4. if you want to propose an alternative to our LSP solution, please provide a patch.

Since our fix we've seen a huge reduction in the number of crashes. It also frees up time to deal with other problems. 

I'm going to close this bug as invalid, the change is intentional - by design.

If you provide a patch which implements your points 1..5 in a new bug, someone will consider it.

Comment 5

[timeless]

bug 513329 and bug 514612 shows our current unhappy LSP crashers.

Comment 6

[Sergey Konovalov]

(In reply to comment #4)
> 1. is so not our problem. if you have an app which is not Vista friendly, file
> a bug against the app saying it doesn't work with firefox because it isn't
> Vista friendly.
I can reproduce this "bug" with a built-in Vista Parental Control done by Microsoft (Vista x64 only).
I think this software is Vista friendly. Should I file bug to Microsoft or Firefox?

> 2. i presume it's possible for a product to have multiple libraries each with
> their own sets of categories, one category which would be acceptable to
> firefox.
I doubt this is possible. It will be a terrible mess of LSPs.

> 3. As for these "problems" going unnoticed, that's not true. We noticed an
> improvement in our crash reports.
I was going to say that end users will not immediately notice that LSPs do not work. In the case of antivirus or parental control it can harm.

> 4. if you want to propose an alternative to our LSP solution, please provide a
> patch.
>...
> If you provide a patch which implements your points 1..5 in a new bug, someone
> will consider it.
I can provide a CPP code for this. It will not be lengthy. Unfortunately, someone has to integrate it into Firefox because I have no experience in this project. Is it OK?
By the way, it will work in WinXP/Win2k too so Firefox will be protected from bad LSPs on all Win platforms.

Comment 7

[timeless]

If you're saying that Vista's parental controls aren't properly tagged, then yes, file a bug against microsoft.

end users might not immediately notice missing functionality, just as they might not immediately notice not crashing. but on the whole, not crashing is much more valuable and affects many more users.


offhand such code probably belongs near:
http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsWindowsDllBlocklist.cpp

follow the instructions near:
https://developer.mozilla.org/en/Windows_Build_Prerequisites

get a build, get a patch which does something. if you have trouble, ask on irc.mozilla.org.