Open Bug 577578 Opened 11 years ago Updated 10 years ago

Bad handling of domain names entered in the location box both if it is entered in /etc/hosts file or is completely unreslved

Categories

(Core :: DOM: Navigation, defect)

defect
Not set
normal

Tracking

()

UNCONFIRMED

People

(Reporter: michal.stybnar, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; sk; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6 ( .NET CLR 3.5.30729; .NET4.0C)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; sk; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6 ( .NET CLR 3.5.30729; .NET4.0C)

I tried this only on Windows XP SP3 and Vista Home Premium SP2 (both running on x86), but I think this should apply to all platforms.

I have made three test cases, which are very similar, but with unpredictable, but 100% reproducible behaviour:

1.) if I enter e.g. "abc" in the location box (correct me if there's a more suitable name for it) while it's not in the C:\Windows\System32\drivers\etc\hosts file, it navigates to the ICQ search page! And there's not an easy way to change it to another page (e.g. google) by the way. I would expect Firefox to try e.g. www.abc.com and www.abc.sk before navigating to the search page. At least the second page exists!

2.) another illogical thing would happen, if you enter the following line into the hosts file (the IP should not be accessible this time):
192.168.5.5 abc
The result is, that this time (even though Firefox knows the exact IP address) Firefox times-out and NAVIGATES to the www.abc.sk! It should display a destination unreachable page this time. Even the name "abc" is changed to www.abc.sk in the location box!

3.) same as 2.), but use either sdfa or use abc and disconnect internet. This time Firefox knows again the exact IP address, but will try the www.abc.sk, but this time will not succeed (fortunately). Still it will sometimes overwrite the location (so I cannot simply refresh) and will display a destination unreachable page, but with a wrong address (in this case www.abc.sk or www.sdfa.sk - depending on what you entered).

All test cases where performed on the Slovak regional settings of Firefox, but similar rules should apply in all languages.


Reproducible: Always

Steps to Reproduce:
already written in details
Actual Results:  
already written in details

Expected Results:  
already written in details

Verified with WireShark:

TestCase1) Firefox tries to resolve the "abc" from DNS with no success. Afterwards doesn't try any other possibilities (like www.abc.com) but navigates to search.icq.com directly.

TestCase2) Firefox resolves the www.abc.sk after a time-out and sends an HTTP GET request (navigates to the page).

TestCase3) Navigating to "sdfa". After a time-out Firefox sends a DNS request with www.sdfa.sk, which is acknowledged with "No such name". Firefox displays the destination unreachable page with wrong target name.

I have seen this error first at work, where we use a long hosts file to be able to name the devices we connect to frequently. And if I'm talking about a long list, I mean hundreds of IP addresses.

Other problem may be security risk. Some applications use hosts file to redirect dangerous domain names (fraudulent sites) to localhost (127.0.0.1). If there's no web server running on localhost, Firefox may navigate to that banned site! If this is confirmed, I would like to tag this bug as a HIGH SECURITY RISK! And a real MUST HAVE FIXED!
I tried this with localhost. Now this is funny! It navigates to the www.localhost.sk, which has an IP address: 195.168.3.123

Try and look at it!

LOL

Not so funny with Internet Explorer. ;-)
> it navigates to the ICQ search page!

I believe that would be because that's the first hit when searching for "abc" using your "keyword.URL" preference.

> And there's not an easy way to change it to another page

It's just a preference (though I agree it's not very discoverable).  There are even separate preferences for whether to search at all and what search url to use.

> I would expect Firefox to try e.g. www.abc.com and www.abc.sk

Those do get tried if the error is not a DNS unknown host error, of if keyword search is disabled.

> If there's no web server running on localhost, Firefox may navigate to that
> banned site!

How would that happen, exactly?
> I believe that would be because that's the first hit when searching for "abc"
> using your "keyword.URL" preference.

Thanx, the keyword.URL is indeed: http://search.icq.com/search/afe_results.php?ch_id=afex&q=
I changed it back to default, but it's really cryptic. If you will not mention it, I will never find it. Either way it's still a bug or bad concept. If I enter a string into the Location Bar and there is an IP for that string either via /etc/hosts or DNS, this keyword.URL should never be used!

> > I would expect Firefox to try e.g. www.abc.com and www.abc.sk
> 
> Those do get tried if the error is not a DNS unknown host error, of if keyword
> search is disabled.

I don't understand. If "abc" has an IP address we try to extend it with www. and .sk? Or what? And if so, than why? This should be done, but only in case DNS unknown host error! Not other way round.

> > If there's no web server running on localhost, Firefox may navigate to that
> > banned site!
> 
> How would that happen, exactly?

I did not try it. It was just an idea based on the test cases described in my bug report. The idea is like this:
 1) you will enter e.g. "127.0.0.1 www.google.sk" in hosts file (www.google.sk is now banned). There's no web server running on localhost.
 2) in the Location Bar enter www.google.sk
 3)there may be two or three results:
   - request timeout - error page "Destination unreachable" - this is correct
   - firefox will try www.google.sk via some strange keyword thing and navigate directly to it - this would be a HUGE security risk
   - firefox will try to "extend" the name like this: www.www.google.sk.com and navigate to it. Here probably we will have a timeout again which is correct, but the Location Bar is already overwritten, which is a BUG!

Not tested.

By the way I upgraded to the Firefox 3.6.8 and have problems to reproduce it. Can someone confirm that it is fixed? Or may it be that buggy keyword.URL I changed?

I will try to reproduce it at work (with original keyword.URL) and report the results here if no one will confirm the fix. If it is that keyword.URL, it should be changed. I think, that nobody will look for it into about:config.
> If I enter a string into the Location Bar and there is an IP for that string
> either via /etc/hosts or DNS, this keyword.URL should never be used!

That's right.  It's not.  If you read comment 0, the ICQ thing got loaded when there _wasn't_ an entry in /etc/hosts for the "abc".

> I don't understand. If "abc" has an IP address we try to extend it with www.
> and .sk?

If either "abc" has an IP address and the connection attempt on port 80 fails in certain ways (whatever triggers NS_ERROR_NET_RESET) or has no IP address and keyword fixup was disabled, then we try to extend it with www. and a suffix appropriate to the locale (.sk in your case).  This is to handle the case of servers, for example, which map "www.foo" and "foo" to the same ip but only respond on the www.foo host; these are less common than they used to be, but not unheard-of.

Note that if there's no web server running on the host at all, I would expect NS_ERROR_CONNECTION_REFUSED and no extension to take place.  I guess you were mapping to a random unreachable IP, though, not to an actual host that just has no web server...

> I did not try it.

OK.  ;)

> firefox will try www.google.sk via some strange keyword thing

It will never do this if the hostname resolved to an IP.

> firefox will try to "extend" the name like this: www.www.google.sk.com and
> navigate to it.

Yep, that's a distinct possibility.

> but the Location Bar is already overwritten, which is a BUG!

That's arguably true, yes, if the connection attempt after the fixup fails.  I filed bug 581678.  If it succeeds, obviously the string the location bar shows should change.

> Can someone confirm that it is fixed? 

There were no changes in this code in 3.6.8.

> If it is that keyword.URL, it should be changed.

Which it?

> I think, that nobody will look for it into about:config.

Sure, which is why the default is a somewhat-useful search page...
(In reply to comment #4)

First I want to say that the problem is still reproducible even if I reset the keyword.URL, but this time I tried it with the real server, where the problem appeared in the beginning.

> > I don't understand. If "abc" has an IP address we try to extend it with www.
> > and .sk?
> 
> If either "abc" has an IP address and the connection attempt on port 80 fails
> in certain ways (whatever triggers NS_ERROR_NET_RESET) or has no IP address and

Either or both? Because the word "either" is not really specific. It may mean "one of" or "both". And in my case it should not generate NS_ERROR_NET_RESET (connection established, but no data received). My case would be either 'no connection' at all or 'http error 403 - access denied'. It seems to me, that in both cases Firefox extends the path. Wireshark trace (I know there's a bug in the server - I fixed it already in a new version of that server - but it's not "widespread"):

GET / HTTP/1.1
Host: fpp1_vm
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: sk,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive

403 Forbidden

Access denied! Check access list.
->Wireshark trace end


> keyword fixup was disabled, then we try to extend it with www. and a suffix
> appropriate to the locale (.sk in your case).  This is to handle the case of
> servers, for example, which map "www.foo" and "foo" to the same ip but only
> respond on the www.foo host; these are less common than they used to be, but
> not unheard-of.
> 
> Note that if there's no web server running on the host at all, I would expect
> NS_ERROR_CONNECTION_REFUSED and no extension to take place.  I guess you were
> mapping to a random unreachable IP, though, not to an actual host that just has
> no web server...
> 

I was not "mapping" to a random unreachable IP (at least in the last mentioned case). That server which has this IP is behind a restrictive router with firewall (but port 80 is allowed for me) and the server itself has some sort of "access list" (that's why it returned that "403 Forbidden"). I did not want to be too specific about this case to cover as many faulty case as possible, but it seems to behave a little different in some special cases...

> > I think, that nobody will look for it into about:config.
> 
> Sure, which is why the default is a somewhat-useful search page...

That's right, but in my case the default was changed to "somewhat strange" ICQ search. I don't really know why, but it happened at work and at home and on some other computers as well.

I think it should be changed. The keyword.URL should be changeable via settings - not just about:config. Don't blame me if you don't think so. I'm not a developer of Firefox - just user.
> Because the word "either" is not really specific. It may mean "one of" or
> "both".

"one of" in this case.  

If the server returns a 403 page, we will actually show the 403 page instead of doing any fixup.

> The keyword.URL should be changeable via settings - not just about:config.

That's a user interface issue that should be filed in the Firefox product, not a core bug in the docshell, obviously...
And for what it's worth, "either" when used in an "either ... or ... " construction, as I did, never means "both".
(In reply to comment #6)
> If the server returns a 403 page, we will actually show the 403 page instead of
> doing any fixup.
> 

As I already wrote, there's a bug in the server. It does not reply with "HTTP/1.0 403 Forbidden" as it should, but with "403 Forbidden" only. I'm not sure how it will react if the http header of the reply is correct (I'm at home again and can't test the behaviour now).

I would just expect Firefox to display some sort of error page or the received data (e.g. custom error page from the server) - in this case "Access denied! Check access list.". In the wireshark trace the fpp1_vm is the etc/hosts entry with fixed IP from the 10.0.0.0/8 subnet. Still I remember that there were cases, where I accessed the server during reboot (which may in some cases cause the NS_ERROR_NET_RESET, but even the second one NS_ERROR_CONNECTION_REFUSED if the server didn't started yet) and the "fixup" happened (namely extension with www. and .sk in my case). I do not remember problems in case of non-standard ports (like 81 or 10080). I may attach some more symptoms for these cases as well.

It may be acceptable to try that "fixup", but fall back if it's not successful. Maybe the error is not in the core, but in Firefox itself. I don't know the structure of the application.

> > The keyword.URL should be changeable via settings - not just about:config.
> 
> That's a user interface issue that should be filed in the Firefox product, not
> a core bug in the docshell, obviously...

I agree. Either way keyword.URL is not the main problem here. It's just my "frustration".

:D

Maybe it may be filed as a new bug. I just do not know who changed the default value for me. Was it the installer probably? Or some other application? Doesn't really matter (for me) if it's not causing this problem.

(In reply to comment #7)
> And for what it's worth, "either" when used in an "either ... or ... "
> construction, as I did, never means "both".

Sorry I didn't see that "or". The word "and" was much closer. :D
I'm not a native English speaker. There are some "non-specific" words in English, which I try to avoid normally, to be able to understand each other in the conversation.


P.S.: Can someone confirm the bug? I gave you symptoms from Wireshark (just the "follow tcp stream" portion of it. If you need the whole pcap file, I can attach it tomorrow.
default option for searching from location bar (even attempts to 'guess' incomplete URI) should be off, since this is a security hole. If the user meant to type a URI, they would have made it a FQDN. If they did not put a FQDN there is a good chance it is a result of say copy-and-paste of wrong info into location bar, and then Firefox helpfully tells everyone in the world what it was you were working on when you made the error, perhaps something personal or commercially advantageous.

Please tell me this has never happened to you! I don't believe you.

Yes, the user should have a big, easy to find button that switches this Location Bar search function on if they like it, but since it has a significant security risk, the default should always be the SAFE behaviour. After all, there is the Search Bar for this function, right next door to the Location Bar. I wonder who makes interface decisions like this? I always picture some devious mafioso or blackhat intelligence operative!
You need to log in before you can comment on or make changes to this bug.