1602034 - Typing 3 numbers separated by . into address bar auto fills to IP address with 0 in 3rd octet

Status: UNCONFIRMED

(Core :: DOM: Navigation, defect, P5)

Description

[paratripper]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0

Steps to reproduce:

When inputting a number into the address bar such as 2.2.2 and pressing return the browser will auto fill and try to reach an IP address 2.2.0.2

This happens with any sequence which appears to be 3 octets therefore can be potentially used to direct people to malicious IP addresses. For example putting http://101.78.146 will go to IP address 101.78.0.146 which has been previously listed as a malicious IP

Actual results:

by entering the number 1.1.1 firefox will try to reach IP address 1.1.0.1

Expected results:

Search results for the number should appear

Comment 1

[:Gijs (he/him)]

This is courtesy of the IPV4 and URL specs, where new URL("http://1.1.1/") behaves this way (ie the .href of that URL is http://1.1.0.1/) - the same thing happens in Chrome with the URL constructor.

It looks like the choice for the address bar was a deliberate decision in bug 1067168, where Olli and I preferred this (standardized) behaviour over the suggestion that users would typo things like this and expect a search. At the time, Chrome also loaded an IP address (cf. bug 1067168 comment 11). It seems Chrome has changed their approach since then.

(In reply to paratripper from comment #0)

http://101.78.146 will go to IP address 101.78.0.146 which has been previously listed as a malicious IP

FWIW, I don't see a safebrowsing warning for either the partial or full IP.

In any case, I don't see why this is a security issue. If an attacker convinces a user to type an IP address in the location bar, they might as well tell the user to put in the full 4 groups of octets. Am I missing something? Why do you think Firefox's behaviour is a security vulnerability?

Comment 2

[paratripper]

From a security standpoint, this just makes it simpler to bypass mail filters and other controls in a a corporate environment when sending phishing links in the form of an IP, not sure how this would directly impact consumers with standard mail types

But if this is the preferred action, would it not be prudent to allow only private rfc1918 addresses as I can't see a use case for going external?

Comment 3

[:Gijs (he/him)]

(In reply to paratripper from comment #2)

From a security standpoint, this just makes it simpler to bypass mail filters and other controls in a a corporate environment when sending phishing links in the form of an IP, not sure how this would directly impact consumers with standard mail types

But links from external sources have a protocol included and are full valid URLs, and at that point there's no search behaviour at all... in any browser, I'm pretty sure... Am I misunderstanding the situation you describe?

Comment 4

[paratripper]

Hi,

For example if I pass through a malicious phishing url, and I am hosting on an IP address there the 3rd octet is missing. I can pass this through mail filters that normally assess the link and will potentially block it.
For example with http://1.2.3/test, Edge and Chrome return search results however Firefox tries to resolve http://1.2.0.3/test

Comment 5

[paratripper]

My mistake, chrome does also try to get the the URL!

Comment 6

[:Gijs (he/him)]

(In reply to paratripper from comment #4)

For example with http://1.2.3/test, Edge and Chrome return search results however Firefox tries to resolve http://1.2.0.3/test

As noted in comment #5, Chrome does just load the URL, and I'd be very surprised if Edge didn't do the same (if it doesn't now, I'd expect it to start when the switch to Chromium is released).

TBH, I think the normalization in question is specced and standardized and the same between browsers, so if this befuddles the mail filter then the mail filter needs fixing. I'm pretty sure (but it's hard to test in practice without an example) that safebrowsing in Firefox/Chrome is going to block based on the final URI, so if the address is malicious we'll block the load either way. Because of all this, I'm going to remove the security flag.

Comment 7

[paratripper]

No problem, I will see if I can get this tested with a mail filter and let you know, as you say more likely an issue with them, also this happens widely with most tools where you can enter an IPV4 address besides browsers.

Thanks for the updates!

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:kmag, could you have a look please?

For more information, please visit auto_nag documentation.