1557562 - Discussion related to multiple ical bugs

Status: RESOLVED FIXED

(Calendar :: General, defect)

Description

[Kai Engert (:KaiE:)]

Discussion related to bug 1553820, bug 1553814, bug 1555646, bug 1553808.

I've been contacted by Markus Vervier. He is worried about the status of above bugs, and that some information on those issues is already public.

It seems that the above bugs aren't yet close to being solved and fixed in the stable Thunderbird.

Let's discuss the next steps here, that might be better than email.

Markus suggested to:

• open up the above bugs
• set preference calendar.icaljs to true as a workaround

Is using that change to the pref a realistic approach to prevent the security bugs, or could it introduce other problems, e.g. compatibility issues?

Comment 1

[Geoff Lankow (:darktrojan)]

I have bug 1553820 (actually solved that and uncovered something else) and bug 1553808 in progress. Bug 1555646 looks like it will be a straight copy of the upstream changes. With some reviewer support and quick uplifts we could do a release within days.

I'm hesitant to push ical.js on release while it still has big performance issues.

Comment 2

[Magnus Melin [:mkmelin]]

Yeah I don't think either of the suggestions would help. Some of the data may be public by now (not sure how much). Toggling icaljs for this isn't that appealing either.

We should make sure to get ical.js into shape for 76 though.

Comment 3

[Markus Vervier]

Hi,

I wrote a lengthy Email Kay, here is a small recap:

• We did NOT suggest to open up bugs, but instead pointed to the public commits that reveal at least two of bugs fully: https://hg.mozilla.org/comm-central/log?rev=heap+overflow
• We think that either the issues should be fixed by a new release, or at least the general public should know that they have the option to turn on icalJS. Currently anyone using the default config is exploitable by just clicking on a mail. That also means the bugs are wormable (think of an exploit that distributes gets code exec when opening the mail and distributes to the address book)..

Due to the publicly available commits and since we did not have a direct contact for the disclosure process (there was some confusion who is responsible for TB...), the distros mailinglist was notified yesterday. This means we have 14 days from yesterday on until the issues are published and distributions can take care of patching - maybe even implementing the workaround.

Best would be to coordinate directly with https://oss-security.openwall.org/wiki/mailing-lists/distros .

Markus

Comment 4

[u621419]

(In reply to Markus Vervier from comment #3)

Currently anyone using the default config is exploitable by just clicking on a mail.

These bugs trigger with no user interaction.

Comment 5

[Kai Engert (:KaiE:)]

I see all bugs have assigned and reviewed patches.

Geoff, what's the situation from your point of view? Are you confident all issues are fixed? Are any tests required to confirm that they work?

Luis, Markus, what's your suggestion going forward? Can we go ahead and check them in publicly? Please advise your expectations.

IIUC, only a subset of the information has been leaked through the public commits. What should we do about the remaining commits? What commit comment should be used? Simply "bug number, r=reviewer", or anything else?

Comment 6

[Geoff Lankow (:darktrojan)]

To the best of my knowledge the bugs are fixed and don't break any of our tests.

Comment 7

[Jorg K (CEST = GMT+2)]

Let me know when/what to land and with which commit message. Bug 1553820 and bug 1553814 have already landed with descriptive commit messages, the former one got backed out.

Comment 8

[Markus Vervier]

Based on past experience with such fixes we would recommend to do it following order:

1. Assign CVEs
2. Coordinate with the distros mailing list for quick response of downstream
3. Commit fixes (in a private branch if possible)
4. Make a release in the shortest time span possible between commit and new release. It should be no more than a few days max, otherwise you will expose a population of your users to being vulnerable (and attackers monitor commit logs of high profile projects such as Thunderbird and browsers)
5. Publish a security bulletin

Comment 9

[u621419]

Thanks everyone for a great job :)

Comment 10

[Kai Engert (:KaiE:)]

Thanks to everyone at X41 who was involved!