2022726 - (CVE-2026-6777) SSRF and DNS hijacking via unvalidated TRR server URL in RecvPDNSRequestConstructor

Status: RESOLVED FIXED

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

Description

[b00rito]

Attachment: report_bug_trr_dns_poison.md

Steps to reproduce:

1. A compromised content process calls SendPDNSRequestConstructor with:
   • aHost = any hostname to resolve (e.g., "example.com")
   • aTrrServer = an attacker-controlled URL (e.g., "https://evil.com/dns-query"
     or an internal address like "https://192.168.1.1/dns-query")
2. The parent/socket process receives the message in
   NeckoParent::RecvPDNSRequestConstructor (NeckoParent.cpp:549-560)
3. The handler passes aTrrServer directly to DNSRequestHandler::DoAsyncResolve
   with no validation

Actual results:

RecvPDNSRequestConstructor performs zero validation on the aTrrServer URL --
no scheme check, no allowlist, no comparison against user-configured TRR URI.
The arbitrary URL flows through to TRR::CreateQueryURI (TRR.cpp:147-164),
which uses it directly as the DNS-over-HTTPS endpoint.

Additionally, nsHostResolver (line 1073-1076) forces TRR_ONLY_MODE when a
custom TRR server is specified, overriding the user's DNS configuration even
if TRR is disabled (network.trr.mode = 0).

This enables:

• SSRF from the unsandboxed parent/socket process to arbitrary URLs including
  internal network addresses (192.168.x.x, 10.x.x.x, 127.0.0.1)
• DNS query exfiltration to attacker-controlled servers
• DNS hijacking for the compromised process's own requests

A related handler, RecvSpeculativeConnect (NeckoParent.cpp:562-588), accepts
an arbitrary nsIURI* and initiates TCP connections from the parent process
without origin validation, enabling port scanning of internal networks.

Expected results:

Content processes should not be able to specify custom TRR server URLs.
RecvPDNSRequestConstructor should reject any non-empty aTrrServer from a
content process with IPC_FAIL, since DNS resolution should use only the
system or user-configured TRR server. If per-request TRR overrides are
needed for some reason, the URL should at minimum be validated against an
allowlist or restricted to the user-configured TRR URI.

Comment 1

[Valentin Gosu [:valentin]]

The custom URL was previously used to do some performance testing of DoH servers other than the default one.
It's only used at DNSLookup.doLookup, and we don't actually run this in release.
We might want to remove this, or otherwise completely ignore the TRR server parameter coming from the content process.

Comment 2

[Valentin Gosu [:valentin]]

Note that even if the attacker process manages to poison the DNS cache via this attack, TLS certificates are still checked properly.

Comment 4

[Valentin Gosu [:valentin]]

Attachment: (secure)

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/ef598a2de8f5
https://hg.mozilla.org/integration/autoland/rev/109fea20f129
Do not allow trrServer in DNS request issued by content process r=necko-reviewers,kershaw

Comment 6

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/109fea20f129