| Summary: | postgresql new security issues CVE-2020-14349 and CVE-2020-14350 | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | David Walser <luigiwalser> |
| Component: | Security | Assignee: | QA Team <qa-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | Sec team <security> |
| Severity: | normal | ||
| Priority: | Normal | CC: | herman.viaene, joequant, mageia, nicolas.salguero, sysadmin-bugs |
| Version: | 7 | Keywords: | advisory, validated_update |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | MGA7-64-OK | ||
| Source RPM: | postgresql9.6, postgresql11 | CVE: | CVE-2020-14349, CVE-2020-14350 |
| Status comment: | |||
|
Description
David Walser
2020-08-14 13:41:47 CEST
David Walser
2020-08-14 13:46:39 CEST
Whiteboard:
(none) =>
MGA7TOO Assigning globally as different people maintain the different versions; CC'ing the most visible ones. Assignee:
bugsquad =>
pkg-bugs Suggested advisory: ======================== The updated packages fix security vulnerabilities: It was found that PostgreSQL versions before 12.4, before 11.9 and before 10.14 did not properly sanitize the search_path during logical replication. An authenticated attacker could use this flaw in an attack similar to CVE-2018-1058, in order to execute arbitrary SQL command in the context of the user used for replication. (CVE-2020-14349) It was found that some PostgreSQL extensions did not use search_path safely in their installation script. An attacker with sufficient privileges could use this flaw to trick an administrator into executing a specially crafted script, during the installation or update of such extension. This affects PostgreSQL versions before 12.4, before 11.9, before 10.14, before 9.6.19, and before 9.5.23. (CVE-2020-14350) References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14349 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14350 https://www.postgresql.org/about/news/2060/ ======================== Updated packages in core/updates_testing: ======================== postgresql9.6-9.6.19-1.mga7 lib(64)pq5.9-9.6.19-1.mga7 lib(64)ecpg9.6_6-9.6.19-1.mga7 postgresql9.6-server-9.6.19-1.mga7 postgresql9.6-docs-9.6.19-1.mga7 postgresql9.6-contrib-9.6.19-1.mga7 postgresql9.6-devel-9.6.19-1.mga7 postgresql9.6-pl-9.6.19-1.mga7 postgresql9.6-plpython-9.6.19-1.mga7 postgresql9.6-plperl-9.6.19-1.mga7 postgresql9.6-pltcl-9.6.19-1.mga7 postgresql9.6-plpgsql-9.6.19-1.mga7 postgresql11-11.9-1.mga7 lib(64)pq5-11.9-1.mga7 lib(64)ecpg11_6-11.9-1.mga7 postgresql11-server-11.9-1.mga7 postgresql11-docs-11.9-1.mga7 postgresql11-contrib-11.9-1.mga7 postgresql11-devel-11.9-1.mga7 postgresql11-pl-11.9-1.mga7 postgresql11-plpython-11.9-1.mga7 postgresql11-plpython3-11.9-1.mga7 postgresql11-plperl-11.9-1.mga7 postgresql11-pltcl-11.9-1.mga7 postgresql11-plpgsql-11.9-1.mga7 from SRPMS: postgresql9.6-9.6.19-1.mga7.src.rpm postgresql11-11.9-1.mga7.src.rpm Version:
Cauldron =>
7 MGA7-64 Plasma on Lenovo B50 No installation issues. Test in two steps: first install version 9.6.19 over existing 9.6 Using pgadmin to create new database and new table with 4 columns: all OK. Reporting later on postgresql11 CC:
(none) =>
herman.viaene Installed version 11 which removed 9.6. Using pgadminthe database was preserved over the major update. I could delete the database which I created in Comment 3, define a new one, new table with 4 colums and a PK and a unique key Looks OK to me. Whiteboard:
(none) =>
MGA7-64-OK
Jani Välimaa
2020-09-06 16:26:02 CEST
CC:
jani.valimaa =>
(none)
David Walser
2020-09-06 16:50:20 CEST
CC:
(none) =>
sysadmin-bugs
Aurelien Oudelet
2020-09-06 20:03:00 CEST
Keywords:
(none) =>
advisory An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2020-0365.html Resolution:
(none) =>
FIXED |