Closed Bug 1915982 Opened 3 months ago Closed 2 months ago

isLocalIPv4 should consider 0.0.0.0/8 a local address per RFC1122

Categories

(Core :: Networking: DNS, defect, P2)

Firefox 131
defect
Points:
2

Tracking

()

RESOLVED FIXED
133 Branch
Tracking Status
firefox133 --- fixed

People

(Reporter: maxime+mozilla, Assigned: maxime+mozilla, NeedInfo)

Details

(Whiteboard: [necko-triaged][necko-priority-next])

Attachments

(1 file)

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

Steps to reproduce:

In the Browser Console, execute the following JavaScript:

Services.io.hostnameIsLocalIPAddress(Services.io.newURI(`http://0.0.0.0`))

Actual results:

The Browser Console returns false.

This impacts things like the DoH canary domain (use-application-dns.net) where a 0.0.0.0 response is incorrectly considered positive. As an example, OPNsense's Unbound DNS Blocklist returns by default the local 0.0.0.0 IP for blocked domains 1, which FireFox would fail to consider a negative result.

Expected results:

The Browser Console should return true for any IP within the 0.0.0.0/8 range as per RFC1122.

Currently only the 10/8 prefix (RFC 1918), 172.16/12 prefix (RFC 1918), 192.168/16 prefix (RFC 1918) and 169.254/16 prefix (Link Local) are considered local by isLocalIPv4.

If this bug is considered valid, I would be happy to fix it as a first contribution.

Not that this specific address was likely to change use, but most of RFC 1122 has been updated and obsoleted over the past 35 years. For due diligence I'll note the IANA IPv4 Special-Purpose Address Registry confirms this block still has this meaning.

We will be blocking connections to 0.0.0.0 specifically in bug 1889130, but knowing it's local before we try could help in other cases. And this would be usefully correct for the unlikely case we encounter other 0.0.0.* addresses.

Status: UNCONFIRMED → NEW
Ever confirmed: true

Valentin: is this a change your team would agree with?

Flags: needinfo?(valentin.gosu)

Yes, I think this is something we should consider doing.

Severity: -- → S3
Points: --- → 2
Flags: needinfo?(valentin.gosu)
Priority: -- → P2
Whiteboard: [necko-triaged][necko-priority-next]
Assignee: nobody → maxime+mozilla
Status: NEW → ASSIGNED
Pushed by valentin.gosu@gmail.com: https://hg.mozilla.org/integration/autoland/rev/e45824d07bb5 Consider 0.0.0.0/8 as a local range. r=valentin,necko-reviewers

Backed out for causing xpcshell failures

  • Backout link
  • Push with failures
  • Failure Log
  • Failure line: TEST-UNEXPECTED-FAIL | netwerk/test/unit/test_dooh.js | xpcshell return code: 0
    TEST-UNEXPECTED-FAIL | netwerk/test/unit/test_dooh.js | test_no_retry_without_doh - [test_no_retry_without_doh : 1056] Expecting only one instance of NS_NET_STATUS_RESOLVED_HOST - "undefined" == 1
    TEST-UNEXPECTED-FAIL | netwerk/test/unit/test_trr.js | xpcshell return code: 0
    TEST-UNEXPECTED-FAIL | netwerk/test/unit/test_trr.js | test_no_retry_without_doh - [test_no_retry_without_doh : 1056] Expecting only one instance of NS_NET_STATUS_RESOLVED_HOST - "undefined" == 1
Flags: needinfo?(maxime+mozilla)
Pushed by chorotan@mozilla.com: https://hg.mozilla.org/mozilla-central/rev/4b7aa2d914f7 Consider 0.0.0.0/8 as a local range. r=valentin,necko-reviewers
Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → 133 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: