259854 - entering incorrect password on Win2003 IIS website with Integrated Windows Authentication causes infinite loop of auth attempts

Status: RESOLVED DUPLICATE of bug 261044

(Firefox :: General, defect)

Description

[Erik Knepfler]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10

Accessing a Windows 2003 / IIS website that is configured as not anonymous,
using only Integrated Windows Authentication, and entering invalid credentials
causes FireFox to loop indefinitely and spam the server with authentication
attempts.

Reproducible: Always
Steps to Reproduce:
1.  Configure a Windows 2003 / IIS website as not anonymous, using only
Integrated Windows Authentication.  
2.  Access it with Firefox 1.0 PR.  
3.  If you enter valid credentials accessing this site, everything is fine.  
4.  However, invalid credentials causes FireFox to wait indefinitely.
Actual Results:  
Firefox froze, seemingly trying to load the page forever, waiting for a server
response.  This lasted more than an hour.  Packet Capture on the server shows a
repeating loop of authorization attempts.

Expected Results:  
Mozilla and IE properly recognize the Access Denied messages coming from the
server, stop accessing and pop up another user/password input dialog, and no
more packets are logged to the server after the first couple of authentication
packets.

The bug may happen with Win2000 but only tested on Win2003.  The webserver in my
test is part of an Active Directory domain.

I consider this severe because it heavily spams the server with packets.

Comment 1

[Andy Townsend]

This looks similar to the proxy access problems reported elsewhere.  I'm seeing
it accessing a web site on a Windows 2000 Server running IIS 5.

Every page (although not, I don't think, "every page element" - might be every
frame?) causes a username / password box to appear.  Pressing "escape" causes
the box to go away and reappear at the next click (that would load another
page).  Older versions of Firefox (before 1.0PR) did not do this - after
pressing escape the prompt would not reappear.

Entering a valid login causes the box not to be displayed again - I'm guessing
it's using the entered details.

Entering an INVALID login is more interesting.  No prompt re-appears, but a
large amount of network traffic to the http port on the web server does occur
(observed using tcpdump on a router between the two).  Navigate away from the
problem web site and this traffic does not stop.  Close the browser, and it does.

Client is Windows 2000 Pro running Firefox 1.0PR.

Comment 2

[Andy Townsend]

Actually, this sounds like a duplicate of 256949 to me (but I don't have a
chance to do a Windows build of either Firefox or Mozilla currently, so aren't
in a position to test the patch there).

Comment 3

[Tim Cain]

This bug is a regression in 1.0PR, the problem did not occur in .0.9.3.  In my
case I am using NTLM authentication.  This is a severe problem where in my case
the browser attempted authenticaion repeatedly with bad credentials (i.e. a
mis-typed password) until the Windows domain controller disabled my account (in
the active directory).

What I see in tcp/ip packet traces appears to be a loop containing:
1) and HTTP get request for a page requiring authentication
2) server returns 401-error with "WWW-Authenticate: Negotiate" and
"WWW-Authenticate: NTLM"
3) browser resubmits get request with "Authorization: NTLM
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\n" 
4) server returns same error as #2
5) browser resends get request with "Authorization: NTLM
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\n"
I believe the two passes with different authentication information is probably
for NTLM-hash and NTLMV2-hash?
After this process the loop repeats at step 4 indefinitely.  If the user presses
the STOP button, the browser recovers.

But of course, Windows authentication will most likely have disabled the
offending user account.  Argh!

Comment 4

[:Gavin Sharp [email: [e-mail]]]

This is likely the same as bug 259344, which also seems to be a regression in 1.0PR.

Comment 5

[Darin Fisher]

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