2087943 - iTIP REFRESH handler sends full calendar event data to attacker-controlled recipients via spoofed ATTENDEE

Status: RESOLVED FIXED

(Calendar :: E-mail based Scheduling (iTIP/iMIP), defect)

Description

[Ibrahim Alghamdi]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/155.0.0.0 Safari/537.36

Steps to reproduce

ummary: iTIP REFRESH handler sends full calendar event data to attacker-controlled recipients via spoofed ATTENDEE

------- Description -------

The iTIP REFRESH handler extracts attendee addresses from the incoming REFRESH message (attacker-controlled) rather than from the locally stored calendar event. When the organizer clicks "Reconfirm", Thunderbird sends the full event details — all attendees' emails, organizer info, location, description, and any confidential notes — to the attacker-supplied email address with AUTO response mode (no send confirmation prompt).

=== ROOT CAUSE ===

File: comm/calendar/base/modules/utils/calItipUtils.sys.mjs:1762-1785

case "REFRESH": {
  // Line 1764: Attendees extracted from INCOMING message (attacker-controlled)
  const attendees = itipItemItem.getAttendees();
  // NOT from the stored calendar item (this.mFoundItems)
  ...
  if (attendees.length > 0) {
    const action = function () {
      ...
      // Line 1777: Full event sent to attacker-supplied attendees
      sendMessage(
        item,          // The REAL stored event with all its data
        "REQUEST",
        attendees,     // From attacker's REFRESH message
        { responseMode: Ci.calIItipItem.AUTO }  // No confirmation prompt
      );
    };
    operations.push(action);
  }
}

=== ATTACK SCENARIO ===

1. Attacker discovers or guesses a calendar event UID (from a forwarded invitation, shared calendar, or predictable UID pattern)
2. Attacker crafts an iTIP REFRESH email:

   METHOD:REFRESH
   UID:[e-mail]
   ATTENDEE:mailto:[e-mail]
   

3. Attacker sends this email to the event organizer
4. Organizer sees a "Reconfirm" button in the invitation bar and clicks it
5. Thunderbird's REFRESH handler extracts [e-mail] from the incoming REFRESH message (line 1764)
6. sendMessage() sends the FULL calendar event (from local storage) as a REQUEST to [e-mail] with AUTO mode (no send dialog)
7. Attacker receives the complete event: all real attendees' emails, description, location, attachments, and private notes

=== STEPS TO REPRODUCE ===

1. Create a calendar event with multiple attendees and sensitive description content
2. From an external account, send an iTIP REFRESH email to the organizer with the event UID and ATTENDEE:mailto:[e-mail]
3. In the organizer's Thunderbird, open the REFRESH message
4. Click "Reconfirm" in the invitation bar
5. Monitor the attacker mailbox — the full event details arrive as a REQUEST

Actual results

=== ACTUAL RESULTS ===

The attendee list is taken directly from the incoming REFRESH message. Any email address supplied by the attacker receives the full event data when the organizer clicks "Reconfirm".

=== IMPACT ===

• Information disclosure of sensitive calendar data (meeting details, attendee lists, locations, descriptions)
• Attacker needs only a valid event UID (often predictable or leaked via forwarded invitations)
• Single click by the organizer triggers the leak
• AUTO response mode bypasses any send confirmation dialog
• Useful for social engineering, competitive intelligence, or targeted attacks

=== SUGGESTED FIX ===

In the REFRESH handler, use the stored event's attendee list instead of the incoming message's attendees:

case "REFRESH": {
  // Use attendees from the STORED item, not the incoming message
  const attendees = item.getAttendees();
  // Alternatively, verify that incoming attendees are already in the stored event
  ...
}

Affected: Thunderbird 153.4.0 ESR and all versions sharing this code.

Expected results

=== EXPECTED RESULTS ===

The REFRESH handler should send the event only to attendees listed in the STORED calendar event, not to addresses supplied in the incoming REFRESH message. Alternatively, it should prompt the organizer to confirm the recipient list before sending.

Comment 1

[Hartmut Welpmann [:welpy-cw]]

Confirmed the core disclosure on current main using a local xpcshell reproduction.
A stored event contained two legitimate attendees and confidential event details. An incoming REFRESH supplied the same UID but named an outsider absent from the stored attendee list. The incoming sender also differed from that recipient.
Processing offered Reconfirm. Executing the normal action handler generated a REQUEST addressed to the outsider, containing the stored description, location, comment, both legitimate attendee addresses, and an attachment URL. The outgoing message used AUTO response mode despite the incoming item starting in USER mode. The final mail-send call was intercepted; no message was delivered.
This requires knowledge of a valid event UID and user interaction; opening the message alone does not send a response. The report’s claims about predictable UIDs and disclosure of all local metadata are not established.
RFC 5546 §6.1.6 explicitly identifies replies to REFRESH requests from non-attendees as a security concern.
Recommend security triage, provisionally S2. The recipient-handling pattern exists in the November 2008 implementation from bug 457203, so this appears longstanding.
A fix should validate the requester against the stored event and reply only to the authorized attendee, rather than broadcast to every stored attendee. The claimed ESR version remains unverified.

Comment 2

[Magnus Melin [:mkmelin]]

Opening up. Guessing the id isn't really practical.

Comment 3

[Magnus Melin [:mkmelin]]

Attachment: Bug 2087943 - Only answer iTIP REFRESH requests from attendees of events the user organizes. r=welpy-cw

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/384d5a725ab0
Only answer iTIP REFRESH requests from attendees of events the user organizes. r=welpy-cw,tobyp