Closed Bug 1155198 Opened 5 years ago Closed 4 years ago

The NSS_CheckVersion function is not accessible in the NSS library that is installed alongside newer Firefox releases.

Categories

(Firefox Build System :: General, defect)

37 Branch
x86_64
Windows 7
defect
Not set

Tracking

(firefox43 wontfix, firefox44 wontfix, firefox45+ fixed, firefox46 fixed)

RESOLVED FIXED
mozilla46
Tracking Status
firefox43 --- wontfix
firefox44 --- wontfix
firefox45 + fixed
firefox46 --- fixed

People

(Reporter: jeromewagener, Assigned: froydnj)

Details

Attachments

(2 files)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0
Build ID: 20150415030206

Steps to reproduce:

We are using the NSS library (nss.dll) that is installed alongside Firefox in order to facilitate the handling of P12 files for our clients. In fact, we use PKCS#11 in order to automatically import SSL and signing certificates into the Firefox-Keystore using a small Java applet. (See http://docs.oracle.com/javase/7/docs/technotes/guides/security/p11guide.html#NSS)

This worked perfectly in the past including the current Firefox ESR (31.2.0). 

However it does no longer work with any recent Firefox versions (i.e. 37.1.0 or Nightly)


Actual results:

With recent versions of Firefox, our applet started throwing a NullPointerException that states that the NSS_CheckVersion symbol couldn't be found. As you can see below, the stacktrace shows that this NSS function is called from within PKCS11, more specifically from within Secmod.java

SEVERE: could not initialize applet
java.lang.NullPointerException: Symbol not found: NSS_VersionCheck
	at sun.security.pkcs11.Secmod.nssVersionCheck(Native Method)
	at sun.security.pkcs11.Secmod.fetchVersions(Secmod.java:111)
	at sun.security.pkcs11.Secmod.initialize(Secmod.java:212)
	at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:207)
	at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:107)

From what we gathered so far, we think that the following has happened:

1) At some point during the "recent" Firefox developments (Mid 2014), it was decided to not build NSS for Firefox with all the available symbols as this is quite costly. In fact, it is mentioned in various Bugzilla tickets that some symbols were removed in the past. (E.g 1072045 and especially 1025998)

2) As a result of this, a duplicate "external" nss.def file was created in August 2014 with the purpose of ignoring unused symbols. (https://hg.mozilla.org/mozilla-central/filelog/a35163f83d22/config/external/nss/nss.def)

3) Some time later Firefox was then build using this new external "nss.def" file which doesn't include all symbols. In our particular case, it lacks at least "NSS_VersionCheck" which is directly referenced by the Java runtime.

4) Our applet crashes since this new NSS version that is packaged with Firefox doesn't provide access to some of the functions required by Java's PKCS#11 anymore.




Expected results:

Even with new versions of Firefox, those functions that are used by the Java runtime environment should still be available in the NSS version that is packaged with Firefox. Otherwise applets that are using PKCS#11 will crash as described above.

A possible fix might consist of simply putting the relevant symbols again into the nss.def file that is used by Firefox.
Update the component to Core: Build config, perhaps there's someone with extensive knowledge on this area that might be able to help here.
Also add :froydnj to CC, perhaps can help us with this bug.
Component: Untriaged → Build Config
Product: Firefox → Core
Is there some way to see a complete list of all the symbols that Java wants to use from the NSS library?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(jeromewagener)
Hello Brindusa and Nathan,

Thank you very much for your reply. 

I dug a bit into the native C code of the JDK and I think that the only two symbols that are needed are:
* NSS_VersionCheck
* NSS_Initialize

I attached a screenshot of a simple search on the JNI portion of the JDK which shows that these two symbols seem to be the only ones that are used to create function pointers. 

In addition, after briefly analyzing the code, it seems that the NSS_Initialize function is capable of performing the required operations. This is also described by the MDN documentation which mentions that:

"NSS_Initialize initializes NSS. It is more flexible than NSS_Init, NSS_InitReadWrite, and NSS_NoDB_Init. If any of those simpler NSS initialization functions suffices for your needs, call that instead." 

See (https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Reference/NSS_Initialize)

Please let me know in case you need further information.

Kind regards,
Jérôme
Flags: needinfo?(jeromewagener)
A search for symbols and in the JDK. Only two symbols are used to create function pointers. NSS_VersionCheck and NSS_Initialize
(In reply to Jérôme from comment #3)
> Thank you very much for your reply. 

Thanks for the response on a really old bug!

> I dug a bit into the native C code of the JDK and I think that the only two
> symbols that are needed are:
> * NSS_VersionCheck
> * NSS_Initialize
> 
> I attached a screenshot of a simple search on the JNI portion of the JDK
> which shows that these two symbols seem to be the only ones that are used to
> create function pointers.

Hm, looking at:

http://mxr.mozilla.org/mozilla-central/source/config/external/nss/nss.symbols#1

or even NSS's version:

http://mxr.mozilla.org/mozilla-central/source/security/nss/lib/nss/nss.def#1

I see many more prefixes (CERT, DER, HASH, PK11, PORT, and several variants of SEC*, among others).  I would think that you'd have to call more than NSS_Initialize and NSS_VersionCheck to be able to use the library.  Unless those are called directly, and not used to create function pointers?  (That seems like an odd setup, but I'm not familiar with the JDK.)

Could you do a broader search using some of those prefixes as well?
Flags: needinfo?(jeromewagener)
Hello again,

To clarify things a bit:
- Your first link shows the external symbol file which is used during the build of Firefox
- Your second link show the symbol file for the entire NSS library

In order to verify which symbols are missing from the "Firefox-Symbol-List", (but which are needed by the JDK), I wrote a small script which recursively goes through the JDK code looking for all symbols that are defined in the "NSS-Symbol-List". Once the script finishes, it outputs the number of occurrences for the symbols, while also checking which of these symbols are NOT in the "Firefox-Symbol-List".

As you can see by by comments on the output below, most occurrences are due to macros or comments and should be ignored. 

In fact, the only symbol that is missing but which is REALLY NEEDED is >>>NSS_VersionCheck<<< as it is used to create a function pointer. NSS_Initialize as well as the other symbols that are used by the JDK seem to still be present in the "Firefox-Symbol-List" and should not cause problems. 

For reference, please find below my script output: (I added some comments on my own which are prefixed by //)

<SYMBOL-FOUND-IN-JDK>: <OCCURRENCES(NUMBER/FILES)> <MISSING?>(If missing, list files)
-------------------------------------------------------------------------------------
->> SECMOD_LoadModule: 2
->> SECOID_FindOID: 2
->> PORT_NewArena: 3
->> NSS_VersionCheck: 3 --> MISSING
     * C:\Users\ex605\Downloads\openjdk\jdk\src\share\native\sun\security\pkcs11\j2secmod.c 
        // !!! USED TO CREATE FUNCTION POINTER !!!
     * C:\Users\ex605\Downloads\openjdk\jdk\src\solaris\native\sun\security\pkcs11\j2secmod_md.h 
        // ONLY COMMENT
     * C:\Users\ex605\Downloads\openjdk\jdk\src\windows\native\sun\security\pkcs11\j2secmod_md.h 
        // ONLY COMMENT
->> SECMOD_GetDBModuleList: 2 --> MISSING
     * C:\Users\ex605\Downloads\openjdk\jdk\src\solaris\native\sun\security\pkcs11\j2secmod_md.h 
       // ONLY COMMENT
     * C:\Users\ex605\Downloads\openjdk\jdk\src\windows\native\sun\security\pkcs11\j2secmod_md.h 
       // ONLY COMMENT
->> SECITEM_FreeItem: 3
->> SECOID_FindOIDTag: 2
->> PORT_Free: 3
->> SECITEM_AllocItem: 4
->> NSS_Init: 3
->> SECMOD_GetModuleSpecList: 2
->> PORT_Alloc: 3
->> PORT_ArenaAlloc: 3
->> NSS_InitReadWrite: 1 --> MISSING 
     * C:\Users\ex605\Downloads\openjdk\jdk\src\share\native\sun\security\pkcs11\j2secmod.c 
       // JDK STRING WHICH MATCHES SYMBOL, USED TO IDENTIFY THE CALL OF NSS_INITIALIZE 
       // COMMENT TAKEN FROM JDK: --> "If the NSS_InitReadWrite function is requested then 
       // call NSS_Initialize..."
->> SECOID_FindOIDTagDescription: 1 --> MISSING
     * C:\Users\ex605\Downloads\openjdk\jdk\src\share\native\sun\security\ec\impl\ecdecode.c 
       // USED IN MACRO
->> PORT_ArenaRelease: 2 --> MISSING
     * C:\Users\ex605\Downloads\openjdk\jdk\src\share\native\sun\security\ec\impl\ecc_impl.h 
       // STRING USED TO DEFINE MACRO
     * C:\Users\ex605\Downloads\openjdk\jdk\src\share\native\sun\security\ec\impl\secitem.c 
       // MACRO CALL
->> NSS_NoDB_Init: 1
->> PORT_ZAlloc: 2
->> PORT_FreeArena: 3
->> PORT_SetError: 3
->> PORT_ArenaUnmark: 2 --> MISSING
     * C:\Users\ex605\Downloads\openjdk\jdk\src\share\native\sun\security\ec\impl\ecc_impl.h 
       // STRING USED TO DEFINE MACRO
     * C:\Users\ex605\Downloads\openjdk\jdk\src\share\native\sun\security\ec\impl\secitem.c 
       // MACRO CALL
->> SECITEM_CopyItem: 3
->> PORT_ZFree: 1 --> MISSING
     * C:\Users\ex605\Downloads\openjdk\jdk\src\share\native\sun\security\ec\impl\ec.c 
       // STRING USED IN MACRO
->> PORT_ArenaZAlloc: 4
->> NSS_Initialize: 3
->> SECMOD_GetDefaultModuleList: 1
->> PORT_ArenaMark: 2 --> MISSING
     * C:\Users\ex605\Downloads\openjdk\jdk\src\share\native\sun\security\ec\impl\ecc_impl.h 
       // STRING USED TO DEFINE MACRO
     * C:\Users\ex605\Downloads\openjdk\jdk\src\share\native\sun\security\ec\impl\secitem.c 
       // MACRO CALL
->> PORT_ArenaGrow: 1 --> MISSING
     * C:\Users\ex605\Downloads\openjdk\jdk\src\share\native\sun\security\ec\impl\ecc_impl.h 
       // STRING USED TO DEFINE MACRO

In case you would like to have a look at the JDK files yourself, you can download the source from http://download.java.net/openjdk/jdk8/

Please let me know in case you need further information or have questions regarding my investigation.

Kind regards,
Jérôme
Flags: needinfo?(jeromewagener)
Better late than never.
Attachment #8707911 - Flags: review?(mh+mozilla)
Attachment #8707911 - Flags: review?(mh+mozilla) → review+
https://hg.mozilla.org/mozilla-central/rev/a885fca1709a
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla46
Assignee: nobody → nfroyd
[Tracking Requested - why for this release]: Some Java applets require this to work properly with Java security libraries.  It would have been nice to fix this for ESR38, but we can at least try to fix it for ESR45.
Comment on attachment 8707911 [details] [diff] [review]
export symbols used by Java from Firefox-built NSS library

Approval Request Comment
[Feature/regressing bug #]: bug 1025998
[User impact if declined]: security-oriented Java programs won't work.
[Describe test coverage new/current, TreeHerder]: we have no test coverage for this feature, or we probably wouldn't have broken it in the first place.
[Risks and why]: Low risk.  Just reverting the visibility of some symbols in our NSS library.
[String/UUID change made/needed]: None.
Attachment #8707911 - Flags: approval-mozilla-aurora?
Comment on attachment 8707911 [details] [diff] [review]
export symbols used by Java from Firefox-built NSS library

Sure, in the context of 45 being an ESR, taking this uplift.
Attachment #8707911 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.