NTLM sometimes causes crashes under Win9x

RESOLVED FIXED in mozilla1.5final



15 years ago
15 years ago


(Reporter: bugzilla, Assigned: darin.moz)


({crash, fixed1.4.2, fixed1.5})

Windows 95
crash, fixed1.4.2, fixed1.5
Bug Flags:
blocking1.5 -

Firefox Tracking Flags

(Not tracked)



(9 attachments, 3 obsolete attachments)



15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.4) Gecko/20030624

I type in the address of a server on the intranet that is running Windows NT4,
accessing a Virtual Directory that has Anonymous Authentication turned off,
leaving only Integrated Windows Authentication. According to the release notes,
Mozilla 1.4 supports NTLM Authentication. However, when I attempt to access the
page, it returns the 401.2 error, "Unauthorized: Logon Failed due to server
configuration" However, using Live HTTP Headers, I see that the WWW-Authenticate
header field does have NTLM... Also, I can access the same URL using IE and it

Reproducible: Always

Steps to Reproduce:
1. Type in a URL that goes to a folder or page that requires NTLM authentication.
2. Do this from a workstation that has an authorized person logged in.
Actual Results:  
A page loads with the following text:
HTTP Error 401
401.2 Unauthorized: Logon Failed due to server configuration
This error indicates that the credentials passed to the server do not match the
credentials required to log on to the server. This is usually caused by not
sending the proper WWW-Authenticate header field.

Please contact the Web server's administrator to verify that you have permission
to access to requested resource.

Expected Results:  
Performed the appropriate authentication and displayed the web page.

Here's what Live HTTP Headers reports (names have been changed):


GET http://intranet.example.com/VirtualDirectory/ HTTP/1.1
Host: intranet.example.com
User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.4) Gecko/20030624
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer: http://intranet.example.com/

HTTP/1.x 401 Unauthorized
WWW-Authenticate: NTLM
Content-Length: 644
Content-Type: text/html
X-Cache: MISS from cache.example.com

Comment 1

15 years ago
reporter: can you please generate a HTTP log using the directions from here:



Comment 2

15 years ago
also make sure to send user/password as:
user: DOMAIN\user
password: password

Comment 3

15 years ago
Created attachment 127510 [details]
http log as requested of attempt to attach to specified site using NTLM

Comment 4

15 years ago
Confirmed with 1.4 Final
I don't know if it is because of an https:// connection (which this attempt
was), or IIS6, or something else.  I have created an attachment of an HTTP log
of my attempt to connect.

Enter Site address in browser address bar
Not authorized screen -- no login box pops up.

Comment 5

15 years ago
>0[781e70]: nsHttpChannel::GetAuthenticator [this=2625620 scheme=ntlm]
>0[781e70]: authentication type not supported
>0[781e70]: ProcessAuthentication failed [rv=80004005]

that's the significant snipet from the log file.  for some reason the NTLM
authentication module cannot be found.

reporter: do you have FIPS mode enabled?  if you do not have it enabled (or if
you don't know what it is) can you instead then try re-installing mozilla after
completely uninstalling your existing copy?  also, try a new user profile.  thx!

Comment 6

15 years ago
Created attachment 127542 [details]
HTTP log of failed NTLM Authentication

Here's the result of following the instructions indicated above. I am not using
SSL in my environment. 

HTH, Mike

Comment 7

15 years ago
Well, I don't know what FIPS mode is, so I uninstalled and reinstalled Mozilla,
creating a new profile on startup. I received the same error. It never shows a
prompt for username/password.

Note: that last log was made with the previous installation of Mozilla. I'll try
to create another with this one... Thanks.

Comment 8

15 years ago
Created attachment 127580 [details]
Yet another HTTP log of NTLM authentication

This log was created after uninstalling and reinstalling Mozilla 1.4 on Win95.
Also created a new profile and set the default home page to about:blank.
HTH, Mike
Attachment #127542 - Attachment is obsolete: true

Comment 9

15 years ago
*** Bug 213086 has been marked as a duplicate of this bug. ***


15 years ago
Severity: normal → major
Ever confirmed: true
Summary: HTTP Error 401.2 on NTLM Authentication to intranet site → NTLM authenticator cannot be loaded under Win9x (sometimes?)
Target Milestone: --- → mozilla1.5beta


15 years ago
Summary: NTLM authenticator cannot be loaded under Win9x (sometimes?) → NTLM authenticator cannot be loaded under Win9x (security.dll not found)

Comment 10

15 years ago
from a Win98 box:

  C:\WINDOWS\SYSTEM>dumpbin /exports secur32.dll
  Microsoft (R) COFF Binary File Dumper Version 6.00.8447
  Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

  Dump of file secur32.dll

  File Type: DLL

  Section contains the following exports for Secur32.dll

           0 characteristics
    353B8DAA time date stamp Mon Apr 20 11:02:18 1998
        0.00 version
           1 ordinal base
          18 number of functions
          18 number of names

    ordinal hint RVA      name

          1    0 000017AE AcceptSecurityContext
          2    1 000016BD AcquireCredentialsHandleA
          3    2 00001842 ApplyControlToken
          4    3 0000181D DeleteSecurityContext
          5    4 0000186B EnumerateSecurityPackagesA
          6    5 00001A61 FreeContextBuffer
          7    6 0000171D FreeCredentialsHandle
          8    7 00001A8E ImpersonateSecurityContext
          9    8 000016A9 InitSecurityInterfaceA
         10    9 00001737 InitializeSecurityContextA
         11    A 00001AE2 MakeSignature
         12    B 00001A9E QueryContextAttributesA
         13    C 00001AC0 QueryCredentialsAttributesA
         14    D 00001A33 QuerySecurityPackageInfoA
         15    E 00001A96 RevertSecurityContext
         16    F 00001B2E SealMessage
         17   10 00001B54 UnsealMessage
         18   11 00001B08 VerifySignature


        1000 .data
        1000 .idata
        1000 .reloc
        1000 .rsrc
        5000 .text

so, this means we need to load secur32.dll under Win9x and lookup the A-suffixed
function names instead.  patch should be trivial.

Comment 11

15 years ago
Created attachment 128070 [details] [diff] [review]
v0 patch - untested

Comment 12

15 years ago
Created attachment 128073 [details] [diff] [review]
v1 patch - this works
Attachment #128070 - Attachment is obsolete: true


15 years ago
Attachment #128073 - Flags: superreview?(alecf)
Attachment #128073 - Flags: review?(dougt)

Comment 13

15 years ago
why are we using the "security.dll"?  Can't we just load "secur32.dll" on all
window versions?  Looking at msdn, it looks like most of the authentication
functionality reference the secur32 lib.

Comment 14

15 years ago
dougt: good call... i think i took "security.dll" from some sample code :(

Comment 15

15 years ago
Created attachment 128109 [details] [diff] [review]
v2 patch

just load secur32.dll on all platforms.
Attachment #128073 - Attachment is obsolete: true


15 years ago
Attachment #128073 - Flags: superreview?(alecf)
Attachment #128073 - Flags: review?(dougt)


15 years ago
Attachment #128109 - Flags: review?(dougt)

Comment 16

15 years ago
Comment on attachment 128109 [details] [diff] [review]
v2 patch

Attachment #128109 - Flags: review?(dougt) → review+


15 years ago
Attachment #128109 - Flags: superreview?(alecf)

Comment 17

15 years ago
Comment on attachment 128109 [details] [diff] [review]
v2 patch

Attachment #128109 - Flags: superreview?(alecf) → superreview+

Comment 18

15 years ago
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 19

15 years ago
(security.dll is just a forwarder for secur32.dll - there's no difference
between them.)

Comment 20

15 years ago
I downloaded and installed build 2003072204 to check to see if the bug was 
fixed. I was prompted for a user name and password for our proxy server. After 
entering it, Mozilla crashed with an invalid page fault error. Here are the 

MOZILLA caused an invalid page fault in
module SECUR32.DLL at 0167:7f8737da.
EAX=40b50600 CS=0167 EIP=7f8737da EFLGS=00010202
EBX=00000000 SS=016f ESP=0065f6a8 EBP=0065f72c
ECX=00000000 DS=016f ESI=00090312 FS=4cff
EDX=01c35035 ES=016f EDI=019fed10 GS=4cee
Bytes at CS:EIP:
89 01 8b 45 fc 89 51 04 c7 40 20 01 00 00 00 83 
Stack dump:
019f82e0 019f82d8 00000000 00080007 00439018 00000000 00000000 019fed27 
00000037 00000008 0065f704 00439710 00430000 00019410 bff7b31d 00430000 

I reset my user profile and entered the proxy information again. The problem 
consistently repeats itself.

Based on this, I don't believe this bug has been completely resolved yet (but 
it's getting close :-) ).

Comment 21

15 years ago
Created attachment 128238 [details]
HTTP log for the previous entry

Comment 22

15 years ago
Steve: what version of Windows are you testing?
Severity: major → critical
Keywords: crash
Resolution: FIXED → ---

Comment 23

15 years ago
Steve: nevermind, you're log file shows that you are on Win98.

Comment 24

15 years ago
based on the log file, it seems that InitializeSecurityContext is the entry
point that is crashing.  i have access to a Win98 box, but it is going to take
me some time to get a testcase ready.


15 years ago
Priority: -- → P1

Comment 25

15 years ago
Steve: Something seems really wrong with your windows installation.  Other folks
have told me that they are not having any trouble with NTLM authentication under
Win98.  Does NTLM authentication work properly when you use Internet Explorer?

Comment 26

15 years ago

Absolutely! I have never had problems with accessing the Internet via IE (using 
both versions 5.5 and 6.0). I'm also not prompted to enter my NT userid and 
password when trying to access the proxy server which Mozilla expects me to do 
(Come to think of it, the users who run Mozilla on their NT4 workstations are 
not prompted for a userid and password when they start up Mozilla as well).

Is there a setting that maybe affecting this?


Comment 27

15 years ago
I stand corrected...

The NT users needed to enter their userid and password the first time they ran 
Mozilla in order to access the Proxy Server.

Sorry for the confusion.


Comment 28

15 years ago
>Is there a setting that maybe affecting this?

no setting.  we decided that it is probably not wise to blindly hand out the
user's windows logon to any machine that requests it.  sure, we're only sending
a hash of the user's password, but it is not a very strong hash (MD4).

so, i'm really baffled about why your system is having trouble.

Comment 29

15 years ago
I understand.

Some more specifics about my environment:

O.S.: Windows 98SE Build 4.10.2222 A

Directory Entry for secur32.dll:

SECUR32  DLL        40,960  04-23-99 10:22p SECUR32.DLL

Could the problem be due to me running 98SE instead of 98?


Comment 30

15 years ago
The fact that you are running Win98SE really shouldn't be an issue.  It must be
the case that Mozilla is passing bad data to Windows, but the log file doesn't
indicate any problems, and since the code is working for other people, I'm
really not sure what the problem could be.  I might try to add some more LOG
statements to the code.  Maybe that's the way to proceed....

Comment 31

15 years ago
*** Bug 215947 has been marked as a duplicate of this bug. ***

Comment 32

15 years ago
Created attachment 129732 [details]
http logfile because talkback won't submit anything

I'm coming in from another bug, which duplicates this one (sorry, I did look
security bugs, but my page fault comes from module SECUR32.DLL).

I have an HTTP log attachment for this, demonstrating something useful, I
suppose.  Be advised Mozilla crashes on this, but I can compose HTML pages
and even opne up the application, so long as I don't try to browse
anything remotely.

I've rolled back to 1.4 for now.  And I'm not screaming for anyone's head,
just take your time and do it right is all anyone should ask.  I'm with
Mozilla all the way.

Comment 33

15 years ago
thanks Christopher... since many folks with Win98 boxes are unable to reproduce
this crash, I may need to enlist your help to test out some things for me,
including running a diagnostic program, etc.  are you game?

Comment 34

15 years ago
absolutely.  it's the least i could do for the team.

Comment 35

15 years ago
I just crashed trying to access the Outlook web interface.
IE can access it just fine.

Win 98 (4.10.1998) using Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5b)
Gecko/20030817 Mozilla Firebird/0.6.1+.

SECUR32.DLL (version 4.10.2222)  40,960 bytes  Friday, April 23, 1999 10:22:00 PM

Talkback ID: TB22914777H

I am willing to run diagnostic software also.

Comment 36

15 years ago
Created attachment 130147 [details]
ntlmdump: diagnostic program

ok, here's a little diagnostic program.  i'm not sure that it will tell us very
much, but maybe it is a good place to start.  this attachment is a .zip file
containing the executable for the program along with its source.  all you need
to do is run the executable, save the output into a text file, and upload that
output to this bug report (or feel free to email it directly to me).  thanks!

Comment 37

15 years ago
Created attachment 130174 [details]
ntlmdump.exe Output From My System

Let me know if you need anything else.

Steve Illgen

Comment 38

15 years ago
The output from ntlmdump.exe on my system matches that of Steve.


Comment 39

15 years ago
My output, as inline text for those playing at home.

  dwVersion = 0x1
  AcquireCredentialsHandle = 7F8716BD
  FreeCredentialHandle = 7F87171D
  InitializeSecurityContext = 7F871737
  AcceptSecurityContext = 7F8717AE
  DeleteSecurityContext = 7F87181D
  fCapabilities = 0x77
  wVersion = 0x1
  wRPCID = 0xa
  cbMaxToken = 768
  Name = NTLM
  Comment = NTLM Security Package

Comment 40

15 years ago
thanks guys!  i'll let you know if it tells me anything...

Comment 41

15 years ago
Status, please?  It's a critical sev-1, just wondering if there's been any news.

Comment 42

15 years ago
sorry, no update.  this bug is still very perplexing to me.  my plan is to write
yet another test program for you guys to try and run.  i hope to have something
next week.

Comment 43

15 years ago
*** Bug 218729 has been marked as a duplicate of this bug. ***

Comment 44

15 years ago
ok, the output of ntlmdump.exe looks perfectly fine.  what i'd like from folks
is to know what version of SECUR32.DLL you have installed on your WIN98 boxes
that crash.  i have read some reports about various bad versions of that DLL
being installed overtop the good versions.  to check the version, you should be
able to right click on the DLL from within explorer, and select the "properties"
option.  from there a popup window should appear with a tab labeled "version". 
these instructions work on Win2k at any rate, and I unfortunately don't have
access to a Win98 box.

Comment 45

15 years ago
Created attachment 131139 [details]
dumpver: outputs the version of Secur32.dll installed on the system

here's a little program that outputs the version of the secure32.dll that is
installed on your system.  it'd be great to collect the output of this command
on as many different machines as possible, including those machines that crash
and those that do not.	thanks!!

Comment 46

15 years ago



Comment 47

15 years ago
dumpver.exe results: (Win98 and Win98SE default) worked (ran the "Q266772" patch to get it, more info in link below) failed as well



Comment 48

15 years ago
jaciss: awesome!  thank you!  i think the solution is probably then to not use
unicode strings on Win9x.  that should be totally do-able since SSPI provides
both narrow and wide versions of the API.

Comment 49

15 years ago
patch-in-hand =)
Flags: blocking1.5?
Summary: NTLM authenticator cannot be loaded under Win9x (security.dll not found) → NTLM sometimes causes crashes under Win9x
Target Milestone: mozilla1.5beta → mozilla1.5final

Comment 50

15 years ago
Created attachment 131189 [details] [diff] [review]
v3 patch

this should fix the win9x crash.

Comment 51

15 years ago
Comment on attachment 131189 [details] [diff] [review]
v3 patch

note: in my local tree, i changed |result = PR_FALSE| to |result = 0| so the
types match.
Attachment #131189 - Flags: superreview?(bryner)
Attachment #131189 - Flags: review?(dougt)

Comment 52

15 years ago
Wouldn't block the release but we've got a few days left to get this in so
please request approval once the reviews are completed. Thanks.
Flags: blocking1.5? → blocking1.5-

Comment 53

15 years ago
Comment on attachment 131189 [details] [diff] [review]
v3 patch

the IsWin9x() check differs from what msdev suggests. For example this check,
from what i am reading, will also be true for NT.  Take a look here:

Comment 54

15 years ago
dougt: are you sure?  it looks correct to me.  am i missing something?
Attachment #131189 - Flags: superreview?(bryner) → superreview+

Comment 55

15 years ago
Comment on attachment 131189 [details] [diff] [review]
v3 patch

missed the switch.
Attachment #131189 - Flags: review?(dougt) → review+

Comment 56

15 years ago
Comment on attachment 131189 [details] [diff] [review]
v3 patch

please consider this patch for 1.5 final and 1.4.2
Attachment #131189 - Flags: approval1.5?
Attachment #131189 - Flags: approval1.4.2?

Comment 57

15 years ago
Last Resolved: 15 years ago15 years ago
Resolution: --- → FIXED

Comment 58

15 years ago
Comment on attachment 131189 [details] [diff] [review]
v3 patch

a=asa (on behalf of drivers) for checkin to the Mozilla 1.5 branch. Please add
the fixed1.5 keyword when this is landed on the branch. Thanks.
Attachment #131189 - Flags: approval1.5? → approval1.5+

Comment 59

15 years ago
sorry, i forgot to mention that this was checked in on the 1.5 branch.
Keywords: fixed1.5


15 years ago
Blocks: 222849

Comment 60

15 years ago
Comment on attachment 131189 [details] [diff] [review]
v3 patch

a=mkaply for 1.4.2
Attachment #131189 - Flags: approval1.4.2? → approval1.4.2+

Comment 61

15 years ago
Keywords: fixed1.4.2
You need to log in before you can comment on or make changes to this bug.