2082776 - CardDAV discovery sends supplied password to a different sibling origin

Status: RESOLVED INVALID

(Thunderbird :: Address Book, defect)

Description

[YuYoung Sung]

Attachment: PoC, current-source evidence, xpcshell log, and full technical report

Steps to reproduce

Security-sensitive report. The attached archive contains the complete PoC, current-source evidence, and xpcshell log. All testing used synthetic credentials and local HTTPS servers only.

Test environment

• Thunderbird comm-central: 0254461e6c6ace42ccfe2e430665d9059fe01fac (origin/main, 2026-10-16)
• Official Thunderbird Daily 160.0a1, BuildID 20261015104419
• Windows x64 xpcshell

Reproduction

1. Extract the attached archive and run the included xpcshell manifest as described in README.md.
2. The certificate-valid source https://imap.test.test/source/ returns a DAV current-user-principal href pointing to https://alt.test.test/principals/victim/ without first requesting authentication.
3. The sibling origin challenges with HTTP Basic authentication.
4. Thunderbird sends the configured synthetic CardDAV username and password to that different sibling origin.
5. The sibling returns addressbook-home-set and collection responses, which discovery accepts.

Observed result: Passed: 1, Failed: 0. The source received no Authorization header; the sibling received Basic dmljdGltQHRlc3QudGVzdDpodW50ZXIy ([e-mail]:hunter2).

Affected code paths

• mailnews/addrbook/modules/CardDAVUtils.sys.mjs
• NotificationCallbacks.promptAuth() compares Services.eTLD.getSite(channel.URI) with passwordSite and injects the raw supplied credentials when the eTLD+1 matches.
• detectAddressBooks() follows server-supplied current-user-principal/addressbook-home-set hrefs.

Relationship to Bug 2075859
This appears to be a residual boundary issue after the unrestricted cross-origin CardDAV href fix: unrelated origins are rejected, but any sibling origin within the same registrable domain is still treated as an authorized password site. The report is being filed separately so Mozilla can determine whether to reopen/duplicate the earlier bug.

Actual results

A CardDAV discovery endpoint can cause Thunderbird to disclose the user's supplied CardDAV credentials to a different sibling origin under the same registrable domain. No authentication challenge is required at the original source origin before the server-directed navigation.

This boundary permits a compromised or attacker-controlled sibling host to receive reusable Basic credentials. Depending on credential reuse and server capabilities, the consequence can include unauthorized read/write access to contacts and other resources protected by the same account.

Suggested severity: High / S2
Suggested CVSS 3.1: 7.5 (AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H)
Suggested CWE: CWE-522 (Insufficiently Protected Credentials)

The attack requires the victim to initiate CardDAV discovery against an attacker-influenced source and the attacker to control another host beneath the same registrable domain, so AC:H is used conservatively.

Expected results

Credentials supplied for one CardDAV origin must be sent only to that exact normalized origin (scheme, host, and effective port), unless the user explicitly approves a different destination. Server-provided DAV hrefs may be followed for discovery, but they must not inherit or receive the original credentials merely because their hosts share an eTLD+1.

Comment 1

[Magnus Melin [:mkmelin]]

Using the password for other hosts on the same site during CardDAV discovery is intentional. When bug 2075859 restricted where the password may be sent, same-site was chosen as the boundary on purpose, which is what testDiscoveryPasswordOnSameSite() covers.

DAV discovery regularly hands out principal and address book URLs on another host of the same site than the one the user entered, e.g. contacts.icloud.com pointing to pNN-contacts.icloud.com. Restricting the password to the exact entered origin would break discovery for those setups, and asking for confirmation on every such step would mostly train users to click through it.

For the attack, the attacker needs to get a href of their choosing into a discovery response from the server the user entered, and control another host on that site with a valid certificate, e.g. through a subdomain takeover. If the attacker controls the entered server itself, they can simply ask for the password there, which is what the user intended to use it for. Our assumption is that whoever controls a site controls its subdomains. If that no longer holds, it's a problem the domain owner has to fix; the client can't reliably detect it.

Given that, we consider this working as designed.