New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 19 users
Status: WontFix
Owner: ----
Closed: May 2015
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug-Regression



Sign in to add a comment
.localhost wont use hosts file
Reported by tothsa...@gmail.com, May 20 2015 Back to list
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.65 Safari/537.36

Example URL:
anything.localhost

Steps to reproduce the problem:
1. Type your localhost ending dev domain
2. Shows It works (which is the standard stuff)
3. Switch to Firefox and check the locahost ending server up and running

What is the expected behavior?
Uses /etc/hosts to lookup anything.localhost, as the previous version do it.

What went wrong?
I think Chrome wont ue /etc/hosts to lookup localhost ending domains.

Did this work before? Yes Previous version, until this morning.

Chrome version: 43.0.2357.65  Channel: stable
OS Version: OS X 10.9.5
Flash Version: Shockwave Flash 17.0 r0

Please fix it I need to use different browser.
 
Comment 1 by p.ston...@gmail.com, May 20 2015
Looks like this is a feature: https://code.google.com/p/chromium/issues/detail?id=378566
Comment 2 by tothsa...@gmail.com, May 20 2015
LOL This is the silliest feature ever, how can i switch off? All the previous versions are worked, it is so disappointing.
Comment 3 by tothsa...@gmail.com, May 20 2015
I mean to ignore /etc/hosts file for localhosts :) 
Comment 4 by mmenke@chromium.org, May 20 2015
Cc: palmer@chromium.org est...@chromium.org rsleevi@chromium.org mkwst@chromium.org
Labels: -OS-Mac OS-All
Status: Untriaged
Labels: -Pri-2 -Type-Bug Pri-3 Type-Bug-Regression
This is caused by http://crrev.com/322452 as part of  Issue 455825 . This was done as a security mitigation, as OS X's resolver does not properly ensure that .localhost domains are not queried on the network, which is a key security property of ensuring .localhost is truely local. Because we can't trust the resolver to do the secure thing, we unfortunately can't trust the resolver (even when it may be secure)
Labels: -Cr-Internals-Network Cr-Internals-Network-DNS
That said, I should also mention that localhost domains are always expected to resolve to localhost (documented here - https://tools.ietf.org/html/rfc6761#section-6.3 ), so this "regression" is that we are now more compliant.

It is the same way you "shouldn't" be able to change "localhost." to resolve to a non-local IP.
Comment 7 by tothsa...@gmail.com, May 20 2015
I'm not quite understand this, because
http://localhost goes through and give me the dummy / default result
http://anysite.localhost mapped to ( /etc/hosts  192.168.10.10) and give me the localhost's dummy / default result, instead of goes to the server as other browsers do.

If we speak about security risk, why I can reach localhost which (because the default settings) could be more insecure rather than a properly set webserver. Plus why *.localhost resolved with localhost instead of an error message. 

I understand that you disable the access from dammvirus.website.org to *.localhost it makes sense. But why I can't navigate to my local sites in the address-bar and keep myself on same domain?

anyway if it is a feature it is time to leave Chrome because I have not time to set up all my dev servers. It is quite strange to be honest it was an automatic update with braking change and there is no button to revert.
Correct, "anything.whatever.localhost" is all treated as localhost. *.localhost -> localhost. That's what's defined in RFC 6761 - that is, that "localhost." (and subdomains) map to the local loopback

The security risk is not about properly configured server vs improperly configured server. It's that a DNS resolver should never send foo.localhost requests out to the network. If it does, a network attacker could make "foo.localhost" point to any IP of their choosing. This is bad, because "localhost" (and "*.localhost") have special privileges (c.f. http://www.w3.org/TR/powerful-features/#is-origin-trustworthy ), and because they have those special privileges, they need to be secure.

This is nothing about virus.evil.example.org not being able to talk to *.localhost. While Issue 378566 is tracking that, this is not the cause for your issue.

Because of the varying quality of the OS DNS resolvers, before we ask the OS (which is responsible for reading /etc/hosts, as well as sending the actual DNS requests, consulting things like NETBIOS, mDNS, etc) to resolve a domain, we first ensure that the domain is valid according to the rules of DNS. For example, you can't resolve "foo..example.com" (note the two dots), even though for some naming systems, and some OSes, that's "valid".

It's a complex topic, but ultimately, the goal is to ensure a consistent, secure experience regardless of the OS you're using, and a consistent, secure experience that follows the relevant Internet standards. "anysite.localhost" mapping to anything other than a loopback address (127.0.0.1/8, [::1]) is one way to violate those standards, hence why it's no longer allowed.
Comment 9 by tothsa...@gmail.com, May 20 2015
Ok, I never thought that. I was quite happy with Firefox today, so until I got these *.localhost -s I can't use Chrome. Bit annoying but I understand. Thanks
I read these specs and I agree localhost must be just localhost. Thanks guys to explained that! It was a bad surprise. As soon as I got some time I'll move everything out from localhost. Thanks again.
 Issue 490679  has been merged into this issue.
Comment 12 by ericr...@gmail.com, May 25 2015
If there is an OS vulnerability with DNS lookup, it seems like the OS manufacturer should address it rather than an application like Chrome.
For developing and testing purposes I use subdomains on localhost with entries in my hosts file like
127.0.0.1 myapp.localhost
127.0.0.1 sub.myapp.localhost

This worked until Chrome 42.

If this is was a security feature the browser should not go wild and try to reloading this address permanently. It should point out, that it is not willing to connect.

On the other hand, there should not be a problem if myapp.localhost points to 127.0.0.1 

Well for a workaround I changed localhost to something else in my hostst file and everything is nice again.

Only cases were localhost is routed outside should be blocked (with a clear warning - message!)
Re: comment 13: Such a config should work. All *.localhost resolutions should resolve to the loopback address (e.g. localhost). If this isn't working, could you file a new bug and include a net-internals log?

See https://dev.chromium.org/for-testers/providing-network-details for directions.

This only applies for cases where a .localhost domain was routed to the loopback adapter.
Status: WontFix
Just to be explicit - Closing this as a "WontFix" for the "Works as Intended" (or at least, the relevant specs dictate such behaviour is perfectly acceptable, and the alternative is security risky)
Same problem with Ubuntu 15.04.
No problems until Chrome 42.
Comment 17 Deleted
Comment 18 Deleted
Comment 19 by Deleted ...@, Jun 24 2015
i don;t understand if there's security risk, why chrome not just pointing "anything.has.localhost" to local?
Re #19, that is what Chrome does now (resolves foo.localhost to 127.0.0.1).
#20 It would be good, but for me (and maybe for others) it says: ERR_NAME_NOT_RESOLVED. That's why we here.
Comment 22 by Deleted ...@, Jul 3 2015
Just for the record, I had the same problem reported by Comment #13 and I fixed it 
adding "127.0.0.1 localhost." to the /etc/hosts (note the trailing dot) as indicated by @rsleevi in https://code.google.com/p/chromium/issues/detail?id=496479, commment #2.

This change breaks resolution of other loopback addresses:

Hosts file:
127.0.0.100	phpmyadmin.localhost
127.0.0.2	site1.localhost
127.0.0.3	site2.localhost
127.0.0.4	site3.localhost
127.0.0.5	site4.localhost
etc.

Those addresses are valid Loopback addresses on Windows and so should be allowed by Chrome, but it never gets that far.

Re: #23, that should not be the case on ToT. https://chromium.googlesource.com/chromium/src/+/d1bc206e4635403d342e40d6e04845c029f1ada7 checks the hosts file first for local hostnames, and resolves them to 127.0.0.1 if they are not resolved in the hosts file.
I tested on Canary (45.0.2454.6, revision e681ad07907c49ee2f3dda78be0b9f029c806868-refs/branch-heads/2454@{#7}) and I see the same issue.

I attached a screenshot showing the behavior. The default Apache page shows up instead of phpmyadmin because the resolution is not being done.

It is possible something else is going on. If it is being resolved through the hosts file or any other regular method, I would also expect to see it in chrome://net-internals/#dns as well as in chrome://net-internals/#events&q=type:HOST and it is not showing in either place. A copy of the relevant events I do see is attached.
Chrome dot.localhost resolution.PNG
120 KB View Download
Chrome events.txt
3.8 KB View Download
Re #25, thanks, I think I see what's happening. Filed issue 510124 (though unfortunately, at the moment, I'm not sure how we can fix this while still avoiding trusting the system resolver with local hostnames).
Comment 27 by Deleted ...@, Jul 23 2015
Thanks to arieljlira@gmail.com (comment #22) - adding 127.0.0.1 localhost. (with trailing dot) to hosts file fixed the issue for me (Ubuntu).
Cheers
Comment 28 by j...@advomatic.com, Jul 28 2015
Comment #22 also fixed this for me. Thanks arieljlira@gmail.com
Comment 29 by Deleted ...@, Aug 5 2015
I also had this issue, and not the behavior described in #20. The fix in #22 is a sufficient workaround.
Sign in to add a comment