Thanks for the report.

rsleevi: could you please help triage this? 

Assigning low severity for now because this doesn't seem more dangerous than a user navigating to a hostname directly, which could happen in any number of ways. But I don't know enough of the nuances :) 

Similar to Issue 479620 with the well-known NTLM shortcoming on top.

I'm in meetings all day today/tomorrow, so roping in asanka@ and pkasting@. My recollection of the code is it does not allow the vector described because we don't allow transparent auth for the DNS hijacking detection, but asanka@ and pkasting@ would know precisely.

 Issue 606216  cleaned up the sending of credentials in the IntranetRedirectDetector code used for DNS hijacking detection.

I think in this report, the attacker isn't targeting those IntranetRedirectDetector requests; he instead just generates a phony DNS response for a single word query (e.g. he pretends there's an intranet server named "BASEBALL" and if your browser tries to connect to that, the authentication dance happens).

If Windows considers the target server as being part of the intranet, when Chrome will respond to authentication using ambient credentials. This unfortunately makes this a realistic attack.

A mitigation would be to use DO_NOT_SEND_AUTH_DATA load flag when making this kind of speculative requests. If the user actively visits a rogue server that the local machine is configured to treat as part of the intranet, then it won't help.

The concern here would be if setting DO_NOT_SEND_AUTH_DATA causes target servers to respond differently.  For example, if a server without auth data replies with 401 and with auth data 200.  In this case, setting this bit will cause us to not detect such servers as valid intranet navigations, which is intensely frustrating to users.

If this isn't possible (even with badly configured servers), or if the possible set of replies is such that we can say "401 means the server exists and we should prompt to navigate" or similar, then we could set this bit.

Is anything done on this issue? When will there be a fix?

Issue 719473 has been merged into this issue.

Looking at chrome_omnibox_navigation_observer.cc, looks like it's already considering 401 as meaning the host exists. I'll upload a CL to prevent these requests from performing an auth handshake.

https://twitter.com/zerosum0x0/status/958890437837692928
Now i think this bug is public...

Removing view restrictions as this issue is public.

http://blog.kleissner.org/?p=842 has a workaround for disabling NetBIOS over TCP/IP on Windows, which should prevent NBNS leaks.

It also says "Because NetBIOS over TCP/IP is so insecure, (in case of those NetBIOS broadcast requests) literally anyone on your local network can reply to the NetBIOS message and claim to resolve the queried name. They can return an IP address they control and where they run for example a web-server with an exploit pack on it, or display a website which tries social engineering (“please enter your credentials here..” or “please download this update or install this plugin”)."