330044 - Crash on NTLM Authentication against an NT4 / IIS4 Server

Status: RESOLVED DUPLICATE of bug 320349

(Core :: Networking, defect, P1)

Description

[Colin Ogilvie [:cso]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060128 Firefox/1.5
Build Identifier: 

When visiting my workplace's internal webserver with NTLM authentication, Firefox crashes.

The internal URL is http://wallace_bdc1/
network.automatic-ntlm-auth.trusted-uris is set to wallace_bdc1
network.ntlm.send-lm-response is set to true

Talkback Incident ID: 16183424

Reproducible: Always

Steps to Reproduce:
1. Visit internal Webserver
2. Crash
Actual Results:  
Firefox crashes, with the previous TB incident idea

Expected Results:  
Firefox logs me

Comment 1

[Colin Ogilvie [:cso]]

Note: This bug occurs on the latest 1.5.0.2 nightly, not the useragent in the initial report; I'm not at work now, so can't file it from there.

Comment 2

[Martijn Wargers (dead)]

From talkback ID:
SECUR32.DLL + 0x37da (0x7f8737da)
SECUR32.DLL + 0x2416 (0x7f872416)
SECUR32.DLL + 0x179a (0x7f87179a)
nsAuthSSPI::GetNextToken  [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/extensions/auth/nsAuthSSPI.cpp, line 357]
nsHttpNTLMAuth::GenerateCredentials  [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/netwerk/protocol/http/src/nsHttpNTLMAuth.cpp, line 348]
nsHttpChannel::GenCredsAndSetEntry  [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp, line 2216]
nsHttpChannel::GetCredentialsForChallenge  [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp, line 2610]
nsHttpChannel::GetCredentials  [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp, line 2411]
nsHttpChannel::ProcessAuthentication  [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp, line 2285]
nsHttpChannel::ProcessResponse  [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp, line 845]

Comment 3

[Christian :Biesinger (don't email me, ping me on IRC)]

hm... this is with win98? looks like bug 320349 to me (the function address is identical); it was minused for 1.5.0.2...

Comment 4

[David :Bienvenu]

see bug 328187 - [e-mail] thinks it was the first patch in there that caused this, so this would be a regression, and one that we should really fix before 1.5.0.2 goes out :-(

Comment 5

[Thorsten Schlichting]

I think the crash is due to a patch for Bug #328187 that makes nsAuthSSPI::GetNextToken() behave like nsAuthGSSAPI::GetNextToken()...

nsHttpNTLMAuth::GenerateCredentials does not expect GetNextToken() to return a
NULL pointer for zero length tokens...

I've created an undo patch that brings back the old behavior. 

Is it possible to use NTLM Authentication with GSSAPI (Kerberos for Windows from MIT)? If so there might be a crash too....

Comment 6

[David :Bienvenu]

Does this mean that NTLM authentication now always crashes FireFox, and that's a regression? If so, it seems like that has to be fixed. One thing I don't get - how is  bug 320349 involved? That was pre your change...

Comment 7

[David :Bienvenu]

Thorsten, are you sure that nsHttpNTLMAuth::GenerateCredentials cares if a null pointer is returned for a zero length result? It looks to me like we'll call PL_Base64Encode with null and 0, which I don't think crashes. I think we're crashing in the call to GetNextToken, not in GenerateCredentials.

Comment 8

[David :Bienvenu]

Colin, have you tried this with 1.5, as opposed to 1.5.0.2, to see if it's really a regression, or simply bug 320349?

Comment 9

[Colin Ogilvie [:cso]]

(In reply to comment #8)
> Colin, have you tried this with 1.5, as opposed to 1.5.0.2, to see if it's
> really a regression, or simply bug 320349?

No, I hadn't tried going backwards - just forwards to see if it still existed in the latest version.

I can check when I go to work on Monday, though. I might get a chance to try it with a 1.8.1 version of Firefox, too.

Personally, I don't know enough to know if it is simply bug 320349 or not, though.

Comment 10

[Thorsten Schlichting]

(In reply to comment #7)
> Thorsten, are you sure that nsHttpNTLMAuth::GenerateCredentials cares if a null
> pointer is returned for a zero length result? It looks to me like we'll call
> PL_Base64Encode with null and 0, which I don't think crashes. I think we're
> crashing in the call to GetNextToken, not in GenerateCredentials.
> 

No, I'm not sure. And you might be right! And even if not, it should crash in PL_Base64Encode() and not in SECUR32.DLL

Comment 11

[David :Bienvenu]

Ok, thx, Thorsten. I'm leaning towards this being a false alarm. It would be great to hear the results of Colin's tests, however.

Comment 12

[Tim Riley [:timr]]

Too late for 1.8.0.2.  We have final bits. "?" for 1.8.0.3.

Comment 13

[Colin Ogilvie [:cso]]

I've just tested in "Mozilla/5.0 (Windows; U; Win98; en-GB; rv:1.8) Gecko/20051111 Firefox/1.5" and it still crashes... TB16342792Q filed, when the Talkback Server gets to it. I', assuming it's the same problem though.

Comment 14

[Colin Ogilvie [:cso]]

Tested on "Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20060313 Firefox/1.6a1" and the NTLM authentication worked fine.

Comment 15

[Darin Fisher]

OK, I'll prepare a diff between branch and trunk and see about backporting relevant bits.

Comment 16

[Darin Fisher]

I'm pretty sure this is a duplicate of bug 320349 given that the crash does not occur on the trunk.

*** This bug has been marked as a duplicate of 320349 ***