Summary: | <www-client/firefox{,-bin}-60.2.1: multiple vulnerabilities (MFSA-2018-23) | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | GLSAMaker/CVETool Bot <glsamaker> |
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | mozilla, tripolar |
Priority: | Normal | Flags: | stable-bot:
sanity-check+
|
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://www.mozilla.org/en-US/security/advisories/mfsa2018-23/ | ||
Whiteboard: | B3 [glsa+ cve] | ||
Package list: |
www-client/firefox-60.2.1-r1
|
Runtime testing required: | --- |
Description
GLSAMaker/CVETool Bot
![]() CVE-2018-12385: Crash in TransportSecurityInfo due to cached data Impact moderate Description A potentially exploitable crash in TransportSecurityInfo used for SSL can be triggered by data stored in the local cache in the user profile directory. This issue is only exploitable in combination with another vulnerability allowing an attacker to write data into the local cache or from locally installed malware. This issue also triggers a non-exploitable startup crash for users switching between the Nightly and Release versions of Firefox if the same profile is used. References CVE-2018-12383: Setting a master password post-Firefox 58 does not delete unencrypted previously stored passwords Impact low Description If a user saved passwords before Firefox 58 and then later set a master password, an unencrypted copy of these passwords is still accessible. This is because the older stored password file was not deleted when the data was copied to a new format starting in Firefox 58. The new master password is added only on the new file. This could allow the exposure of stored password data outside of user expectations. References @ Arches, please test and mark stable: =www-client/firefox-60.2.1-r1 Don't forget to remove package.stable.use.mask for USE=clang once you have stabilized =sys-devel/lld-6.0.1 as part of bug 667168. x86 stable amd64 stable Repository is clean. New GLSA request filed. This issue was resolved and addressed in GLSA 201810-01 at https://security.gentoo.org/glsa/201810-01 by GLSA coordinator Thomas Deutschmann (whissi). |