1492552 - Leading zero in ip address causes connection to unexpected IP due to octal parsing

Status: RESOLVED WONTFIX

(Core :: Networking, defect)

Description

[John K.]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:60.0) Gecko/20100101 Firefox/60.0
Build ID: 20180903060751

Steps to reproduce:

When an IPv4 address is entered with leading zeros, a parsing issue interprets the number as octal and causes the connection to be established to a different ip. 


Actual results:

Example:
Entering 10.0.0.042 in the URL bar connects to 10.0.0.34

Hex works too BTW:
0x0A.0x00.0x00.0x2A


Expected results:

Octal parsing should be removed from the url bar. (And maybe hex for IPv4 too.)

NB: Bug marked as security critical, as there may be a way to exploit this and direct a user to the wrong site.
NB2: Can TLS certificates be affected by this?

Comment 1

[Paul Theriault [:pauljt] (no longer reading bugmail)]

Is this not the expected behavior?  Note that this behavior consistent with link navigation (i.e. its not just the address bar) E,g, document.location = "http://192.0250.1.1" loads http://192.168.1.1

Moving to networking to find someone who is familiar with relevant specs.

Comment 2

[Paul Theriault [:pauljt] (no longer reading bugmail)]

PS As for spoofing risk, at worst I think its probably low. Theres not a lot of trust a user can place in an IP address. And there's plenty of homoglyph attacks already for IP addresses (e.g. http://192.168.1.lOl)

I'm unsure about the answer to the TLS cert question (I dont know how ownership is proven in that case)

Comment 3

[:Gijs (he/him)]

(In reply to Paul Theriault [:pauljt] from comment #2)
> PS As for spoofing risk, at worst I think its probably low. Theres not a lot
> of trust a user can place in an IP address. And there's plenty of homoglyph
> attacks already for IP addresses (e.g. http://192.168.1.lOl)

Yeah, I don't think there's any risk there. Besides, link mouseover tooltips/status bar items are fully spoofable anyway (see discussion in bug 229050).

> I'm unsure about the answer to the TLS cert question (I dont know how
> ownership is proven in that case)

Maybe :keeler or :jcj can weigh in. Can we query crt.sh for this type of thing, and/or do any of the CABforum/Mozilla/ETSI/whatever rules specify how ip addresses must be recorded if they're included in the cert - from a quick look, https://tools.ietf.org/html/rfc3779#section-2.1.1 seems to define they get stored as bit strings, so I don't think any confusion with octets *should* be possible, though what NSS, PKIX, or other implementations do to check them is obviously another matter.


Also, I thought we had a different bug on file about making it impossible to use decimal (ie "5213421" as a representation of an IP) IPs in the address bar, but I can't find it right now.

Comment 4

[J.C. Jones [:jcj] (he/they)]

iPAddress fields are binary, so no worries there.

Encoding an IP as a string dNSName violates the Baseline Requirements, section 7.1.4.2.1, "Subject Alternative Name Extension". This is checked by awslabs' certlint (https://github.com/awslabs/certlint) which is run on CT data via crt.sh. I'm confident there are examples of this sort of mis-issuance, but poking around at the certlint errors of the last week I didn't see any stand out.

(It may be caught by x509lint, too, or instead. Might be a better question for Wayne than for me.)

Comment 5

[Al Billings [:abillings - ex-MoCo]]

Removing from security groups as not a security issue.

Comment 6

[Michal Novotny [:michal]]

I'm not sure what is correct behavior. Chrome does the same, but I found this spec about textual representation of IP addresses: https://tools.ietf.org/html/draft-main-ipaddr-text-rep-02#section-3.1 and IIUC we should probably always assume decimal number and ignore leading zeroes. Daniel, is there some spec saying exactly what we should do?

Comment 7

[Daniel Stenberg [:bagder]]

It's not crystal clear to me what the correct behavior should be.

RFC 3986 section 3.2.2 defined IPv4 address in the URI as "a sequence of four decimal numbers in the range 0 to 255, separated by "." (https://tools.ietf.org/html/rfc3986#section-3.2.2) while the WHATWG URL spec (https://url.spec.whatwg.org/#host-parsing) leaves the numerical base undefined.

ping on my linux machine also parses zero-prefixes as octal:

$ ping 0177.01.01.01
PING 0177.01.01.01 (127.1.1.1) 56(84) bytes of data.

... as does curl:

$ curl 0177.00.00.01 -v
* Rebuilt URL to: 0177.00.00.01/
*   Trying 127.0.0.1...

Comment 8

[Daniel Stenberg [:bagder]]

getaddrinfo() itself does this conversion

Comment 9

[Daniel Stenberg [:bagder]]

This is simply put: working as intended.