pkasting@ -- this looks quite similar to 47262 so assigning to you to comment.
If a fix is needed, please feel free to assign it to the rightful owner, or assign it back to me.

Maybe we need to 'or' in the DO_NOT_SEND_AUTH_DATA flag when we tell the URLFetcher to try to retrieve the fake target hostnames?
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/intranet_redirect_detector.cc&sq=package:chromium&l=92

It's not clear how big a vulnerability this is, because an attacker in a position to respond to these challenges is likely in a good position to inject a plainhostname reference into any insecure HTML the victim downloads subsequently.

Some additional clarification from me.


The problem with Chrome is that IntranetRedirectDetector removes the necessity to perform MiTM / trick user to click on the plainhostname reference, which is the case with IE. 

1. DNS lookup for plainhostname URL fails
2. NBT-NS queries are being issued (default system configuration)
3. An attacker is able to respond to these queries and capture network credentials, without prompting end-user (IE, Chrome)

Deleted: netbios_settings.PNG 27.2 KB

	netbios_settings.PNG 27.2 KB View Download

Tentatively adding low severity, but feel free to update this if you disagree.

I know nothing about NTLM or NetBIOS, so I'm out of my depth on this bug.

It sounds as if there's some sort of fallback system for name lookup (NBT-NS) that is queried if DNS lookup fails, and the attacker here is in a position to intercept these NBT-NS requests.  If so, isn't this basically a problem as soon as the user does some sort of failed DNS lookup anyway?

Would DO_NOT_SEND_AUTH_DATA actually address the problem here?  I don't know what kinds of auth data that disables.

 #10

True, once user submits any URL for which DNS lookup fails, an attacker will be able to capture his credentials. You just eliminate one step in the attack vector with random URLs requests.
I think proper behavior would be asking user to enter his credentials before submitting them.

If we decide that what we want is DO_NOT_SEND_AUTH_DATA, I can obviously implement that (trivial) CL, but I don't think this should be assigned to me for the decision on whether that's the right thing to do.  Somebody who understands more about these auth systems needs to be making that call.

Eric, can you please take a look or help find an owner.

See the security analysis in  issue 464963 , where this was classified as WontFix.


Regarding comments #5 and #12:

Disabling auth on the IntranetRedirectDetector sounds good to me. I think is a good if for no other reason than code hygiene. From a security perspective though it doesn't solve the inherent weakness of using NTLM over HTTP.

Regarding comment #0:

The attacker is in a position to present themselves as whoever they like over HTTP. So prompting doesn't help much.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4ae1ec3b4d2acbd5ef53a81967619c9e780bbd15

commit 4ae1ec3b4d2acbd5ef53a81967619c9e780bbd15
Author: pkasting <pkasting@chromium.org>
Date: Thu Jun 16 17:20:15 2016

Don't send auth data from IntranetRedirectDetector.

BUG= 606216 
TEST=none

Review-Url: https://codereview.chromium.org/2057213003
Cr-Commit-Position: refs/heads/master@{#400186}

[modify] https://crrev.com/4ae1ec3b4d2acbd5ef53a81967619c9e780bbd15/chrome/browser/intranet_redirect_detector.cc

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot