Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#62974 - [thunderbird] <= 60.7.1: CVE-2019-11707 and CVE-2019-11708, ship "javascript.enabled=false"?

Attached to Project: Arch Linux
Opened by Pascal E. (hardfalcon) - Saturday, 22 June 2019, 11:36 GMT
Last edited by David Runge (dvzrv) - Tuesday, 19 November 2019, 23:02 GMT
Task Type Bug Report
Category Security
Status Assigned
Assigned To Jan de Groot (JGC)
Levente Polyak (anthraxx)
Architecture All
Severity Critical
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 2
Private No

Details

Thunderbird releases before version 60.7.2 are vulnerable to critical CVE-2019-11707 "Type confusion in Array.pop" and high CVE-2019-11708 "sandbox escape using Prompt:Open" according to a security advisory published by upstream:

https://www.mozilla.org/en-US/security/advisories/mfsa2019-20/


Since almost all vulnerabilities in Thunderbird over the last years seem to affect its JavaScript implementation, and since I don't see any good reason why a mail client and RSS feed reader should have JS support enabled by default/out of the box, my suggestion would be to ship the Thunderbird package with the line

pref("javascript.enabled", false);

added to /usr/lib/thunderbird/defaults/preferences/vendor.js.

I've been using Thunderbird with such a configuration for years now both as a mail client and as an RSS feed reader, with a bunch of extensions, and I've never encountered even just a single issue caused by JS being disabled - not when reading mail, not when reading RSS feeds, and not even when using my extensions/addons. And even *if* there should exist some exotic corner case where JS support is actually needed, the users in question could easily enable JS for that specific user profile using Thunderbird's GUI for about:config.
This task depends upon

Comment by loqs (loqs) - Saturday, 22 June 2019, 19:36 GMT
Thunderbird has disabled javascript in message content since version 3 [1].
What is upstream's position on disabling javascript in remote content such as RSS by default?

[1] https://developer.mozilla.org/en-US/docs/Mozilla/Thunderbird/Releases/3
Comment by Pascal E. (hardfalcon) - Saturday, 22 June 2019, 21:02 GMT
Their position hasn't changed, otherwise they would have changed the default for the "javascript.enabled" pref to "false".

"javascript.enabled" is only for the RSS context, whilst the pref for allowing JS in the email context was "javascript.allow.mailnews" - however they completely removed support for JS in the email context (hence also for the "javascript.allow.mailnews" pref itself) starting with Thunderbird 3, so it cannot be enabled for emails even if the user wanted to.
Comment by Michel Koss (MichelKoss1) - Friday, 28 June 2019, 01:08 GMT
General packaging policy in Arch is to stick with what upstream provides. Everyone is free to make their own local modifications
Comment by Pascal E. (hardfalcon) - Friday, 28 June 2019, 06:06 GMT
@MichelKoss1: Whilst in general, I agree with that position, there is precedent where Arch ships a different configuration than upstream's default. The most well-known example for this is probably the imagemagick package, which disables support for PostScript by default:

https://git.archlinux.org/svntogit/packages.git/tree/trunk/IM7-GS-policy.patch?h=packages/imagemagick#n7

Also, note that this is not a compile-time option, but just a changed default setting which users can still change back to Mozilla's default if they so please.
Comment by Michel Koss (MichelKoss1) - Friday, 28 June 2019, 14:26 GMT
I'm aware, imagemagick maintainer is questioning that: https://bugs.archlinux.org/task/62785#comment179558

Users who don't like mozilla default can change it right now as well.
Comment by Pascal E. (hardfalcon) - Friday, 28 June 2019, 16:20 GMT
Upstream's questionable attitude towards IT security shouldn't be an excuse to ship packages with an inherently insecure default configuration.

You may want to have a look at Mozilla's security advisories for Thunderbird:

https://www.mozilla.org/en-US/security/known-vulnerabilities/thunderbird/#thunderbird60.7.2

Of the 11 security advisories from Thunderbird 60.0 to 60.7.2, there has only been a single one (MFSA2019-17 for Thunderbird 60.7.1) which fixed security issues that were *not* caused by JavaScript being enabled "in browser or browser-like contexts". *All* of the other 10 security advisories started with the following note:

"In general, these flaws cannot be exploited through email in the Thunderbird product because scripting is disabled when reading mail, but are potentially risks in browser or browser-like contexts."

Almost the same ratio applies to the 10 security advisories for Thunderbird 52.x - only a single one of them (MFSA2017-30 for Thunderbird 52.5.2) didn't come with the above note, but rather with (among others) a "CVE-2017-7846: JavaScript Execution via RSS in mailbox:// origin":

https://www.mozilla.org/en-US/security/advisories/mfsa2017-30/#CVE-2017-7846

So at the end of the day, the change that I'm requesting would mitigate the security issues which have been the reason for over 90% of Thunderbird updates over the last two major releases, at the cost of potentially requiring a very small number of users to toggle a single about:config flag once for some very exotic use cases. In fact, of the 41 RSS feeds I'm currently subscribed to, there's only a single one that uses JS at all - and that one isn't even a public/free feed, but just the paid RSS feed of golem.de. And even there, JS is only needed if you actually want to play videos and scroll through picture galleries, whilst the rest of the feed works perfectly fine even without JS.
Comment by Michel Koss (MichelKoss1) - Friday, 28 June 2019, 17:11 GMT
Well, for people who don't use browser-like context in TB flipping this setting and related security issues are irrelevant. They are relevant for people who use browser-like context but they would have to flip it back to not lose functionality in first place.

So people for whom this mitigation matter the most are ones who will disable it most likely. I think this isn't worth effort from Arch.

Loading...