2083487 - Cross-site DAV SRV discovery can authorize a new password audience without user confirmation

Status: REOPENED

(Thunderbird :: Address Book, defect)

Description

[Christopher Bohn (Protectstar Inc.)]

Attachment: TB160-N05-V2-FINAL-Bugzilla-Package.zip

• Product: Thunderbird
• Primary component: Address Book
• Joint component: Calendar :: Provider: CalDAV
• Suggested joint triage: Account Hub / Security hardening
• Requested handling: security-sensitive, restricted, and coordinated disclosure

Evidence and current-main status

• Audited-snapshot evidence: B2_STATICALLY_CLOSED / NOT_RUN
• Latest local main status: N05_V2_INTENTIONAL_DELEGATION_DESIGN
• Submission decision: FILE_WITH_RELATED-BUG_CONTEXT
  Impact assessment: the supplied mail password may be selected for Basic authentication at a cross-site SRV target. Final security severity is left to Mozilla. Current code and tests explicitly treat SRV as password delegation, so this report requests security-policy, standards, and compatibility triage rather than claiming that the behavior is accidental.

No runtime reproduction is claimed.

Snapshot identity

The closed A12 evidence was prepared for Thunderbird 160.0a1, comm commit 7138b0613bf9c6413cdc5f2f27e4f843f4f2e02e, with Mozilla platform commit 8014960797439064c025f6bbc6a236558bd4f35f.

The latest local comm recheck used Thunderbird 160.0a1, comm commit c019149b3021a01cb69f7d9300e65bcd80b93cbc, downloaded at 20261018T125222Z as a commit-specific current-main ZIP. It is not a final Thunderbird 160 release or a signed release archive.

Security policy question

May an ordinary DNS SRV answer, without a checked DNSSEC validation or authenticated-data (AD) signal and without a target-specific user decision, authorize reuse of a password already supplied for the mail account at an arbitrary cross-site DAV target?

The proposed security invariant is narrower than disabling SRV: discovery may follow legitimate SRV delegation, but a new cross-site target should not automatically receive the reusable mail password unless an explicit audience policy or authenticated delegation authorizes it.

Preconditions

• Account setup or discovery holds a reusable password in memory.
• DAV discovery starts from the root URL of the email or account domain.
• The consumed _carddavs._tcp or _caldavs._tcp answer selects a target on another registrable site.
• The target has a certificate valid for its own hostname and issues a Basic 401 challenge.
• The account is not passwordless or exclusively using an OAuth path that prevents Basic password selection.
• An attacker can influence the resolver answer, such as through an active DNS/on-path position or compromised DNS delegation. No claim is made that every resolver environment is unauthenticated.

Latest-main CardDAV trace

1. CardDAVUtils.detectAddressBooks() in mailnews/addrbook/modules/CardDAVUtils.sys.mjs enters its DNS branch only when the current URL has a root path and its current hostname is not a key in PRESETS, then queries _carddavs._tcp.<root-host>.
2. It selects the first sorted record and replaces the URL with its unrestricted host and port over HTTPS. TXT can supply a non-root path.
3. For an SRV rewrite, that non-root TXT path is tried first. If it is absent or produces no useful discovery result, the SRV target's /.well-known/carddav URL is tried; the SRV target's root follows if needed.
4. It creates NotificationCallbacks before those probes and derives callbacks.passwordSite from the rewritten SRV URL, not the original URL.
5. The real PROPFIND requests are opened with those callbacks.
6. On the first Basic challenge, NotificationCallbacks.promptAuth() sees the target as the allowed password site, copies the supplied username/password, and returns success.

The CardDAV file is byte-identical between the audit and latest local snapshots.

Latest-main CalDAV trace

1. CalDavProvider.detectCalendars() in calendar/providers/caldav/CalDavProvider.sys.mjs adds the original location's site to a CalDavDetectionSession.
2. For a root URI, its search order reaches dnsSRV() before the original site's well-known and root fallbacks.
3. dnsSRV() selects the first _caldav[s]._tcp record, accepts its host and port, and inserts the selected site's value into session.passwordSites before probing it.
4. An optional non-root TXT path at the SRV target is tried first. If it is absent or yields no calendars, the SRV target's /.well-known/caldav URL is tried; if dnsSRV() still returns no result, the outer sequence continues with the original site's well-known and root fallbacks.
5. The unchanged comment states that the entered domain's DNS records decide where its password may go.
6. CalDavDetectionSession.promptAuth() in CalDavSession.sys.mjs supplies the in-memory username/password when the challenged channel is in passwordSites.

Latest main changed the provider's OAuth dispatch and removed the fifth authMethod parameter, but did not change this SRV audience path. New API documentation expressly says the password is sent to the location site or the server selected by its SRV records.

DNS and redirect boundaries

DNS.srv() and DNS.txt() in mail/modules/DNS.sys.mjs return the worker's ordinary record data. The objects consumed by DAV discovery do not carry a checked DNSSEC validation or authenticated-data (AD) signal, and neither consumer requires authenticated-delegation evidence before adding the selected target to its password audience.

CardDAV separately protects later redirects: an existing Authorization header is copied only when the old and new origins have the same prePath, and a cross-origin redirect with such a header is aborted. That is not a guard on the initial SRV-selected audience.

No provider/session-specific cross-origin redirect sink is visible in the inspected CalDavProvider.sys.mjs and CalDavSession.sys.mjs files. This is not a claim about Necko or modules outside the permitted review scope.

Normal same-site password checks therefore exist. The policy question is how a foreign site becomes authorized in the first place.

Evidence of intentional delegation design

The latest source is not merely missing an accidental check:

• detectCalendars() documents the SRV target as an intended password recipient.
• dnsSRV() states that the entered domain's DNS decides where the password may go.
• The existing Account Hub browser_accountHubSyncAccounts.js maps _carddavs._tcp.imap.test and _caldavs._tcp.imap.test to cross-site example.org:443; local DAV handlers challenge for Basic authentication, and the test expects resources to be discovered.

That is why the precise latest-main status is N05_V2_INTENTIONAL_DELEGATION_DESIGN: the evidence indicates an explicit delegation policy rather than an accidental, undocumented omission.

Strongest design counterargument

RFC-6764-style service discovery and legitimate split-hosting deployments may intentionally locate DAV services outside the mail or identity domain. Current behavior supports that deployment model. A blanket same-site rule or removal of SRV could break valid configurations.

TLS authenticates the selected server, but it does not by itself prove that the resolver answer authorizes reuse of the mail password. The requested remediation is therefore an audience-policy decision: for example, target-specific confirmation, a distinct DAV credential, or an authenticated delegation signal. This report does not prescribe one solution or claim an RFC violation.

RFC 6764 security context

RFC 6764 Section 8 explicitly identifies malicious or spoofed DNS data as capable of directing clients to an attacker-selected server. In the absence of secure DNS, it says clients should check whether the SRV target matches the original service domain and should verify a foreign target with the user before connecting. As an alternative for TLS service discovery, a cross-domain target requires service-identity validation using the SRV-ID rules described through RFC 6125.

The reviewed Thunderbird application path exposes no:

• same-domain requirement for the selected SRV target;
• target-specific user confirmation before the first authenticated request;
• consumed DNSSEC/Authenticated-Data decision;
• application-level SRV-ID audience check before passwordSite or passwordSites is populated.

Normal HTTPS validation of the attacker-selected hostname is valuable but is not, by itself, an authorization decision from the originally queried service domain. This static review did not execute certificate validation and does not exclude an undocumented lower-layer service-identity mechanism; Mozilla should confirm that point during triage.

This standards context strengthens the security-policy question. The report still does not prescribe disabling SRV or breaking legitimate split hosting.

Related public bug context

The following public Bugzilla states were independently rechecked on 18 October 2026:

• Bug 2082775, “Calendar discovery sends supplied password to a different sibling origin,” was public and RESOLVED INVALID.
• Bug 2082776, “CardDAV discovery sends supplied password to a different sibling origin,” was public and RESOLVED INVALID.

The local source comparison confirms this distinction:

Those public reports concerned credential reuse across sibling origins or server-supplied redirects/DAV hrefs within one registrable site. This report concerns an unauthenticated DNS SRV answer selecting the initial credential audience, potentially on a different registrable site.

That difference identifies a distinct producer, allowlist transition, initial sink, and likely minimal fix. It does not decide duplicate status. The supplied INVALID states do not establish that Mozilla evaluated this cross-site SRV producer or approved the current design. Please perform explicit merge/split/duplicate/design triage.

Narrow impact

Under the stated conditions, the reusable password supplied to DAV discovery can be selected for Basic authentication at a certificate-valid site chosen by ordinary cross-site SRV data. The affected consumers are CardDAV and CalDAV discovery. This does not establish that the password is valid for any other service or that every account and DNS environment is affected.

Regression-test attachments

The A12 package proposes CardDAV and CalDAV xpcshell tests plus a supplementary Account Hub skip/abort browser test. They use synthetic names, local routing, exact sentinel equality, real product callbacks, positive and negative controls, fixed deadlines, and complete cleanup.

The combined A12 patch is Anpassung erforderlich / NOT_RUN for latest main:

• the CardDAV core test remains conceptually and API compatible;
• the CalDAV core audience oracle remains relevant, but its fifth authMethod argument is now ignored and its OAuth-only control is invalid under the new dispatch architecture;
• the Account Hub abort test remains conceptually compatible in the inspected unchanged harness, but is supplementary and must not be conflated with the SRV audience-policy core;
• the combined patch must not be submitted unchanged. A12.1 deliberately does not rewrite it.

Expected secure-policy result: a cross-site SRV target can be discovered, but receives no supplied mail-password sentinel until the selected policy authorizes that audience.

Static prediction for the current design: the SRV target is added to passwordSite or passwordSites, and its first Basic challenge can select the supplied password.

Suggested remediation invariant

Preserve legitimate SRV discovery while separating endpoint discovery from credential-audience authorization. Before a reusable mail password is selected for a new cross-site target, require an explicit target-specific decision, a distinct credential flow, or an authenticated delegation policy. Keep existing redirect guards and thread cancellation into active DAV channels independently of the core audience decision.

Non-claims

• No runtime reproduction or actual credential transfer is claimed.
• The related public bugs are cited only for triage context; this report does not claim their private scope or final disposition.
• No duplicate, non-duplicate, CVE, bounty, novelty, Mozilla severity, affected release range, or first-fixed-version claim is made.
• RESOLVED INVALID is not presented as security or design approval.
• No claim is made that DNS is universally unauthenticated or that DNSSEC-validating deployments behave identically. The report identifies an apparent gap relative to RFC 6764's cross-domain SRV safeguards and asks Mozilla to confirm the complete certificate-validation path.
• No TLS bypass, OAuth compromise, code execution, or universal password reuse is claimed.

Credit and disclosure request

Preferred credit: Christopher Bohn (Protectstar Inc.).

Please keep this report restricted, coordinate disclosure with the reporter, and perform explicit policy and duplicate triage against bugs 2082775 and 2082776. Nothing in this package has been submitted or sent.

Comment 1

[Magnus Melin [:mkmelin]]

Attachment: Bug 2083487 - Ask for the password for DAV servers on another site during discovery. r=jtracey

When an SRV record points CardDAV or CalDAV discovery to a server on another
site than the entered domain, prompt for the password naming that server
instead of using the given one. Servers on the same site, such as
dav.example.com for example.com, are unaffected.

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/091dd88032bb
Ask for the password for DAV servers on another site during discovery. r=jtracey

Comment 3

[Kai Engert [:KaiE:]]

this introduces a new test failure:
TEST-UNEXPECTED-TIMEOUT | comm/mail/test/browser/account/browser_accountHubAbRemote.js | application timed out after 370.0 seconds with no output

I'll backout and reopen.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/10b5e74aeb79
Revert "Bug 2083487 - Ask for the password for DAV servers on another site during discovery. r=jtracey" for causing a test failure in browser_accountHubAbRemote.js

Comment 5

[Magnus Melin [:mkmelin]]

Attachment: Bug 2083487 - Follow-up: Use a saved login before asking for the password for a CalDAV server on another site. r=jtracey

During calendar detection, use a login saved for the origin and realm of a
server on another site, instead of asking for the password. Only remove logins
saved during detection when they fail, and only after saving them has
finished. Don't save an empty password, and log save errors.