Opened 5 years ago
Closed 5 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 , 5 years ago
comment:2 by , 5 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 , 5 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 , 5 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 , 5 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:6 by , 5 years ago
My build size is:
9.1 GB (149 MB installed)
Ken, does that sound reasonable?
comment:8 by , 5 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?