Opened 7 years ago
Closed 7 years ago
#13004 closed enhancement (fixed)
thunderbird-68.4.1 (0 day fix similar to Firefox)
| Reported by: | Owned by: | Douglas R. Reno | |
|---|---|---|---|
| Priority: | highest | Milestone: | 9.1 |
| Component: | BOOK | Version: | SVN |
| Severity: | critical | Keywords: | |
| Cc: |
Description
Source has now appeared, but no release notes yet. Maybe this picks up the same fix as for yeasterday's firefox releases, or maybe they are just keeping in sync and had not got 68.4.0 ready.
Please, whoever does this, can we have an accurate measurement of the disk build space using the version of rustc which is in the book ?
Change History (9)
follow-up: 2 comment:1 by , 7 years ago
comment:2 by , 7 years ago
Replying to bdubbs:
Replying to ken@…:
Please, whoever does this, can we have an accurate measurement of the disk build space using the version of rustc which is in the book ?
I can do that, but how do I count the 640M that is already in ~/.cargo?
Good question. For firefox when I last checked, the space used for *extra* cached cargo files seemed to be minimal (I guess most of them are already present for the version of rust being used, the rust files shipped within firefox don't seem to add to the cache), so I ignore them.
comment:3 by , 7 years ago
Thunderbird (and JS60 for that matter) are affected by the 0-day. 68.4.0 was skipped, 68.4.1 has 7 total security fixes and a host of other bug fixes. I can handle the JS60 update.
Mozilla Foundation Security Advisory 2020-04
Security Vulnerabilities fixed in Thunderbird 68.4.1
Announced
January 10, 2020
Impact
critical
Products
Thunderbird
Fixed in
Thunderbird 68.4.1
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.
#CVE-2019-17026: IonMonkey type confusion with StoreElementHole and FallibleStoreElement
Reporter
Qihoo 360 ATA
Impact
critical
Description
Incorrect alias information in IonMonkey JIT compiler for setting array elements could lead to a type confusion. We are aware of targeted attacks in the wild abusing this flaw.
References
Bug 1607443
#CVE-2019-17015: Memory corruption in parent process during new content process initialization on Windows
Reporter
Thomas Imbert
Impact
high
Description
During the initialization of a new content process, a pointer offset can be manipulated leading to memory corruption and a potentially exploitable crash in the parent process.
Note: this issue only occurs on Windows. Other operating systems are unaffected.
References
Bug 1599005
#CVE-2019-17016: Bypass of @namespace CSS sanitization during pasting
Reporter
Michał Bentkowski
Impact
high
Description
When pasting a <style> tag from the clipboard into a rich text editor, the CSS sanitizer incorrectly rewrites a @namespace rule. This could allow for injection into certain types of websites resulting in data exfiltration.
References
Bug 1599181
#CVE-2019-17017: Type Confusion in XPCVariant.cpp
Reporter
bo13oy
Impact
high
Description
Due to a missing case handling object types, a type confusion vulnerability could occur, resulting in a crash. We presume that with enough effort that it could be exploited to run arbitrary code.
References
Bug 1603055
#CVE-2019-17021: Heap address disclosure in parent process during content process initialization on Windows
Reporter
Thomas Imbert
Impact
moderate
Description
During the initialization of a new content process, a race condition occurs that can allow a content process to disclose heap addresses from the parent process.
Note: this issue only occurs on Windows. Other operating systems are unaffected.
References
Bug 1599008
#CVE-2019-17022: CSS sanitization does not escape HTML tags
Reporter
Michał Bentkowski
Impact
moderate
Description
When pasting a <style> tag from the clipboard into a rich text editor, the CSS sanitizer does not escape < and > characters. Because the resulting string is pasted directly into the text node of the element this does not result in a direct injection into the webpage; however, if a webpage subsequently copies the node's innerHTML, assigning it to another innerHTML, this would result in an XSS vulnerability. Two WYSIWYG editors were identified with this behavior, more may exist.
References
Bug 1602843
#CVE-2019-17024: Memory safety bugs fixed in Thunderbird 68.4.1
Reporter
Mozilla developers
Impact
high
Description
Mozilla developers Jason Kratzer, Christian Holler, and Bob Clary reported memory safety bugs present in Thunderbird 68.3. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code.
References
Memory safety bugs fixed in Thunderbird 68.4.1
Changes changed Various improvements when setting up an account for a Microsoft Exchange server: Now offers IMAP/SMTP if available, better detection for Office 365 accounts; re-run configuration after password change. Fixes After changing view layout, the message display pane showed garbled content under some circumstances fixed Various security fixes fixed Various theme changes to achieve "pixel perfection": Unread icon, "no results" icon, paragraph format and font selector, background of folder summary tooltip fixed Tags were lost on messages in shared IMAP folders under some circumstances fixed Calendar: Event attendee dialog was not displayed correctly fixed
comment:4 by , 7 years ago
| Priority: | normal → highest |
|---|---|
| Severity: | normal → critical |
| Summary: | thunderbird-68.4.1 → thunderbird-68.4.1 (0 day fix similar to Firefox) |
comment:5 by , 7 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
comment:6 by , 7 years ago
My build size is:
9.1 GB (149 MB installed)
Ken, does that sound reasonable?
comment:8 by , 7 years ago
Both sizes sound as if they are in the right area - at times over the past few months we've had those sort of sizes, but then on the next update we've dropped back to less than half that size (4.2GB for 68.3.1 at the moment). I suspect those were measured with a much older version of rustc.

Replying to ken@…:
I can do that, but how do I count the 640M that is already in ~/.cargo?