2082775 - Calendar discovery sends supplied password to a different sibling origin

Status: RESOLVED INVALID

(Thunderbird :: Security, defect)

Description

[YuYoung Sung]

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

Steps to reproduce

Security-sensitive report. Full PoC, source evidence, and test log are attached.

Test environment:

• Thunderbird Daily 160.0a1, Build ID 20261015104419
• Official win64 build plus matching Taskcluster test packages
• Current comm-central checkout 0254461e6c6ace42ccfe2e430665d9059fe01fac
• Local synthetic TLS endpoints and credentials only

Reproduction:

1. Run the attached poc_xpcshell.toml with a matching Thunderbird xpcshell environment.
2. The certificate-valid entered origin https://test.test/redirect returns an unauthenticated 302 to https://alt.test.test/capture.ics.
3. The sibling returns a Basic challenge.
4. Thunderbird's real ICS discovery flow retries the sibling with the original username/password.
5. The PoC asserts the entered origin received no Authorization header and the sibling received Basic dmljdGltQHRlc3QudGVzdDpodW50ZXIy (synthetic [e-mail]:hunter2).

Observed: full manifest Passed 3, Failed 0. Direct production-boundary assertions Passed 7/7.

Affected code:

• calendar/base/modules/utils/calProviderDetectionUtils.sys.mjs: getPasswordSite() reduces origins with Services.eTLD.getSite(); isPasswordSite() authorizes all same-site siblings.
• calendar/providers/caldav/modules/CalDavSession.sys.mjs: CalDavDetectionSession.promptAuth() copies the raw credentials after that check.
• calendar/providers/ics/CalICSProvider.sys.mjs: ICSDetectionSession.promptAuth() uses the same boundary.

Relationship to Bug 2077677: this is a residual boundary issue in the current fix, not the already-fixed unrestricted cross-site case. The upstream test testIcsDetectionPasswordRedirectSameSite() confirms sibling sharing remains intentional. Bug 2077677 is restricted, so please mark duplicate if its hidden analysis already covers different sibling ownership.

Actual results

Thunderbird silently sends the calendar username and password entered for one HTTPS origin to a different HTTPS sibling origin. In the attached end-to-end proof, the original origin never sees credentials, while alt.test.test receives the exact Basic credential and discovery succeeds.

Impact: an attacker controlling a certificate-valid sibling subdomain and able to trigger a discovery redirect there (for example, through an open redirect on the intended calendar service plus a dangling sibling record) can harvest calendar credentials. Those credentials commonly permit reading private events and modifying or deleting meetings; some deployments reuse them for other DAV/account services.

Suggested severity: S2 / High. Suggested CVSS 3.1: AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H = 7.5. Suggested CWE: CWE-522. High complexity and user interaction are selected conservatively.

Expected results

Raw credentials entered during calendar discovery should be released only to the exact origin the user entered, with at most a narrowly defined HTTP-to-HTTPS upgrade exception on the same host and port policy. A different host, including a sibling under the same eTLD+1, should receive no Authorization header unless the user explicitly approves that exact destination origin.

Comment 1

[Magnus Melin [:mkmelin]]

Sending the password to other hosts on the same site during calendar detection is intentional. When the password scoping was tightened recently, same-site was chosen as the boundary on purpose, which is what testIcsDetectionPasswordRedirectSameSite() covers.

Calendar detection usually starts from the domain of the email address, or from whatever the user enters, and servers commonly redirect from there to a dedicated host, e.g. from https://example.com/.well-known/caldav to https://dav.example.com/. Restricting the password to the exact entered origin would break detection for those setups, and asking for confirmation on every such redirect would mostly train users to click through it.

The attack needs both a redirect under the attacker's control on the server the user entered (e.g. an open redirect) and a valid certificate for another host on the victim's site, e.g. through a subdomain takeover. 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.