Intent to Deprecate and Remove: 0.0.0.0 for Private Network Access

[David Adrian]

Contact emails

l...@chromium.org

Explainer

None

Specification

https://wicg.github.io/private-network-access

Summary

We propose to block access to IP address 0.0.0.0 in advance of PNA completely rolling out. Chrome is deprecating direct access to private network endpoints from public websites as part of the Private Network Access (PNA) specification (https://developer.chrome.com/blog/private-network-access-preflight/). Services listening on the localhost (127.0.0.0/8) are considered private according to the specification (https://wicg.github.io/private-network-access/#ip-address-space-heading). Chrome's PNA protection (rolled out as part of https://chromestatus.com/feature/5436853517811712) can be bypassed using the IP address 0.0.0.0 to access services listening on the localhost on macOS and Linux. This can also be abused in DNS rebinding attacks targeting a web application listening on the localhost. Since 0.0.0.0 is not used in practice (and should not be used), but was overlooked during https://chromestatus.com/feature/5436853517811712, we're deprecating it separately from the rest of the private network requests deprecation. This will be a Finch (experimental) rollout, rather than a Developer Trial.

Blink component

Blink>SecurityFeature>CORS>PrivateNetworkAccess

Search tags

security, Private Network Access

TAG review

None

TAG review status

Not applicable

Chromium Trial Name

PrivateNetworkAccessNullIpAddressAllowed

Origin Trial documentation link

https://crbug.com/1300021

WebFeature UseCounter name

kPrivateNetworkAccessNullIpAddress

Risks

Interoperability and Compatibility

None

Gecko: Closed Without a Position (https://github.com/mozilla/standards-positions/issues/143)

WebKit: Support (https://github.com/WebKit/standards-positions/issues/163)

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Goals for experimentation

Ongoing technical constraints

Eventually, all private network access will be limited according to the developing Private Network Access spec.

Debuggability

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

No

Flag name on chrome://flags

block-null-ip-address

Finch feature name

PrivateNetworkAccessNullIpAddress

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1300021

Estimated milestones

Shipping on desktop	133
Origin trial desktop first	127
Origin trial desktop last	133
DevTrial on desktop	127

Shipping on Android	133
OriginTrial Android last	133
OriginTrial Android first	127
DevTrial on Android	127

Shipping on WebView	133
OriginTrial webView last	133
OriginTrial webView first	127

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5106143060033536

This intent message was generated by Chrome Platform Status.

[David Adrian]

Chrome Status doesn't generate emails for the deprecation trails, only developer trials, so I've repurposed that here. This is a Finch managed rollout, not a developer opt-in, due to the extremely low usage that seems to be almost entirely malware.

[Vladimir Levin]

On Mon, Jun 3, 2024 at 12:06 PM 'David Adrian' via blink-dev <blin...@chromium.org> wrote:

Chrome Status doesn't generate emails for the deprecation trails, only developer trials, so I've repurposed that here. This is a Finch managed rollout, not a developer opt-in, due to the extremely low usage that seems to be almost entirely malware.

Can you please elaborate on the analysis: how low is the usage and how did you check that the use is malware?

Also, just to confirm, this is an intent to deprecate and remove but you're planning on rolling out the removal gradually via finch, right?

Thanks!

Vlad

 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42%2BQKMO3O3dgP-pRY-44xypbZ1CPsfiFjDGwcdrU0w0JqA%40mail.gmail.com.

[David Adrian]

> Can you please elaborate on the analysis: how low is the usage and how did you check that the use is malware?

The Blink.UseCounter.Feature for PrivateNetworkAccessNullIpAddress shows below 0.001% on all platforms.

We've had multiple reports of malware leveraging this to attack specific developer tooling frameworks, e.g. https://crbug.com/40058874.

> Also, just to confirm, this is an intent to deprecate and remove but you're planning on rolling out the removal gradually via finch, right?

Correct.

[Kagami Rosylight]

> Gecko: Closed Without a Position (https://github.com/mozilla/standards-positions/issues/143)

It looks like it's closed with position: "worth prototyping", though? Or is there another issue that is closed without position?

[Mike Taylor]

On 6/4/24 6:26 AM, 'Kagami Rosylight' via blink-dev wrote:

> Gecko: Closed Without a Position (https://github.com/mozilla/standards-positions/issues/143)

It looks like it's closed with position: "worth prototyping", though? Or is there another issue that is closed without position?

I can see why that's confusing - it's labelled as "proposal appears stale", but if you follow the linked PR https://github.com/mozilla/standards-positions/pull/480 you can get to the actual resolution.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1b0415c6-7195-4d70-b698-f8ec245e5796n%40chromium.org.

[Jeffrey Yasskin]

The text in the default Intent email is derived from the position issue's labels, and https://github.com/mozilla/standards-positions/issues/143 was closed before the Mozilla folks had created the labels we're looking for. We don't have great help text in Chrome Status to help feature owners figure that out, but folks can either edit the text before sending, link to the published position itself (https://mozilla.github.io/standards-positions/#cors-and-rfc1918) if one exists, or ask the Mozilla (or WebKit or TAG) folks to add a label.

Jeffrey

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/de789612-cb7b-46fb-8b8a-03fcaf5bb4f9%40chromium.org.

[Daniel Bratell]

Can you please start (or possibly N/A) the Privacy/Security/Enterprise/Debuggability/Testing pills in Chromestatus?

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42KD_M%3DuYi%3DV4xusJg34EfGavVxpbHoOTQCj5UyxTeu0Uw%40mail.gmail.com.

[David Adrian]

> Can you please start (or possibly N/A) the Privacy/Security/Enterprise/Debuggability/Testing pills in Chromestatus?

I believe it already has all the pils approved.

[Daniel Bratell]

If so, it's not visible to me. They are all shown as grey, i.e. not started. Is there maybe more than one chromestatus entry and the review was done somewhere else?

/Daniel

[Jason Robbins]

I think this hit a chromestatus bug.   A deprecation should start with approvals of the plan stage, including 3 votes from API Owners.  This was incorrectly detected by chromestatus as a thread about the ship stage, which comes later.

I have voted "review started" to get the "plan" stage API review gate to appear on the reviewers' dashboard.  That stage already has 2 of the need cross-functional reviews approved and one pending.  I'll reset the "Ship" gate so that it can be used later.

I'll fix the underlying parsing bug today.

Thanks,

jason!

[David Adrian]

Ah, I got them on the "Write up plan" stage accidentally. Also, you are correct that Debuggability has not responded yet and was still Blue. My apologies.

Should I ask for approvals on a different stage? None of the stages on Deprecations seem to match an Intent to Deprecate, rather than a Developer Trial or a traditional original trial.

[Jason Robbins]

Sorry, the ChromeStatus labels for things are a little out of sync with the launching-features documentation at the moment.   I believe that you are on this step of the process:

https://www.chromium.org/blink/launching-features/#deprecate

Which corresponds to the "Write up plan" stage in chromestatus.

At a high level, the deprecation process is intended to be front-loaded with the most scrutiny and coordination happening during the planning stage.  

Thanks,

jason!

[Daniel Bratell]

LGTM1

/Daniel

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42L-7xt9YY-jmq-G4-nuitqELpgqgnvECkbCoPpAWWMMjw%40mail.gmail.com.

[Yoav Weiss (@Shopify)]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/683cadae-9413-4125-9209-4ecfe1b812aa%40sarasas.se.

[Vladimir Levin]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSLHTiP3%2BEjLdMVnDK%3DD88Zixa_gDaHoS8t9MxoTTzP6Ow%40mail.gmail.com.