LNA check after connection establishment allows for potential ID sharing

[TimVlummens]

Chrome and Firefox's current implementations (affected versions listed below) appear to enforce LNA after a local connection has been established. Doing LNA checks post-connection allows an adversary to misuse connection handshakes to transmit identifiers from public to local contexts, similar to the Local Mess abuse (https://localmess.github.io). Two working methods are as follows:

TLS SNI-based: The web script sends an HTTPS request to unique_id_1234.localtest.me:8080, which resolves to 127.0.0.1 due to a wildcard DNS record. Because the request uses HTTPS, the browser includes the full hostname in the TLS ClientHello's Server Name Indication (SNI) field. The local server/app listening on 127.0.0.1:8080 can then extract the subdomain from the SNI extension, recovering the embedded data (unique_id_1234) from the raw packet. An Android PoC app printing the SNI field is given below (lna.quest domain has a wildcard DNS record=127.0.0.1):

IP–based: As the whole 127.x.x.x /8 IP range can be used to communicate with localhost, the IP address itself can be used to encode the identifier to be transmitted. For example, the three last octets can be used to embed a unique ID, or multiple requests can be sent to transmit larger payloads in parts. The server can extract the local IP address from the TCP SYN packet using getsockname and decode the characters contained within.

Both methods are tested on Chrome Stable v145.0.7632.77, Firefox Nightly v150.0a1 and Chrome Canary 147.0.7701.0. The SNI-based method triggers a prompt on Firefox Nightly, but no prompt is shown on Chrome Stable or Canary. If a successful connection is established with the server, the permission prompt is triggered on both browsers. However, if a user selects “block” on the prompt, browsers still attempt to establish the connection first. Thus, the adversary can transmit identifiers from public to local via the TCP or TLS handshakes.

A comment in issue #44 notes Chrome’s plan to move the LNA prompt and check before a connection is established. We were wondering if the LNA spec will be updated to align with that change (pre-connection checks and prompts), or whether the exact time of the prompt/enforcement will be left to user agents. Perhaps being more specific would be beneficial for implementation consistency.

Doing the LNA enforcement pre-connection will obviously have a usability cost: for example, requests to sinkholed domains will now trigger LNA prompts, even if there’s no local server/app that would receive the request.

Two “bypasses” we describe above have limitations: they allow for ID sharing, but the adversary may not receive confirmation for the sent payload. DNS Rebinding and similar attacks that require sending HTTP requests are also not possible through these bypasses.

We are happy to share the PoC source code, if it helps any vendors reproduce the problem.

Mostafa Ansar (IP bypass), Stefan van Ieperen (SNI bypass) and the localmess team.

[tresf]

no prompt is shown on Chrome Stable or Canary

Isn't this better tracked as Chromium bug?

The local server/app listening on 127.0.0.1:8080 can then extract the subdomain from the SNI extension

I was under the impression that resolution, categorization, prompt, otherwise, I agree, the spec is worthless. But this really reads like a bug report.

[gunesacar]

But this really reads like a bug report.

This is a fair point and we thought about both options (disclosing to vendors vs. spec editors). However, we finally landed on disclosing here, since one can argue that browsers ' current behavior do follow the current spec, and implementation inconsistencies are a product of undefined behavior. We also wanted to have clarity on whether there are plans to move towards pre-connection checks within the spec.

That said, we'll be happy to disclose to individual vendors, if they prefer that and let us know.

[larseggert]

I think it makes sense to discuss this here, because there is quite a bit of spec-based commonality between the browsers. Where that diverges, it may make sense to have browser-specific discussions, but I think we all try to learn from one another and find a mostly-common good way to deal with this, so even then, to me, a shared discussion makes the most sense.

[christhompson]

Thanks for the demos and the writeup! We (roughly) knew that the current "check permission after connection establishment" had some potential leaks, but we (Chrome LNA team) considered this lower priority than closing the broader security gap in the web platform. The techniques you describe here are clever in that they don't require repeated connection attempts in order to transmit meaningful information, and so are a lot less noisy than what we'd previously been thinking about in this space.

Chromium does plan to move to "check after DNS resolution but before connection establishment", but we don't have a timeline. Our next step here would be to determine what architectural changes we'd need to make to support this -- our current LNA implementation is largely built on top of the prior PNA architecture which was always explicitly post-connection (since it had to make a pre-flight first).

Another open question was whether this could have complicated interactions with things like Happy Eyeballs, where DNS resolution and connection establishment are kind of inherently intertwined (see Issue #7).

A comment in #44 (comment) notes Chrome’s plan to move the LNA prompt and check before a connection is established. We were wondering if the LNA spec will be updated to align with that change (pre-connection checks and prompts), or whether the exact time of the prompt/enforcement will be left to user agents. Perhaps being more specific would be beneficial for implementation consistency.

Yes, it would probably be best for the LNA spec to make this more explicit, if possible. (Actually making this explicit in the Fetch spec is potentially a bit of a challenge ("obtain a connection" is vague, and the actual bits ), but we could at minimum ensure that this is called out as a warning to implementers that they should perform the LNA check before connection establishment.

@MayyaSunil do you know if Firefox has any concerns with trying to move towards applying LNA checks earlier?

no prompt is shown on Chrome Stable or Canary
Isn't this better tracked as Chromium bug?

I think it would be good to also file a Chromium bug so we can track it there, but having the common spec discussion is good for cross-browser collaboration.

[valenting]

@christhompson Firefox is currently not vulnerable to the SNI bypass, due to us prompting after the TCP connection is established, before TLS (we're tracking this in bug 2017712 )
We're supportive of applying the LNA checks earlier - after the TCP connection establishment, or as mentioned in #12 after resolving DNS.

[radansar]

Dear @valenting,
This doesn't align with our test results with the current Beta and Nightly versions. It's true that Firefox prompts after the TCP connection is established, but it doesn't block local connections while waiting for user input, and even if the user chooses "Block" the connection still goes through.

lna-sni.mp4

[ylemkimon]

With link rel="preconnect", it seems the prompt can also be not shown on Firefox. And the existence of preconnect would be another compelling reason to move the check before establishing the connection.

But with all the network prediction, prefetching, and similar speculations, I wonder whether every connection has an initiating origin and can be blocked. Chrome appears to implement a blocking mechanism at the NetworkContext level for Fenced Frame network revocation and Connection Allowlists. This makes me wonder why LNA was not implemented at the same level as well.

[valenting]

Thanks for letting us know. I'll try to fix it ASAP.

[gunesacar]

Issues filed with Chromium and Mozilla, for reference:

• https://issues.chromium.org/issues/490319984 (currently private, since filed as security related; hoping it can be made public after triage)
• https://bugzilla.mozilla.org/show_bug.cgi?id=2021594
• https://bugzilla.mozilla.org/show_bug.cgi?id=2022790 (thanks @valenting)

[ylemkimon]

I think it needs to be decided whether speculation requests are allowed. For navigational speculation, it'd make sense to allow them until #48, but it's not user-visible, so it can be abused.