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

description

- 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.