514955 - SM 1.1.18 PSM Initialization fails because NSS 3.12 doesn't support Win9x or WinNT4

Status: RESOLVED WONTFIX

(SeaMonkey :: Security, defect, P1)

Description

[Benoît]

Even with bug#512187 fixed, the PSM still fails to initialise on
-Windows NT 3.51
-Windows 95
-Windows NT4
-Windows 98 with 98lite

The presence of IE doesn't seem to matter, except for Windows 98 and Windows Me, as vanilla installs of those Windows versions do not have this problem.

Comment 1

[Robert Kaiser]

Sorry, we cannot go back to an older NSS version due to security issues (MITM of SSL connection, etc) and we also will not work on making NSS 3.12 work with ancient Windows versions, so this is WONTFIX.

Comment 2

[Benoît]

KaiRo, you seem to fail to notice that SeaMonkey 1.1.18 DOES work on Windows 98 and Windows Me, unless they don't have IE. There is something else going on here than the drop of support of Win9x.

Furthermore, SeaMonkey 1.1.x officially supports these "ancient Windows versions", so you are committed to them, whether you like it or not.

Comment 3

[Robert Kaiser]

Benoît, feel free to fix NSS yourself to support Win95 and NT 3.51, we can reconsider if NSS takes a fix, but what I'm saying is the SeaMonkey team will not fix this problem, we are no NSS hackers and we can't go back to an older NSS version unless we want all of our users to be susceptible to MITM attacks on SSL connections.

Comment 4

[Philip Chee]

Re-opened temporarily so that I can ask the NSS team if there is a feasible workaround.

Apparently IE4.0 update is included in the requirements since December 2006. See
Bug 361340 (Mingw build error in SpecialSystemDirectory.cpp, error: `::SHGetSpecialFolderPathW' has not been declared).

SHGetSpecialFolderPathW was introduced in Bug 481968 (Update mozilla-1.9.1 to pick up NSS 3.12.3 or newer).

All other places that use SHGetSpecialFolderPathW actually alias it to SHGetSpecialFolderPath:
http://mxr.mozilla.org/mozilla-central/search?string=SHGetSpecialFolderPathW&find=&tree=mozilla-central

CC Kai, Is it possible to do the same in the NSS code?

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

Question for Robert and SM folks:
Does SM have its own copy of NSS on the SM 1.1 branch? (and is that CVS or Hg?)
Or does it use a copy of NSS on some other branch/tree that is shared with 
some versions of Firefox?  

I'm guessing that this problem began at some point when a rather new version
of NSS (such as version 3.12.3, which was developed for the platforms supported by the 1.9.1 FF branch) was back-ported to one or more older branches, which 
still have requirements to support older platforms.  The array of possible 
solutions depends in large part on which branch(es) we're talking about here,
exactly, and what (if any) requirements the products built from those branches
have with respect to being certified for use by anyone in the US government.
Old branches that are not shared with Firefox and have no US government 
certification requirements have the widest range of possible solutions.
Please advise.

Comment 6

[Philip Chee]

SeaMonkey 1.1.x comes from the Mozilla 1.8 tree (1.8.1.something) http://mxr.mozilla.org/mozilla1.8/. This is on CVS. We pick up what ever NSS version is in that tree at the point of tagging. Firefox 2.0.0.x comes from the same tree but Mozilla Corp has dropped support for the 2.0x series. Some Linux distributions with long term stable versions still support Firefox 2.0x (contact asac for details).

I would guess that we could use the ANSI version (SHGetSpecialFolderPathA) on old branches or do some #IFDEF magic like http://xoblite.net/source/Settings.h.html

#ifndef SHGetSpecialFolderPath 
SHSTDAPI_(BOOL) SHGetSpecialFolderPathA(HWND hwnd, LPSTR pszPath, int csidl, BOOL fCreate);
SHSTDAPI_(BOOL) SHGetSpecialFolderPathW(HWND hwnd, LPWSTR pszPath, int csidl, BOOL fCreate);
#ifdef UNICODE 
#define SHGetSpecialFolderPath  SHGetSpecialFolderPathW 
#else 
#define SHGetSpecialFolderPath  SHGetSpecialFolderPathA 
#endif 
#endif

Comment 7

[Robert Kaiser]

(In reply to comment #5)
> Question for Robert and SM folks:
> Does SM have its own copy of NSS on the SM 1.1 branch? (and is that CVS or Hg?)
> Or does it use a copy of NSS on some other branch/tree that is shared with 
> some versions of Firefox?  

SM 1.1.x comes directly from the 1.8 branch on CVS and uses whatever NSS is being pulled in by config.mk on that branch - currently that is some 3.12.x version, you surely remember all the discussion of bug 504523 that switched us to that.

Comment 8

[Nathan Lineback]

Neither the A or W version of SHGetSpecialFolderPath exists in Windows NT 3.51, 95, or NT 4. 

After looking over the code and what it does, I think the best solution would be to link to that API at runtime in win_rand.c, like it does with the ADVAPI32.DLL crypto functions, and if it is not present then skip the loop retrieving the 4 folder paths in EnumSystemFiles. 

What it is trying to do is get the actual path names for the recycle bin, the recent folders, the MSIE cache folder, and the MSIE history folder to sample files for "entropy". 

None of these folders even exist on NT 3.51, and the MSIE folders might not exist under 95 or NT 4, so they would need to be skipped anyway. On a system where the API exists, that mostly ensures these folders do exist and everything is in order.

Comment 9

[Benoît]

Now that the problem has been discovered and some solutions have been proposed, what shall be done about this?

Comment 10

[Robert Kaiser]

All that can be done is in the realm of NSS, so it's entirely up to Nelson and his fellow NSS people. The SeaMonkey team specifically can't do anything about NSS code, and we also can't step backl to a version that supports older versions because going to code that allows MITM attacks on SSL connections is out of the question.

Comment 11

[Nelson Bolyard (seldom reads bugmail)]

The history here is this:
In the development of NSS 3.12.x, the NSS team accepted a patch from the 
fennec team that was intended to solve a problem for WinCE, and was said
to work on all windows platforms supported by Mozilla. That patch added 
the calls to SHGetSpecialFolderPathW.  We all knew that this function did
not exist in Win9x and WinNT4.  What we did not know at that time (or had
forgotten) was that products are still being shipped for Win9x and WinNT4 
from Mozilla's code base.  We believed that the requirement to support 
Win9x and WinNT4 had been explicitly removed, and indeed there had been  
bugs files requesting that code whose sole purpose was to support those 
old platforms be specifically removed.  

Today, we're looking at the least painful way to restore compatibility 
with Win9x and WinNT4.  It appears that we may need to do nothing more than 
provide a SHGetSpecialFolderPathW function that emulates the Win2k version 
of that function, even if it is an imperfect emulation.  Perhaps we can do 
that in PSM.  Perhaps we develop an "extension" for use only on Win9x/NT4.

Comment 12

[Benoît]

API calls for IE's history and cache folders should return FALSE in this emulation. Does NSS account for that possibility?

Emulating the API for the Recycle Bin and the Recent folder seems easy enough. The Recycle Bin is always C:\RECYCLED (as far as I know, and if it's present), and the Recent folder path is stored in the registry along with other special folder paths, at HKEY_CURRENT_USER/Software/Microsoft/CurrentVersion/Explorer/Shell Folders.

Comment 13

[Nathan Lineback]

I don't think re-implementing SHGetSpecialFolderPathW is quite as simple as it might sound, unless perhaps you mean to just forward it on to the real deal if it is present and return a null path otherwise.

Is there any reason why something like the following would not work or not be sufficient? This works for me under Windows NT 3.51, 95, NT 4 and later. Would loading the function at runtime like this cause any problems with Win CE? Or did they do it that way for a reason :)

Of course if, going forward, anybody plans on using SHGetSpecialFolderPathW in other places in the 1.8 branch then having the call wrapped in a custom function could be better. 

typedef BOOL 
(WINAPI *SHGetSpecialFolderPathWFn)(
    HWND hwndOwner,
    LPWSTR lpszPath,
    int nFolder,
    BOOL fCreate);

static BOOL
EnumSystemFiles(Handler func)
{
    HMODULE hModule;
    SHGetSpecialFolderPathWFn pSHGetSpecialFolderPathW;
    PRUnichar szSysDir[_MAX_PATH];
    static const int folders[] = {
        CSIDL_BITBUCKET,  
        CSIDL_RECENT,
#ifndef WINCE     
        CSIDL_INTERNET_CACHE, 
        CSIDL_HISTORY,
#endif
        0
    };
    int i = 0;
    if (_MAX_PATH > (i = GetTempPathW(_MAX_PATH, szSysDir))) {
        if (i > 0 && szSysDir[i-1] == L'\\')
            szSysDir[i-1] = L'\0'; // we need to lop off the trailing slash
        EnumSystemFilesInFolder(func, szSysDir, MAX_DEPTH);
    }
    hModule = LoadLibrary("shell32.dll");
    if (hModule != NULL) {
      pSHGetSpecialFolderPathW = (SHGetSpecialFolderPathWFn)
        GetProcAddress(hModule, "SHGetSpecialFolderPathW");
      if (pSHGetSpecialFolderPathW) {
        for(i = 0; folders[i]; i++) {
            DWORD rv = pSHGetSpecialFolderPathW(NULL, szSysDir, folders[i], 0);
            if (szSysDir[0])
                EnumSystemFilesInFolder(func, szSysDir, MAX_DEPTH);
            szSysDir[0] =  L'\0';
        }
      }
      FreeLibrary(hModule);
    }
    return PR_TRUE;
}

Although I must say I don't really like the idea of SeaMonkey/Firefox poking around at files that don't belong to it. If I were a security program I would slap SeaMonkey/Firefox upside the head for doing that... but whatever.

Comment 14

[Nelson Bolyard (seldom reads bugmail)]

The immediate problem is the ABSENCE of any function named 
SHGetSpecialFolderPathW in the process address space.
In reply to comment 12: There is (obviously) a range of possible emulations.  
As a lower bound, NSS will accept an emulation that is nothing more than this:

BOOL SHGetSpecialFolderPathW( HWND hwndOwner, WCHAR *lpszPath,
    int csidl, BOOL fCreate)
{
    *lpszPath = 0;
    return FALSE;
}

The more values of csidl for which the function can output valid non-empty 
string values, the better.

Nathan,  I very much appreciate that you're trying to help solve the problem.
You're part of the Mozilla community at its finest!  Now, assume that the 
given requirement is that the file win_rand.c (or any other source file that goes into freebl.dll) cannot be changed for whatever reason (it doesn't matter what the reason is).  How else can you solve the problem?

Comment 16

[Robert Kaiser]

As we have end-of-lined the 1.x series, stopped all support for it and it's even a security risk to use it because of its vulnerabilities, we better admit that we can't and won't fix this any more. Sorry.