| Summary: | phpmyadmin new security issues fixed upstream in 4.4.15.3 | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | David Walser <luigiwalser> |
| Component: | Security | Assignee: | QA Team <qa-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | Sec team <security> |
| Severity: | major | ||
| Priority: | Normal | CC: | davidwhodgins, lists.jjorge, sysadmin-bugs, wilcal.int |
| Version: | 5 | Keywords: | validated_update |
| Target Milestone: | --- | ||
| Hardware: | i586 | ||
| OS: | Linux | ||
| URL: | http://lwn.net/Vulnerabilities/674263/ | ||
| Whiteboard: | has_procedure MGA5-32-OK MGA5-64-OK advisory | ||
| Source RPM: | phpmyadmin-4.2.13.3-1.3.mga5.src.rpm | CVE: | |
| Status comment: | |||
|
Description
David Walser
2016-01-28 14:35:25 CET
Advisory: ======================== Updated phpmyadmin package fixes security vulnerabilities: Password suggestion functionality uses Math.random() which does not provide cryptographically secure random numbers (CVE-2016-1927). By calling some scripts that are part of phpMyAdmin in an unexpected way, it is possible to trigger phpMyAdmin to display a PHP error message which contains the full path of the directory where phpMyAdmin is installed (CVE-2016-2038). The XSRF/CSRF token is generated with a weak algorithm using functions that do not return cryptographically secure values (CVE-2016-2039). With a crafted table name it is possible to trigger an XSS attack in the database search page. With a crafted SET value or a crafted search query, it is possible to trigger an XSS attacks in the zoom search page. With a crafted hostname header, it is possible to trigger an XSS attacks in the home page (CVE-2016-2040). The comparison of the XSRF/CSRF token parameter with the value saved in the session is vulnerable to timing attacks. Moreover, the comparison could be bypassed if the XSRF/CSRF token matches a particular pattern (CVE-2016-2041). The phpmyadmin package has been updated to version 4.4.15.3 in the 4.4.x stable branch, and the phpseclib dependency has been updated to version 2.0.1. References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-1927 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2038 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2039 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2040 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2041 https://www.phpmyadmin.net/security/PMASA-2016-1/ https://www.phpmyadmin.net/security/PMASA-2016-2/ https://www.phpmyadmin.net/security/PMASA-2016-3/ https://www.phpmyadmin.net/security/PMASA-2016-4/ https://www.phpmyadmin.net/security/PMASA-2016-5/ https://www.phpmyadmin.net/files/4.4.15.3/ https://www.phpmyadmin.net/news/2016/1/28/phpmyadmin-454-44153-and-401013-are-released/ ======================== Updated packages in core/updates_testing: ======================== phpseclib-2.0.1-1.mga5 phpmyadmin-4.4.15.3-1.mga5 from SRPMS: phpseclib-2.0.1-1.mga5.src.rpm phpmyadmin-4.4.15.3-1.mga5.src.rpm Assignee:
bugsquad =>
qa-bugs Testing procedure: https://bugs.mageia.org/show_bug.cgi?id=12834#c7 https://bugs.mageia.org/show_bug.cgi?id=14208#c6 Whiteboard:
(none) =>
has_procedure In VirtualBox, M5, KDE, 32-bit Package(s) under test: mariadb phpmyadmin default install of mariadb & phpmyadmin [root@localhost wilcal]# urpmi mariadb Package mariadb-10.0.23-1.mga5.i586 is already installed [root@localhost wilcal]# urpmi phpmyadmin Package phpmyadmin-4.2.13.3-1.3.mga5.noarch is already installed start mysqladmin, set password, open http://localhost/phpmyadmin/ create new database called test01. Close browser. Successfully reopen: http://localhost/phpmyadmin/ install phpmyadmin from updates_testing [root@localhost wilcal]# urpmi mariadb Package mariadb-10.0.22-1.mga5.i586 is already installed [root@localhost wilcal]# urpmi phpmyadmin Package phpmyadmin-4.4.15.3-1.mga5.noarch is already installed open http://localhost/phpmyadmin/ Oh oh! phpmyadmin fails to open. :-( CC:
(none) =>
wilcal.int Mariadb seems to have go back a version Bill, is that correct or a typo? From mariadb-10.0.23-1.mga5.i586 to mariadb-10.0.22-1.mga5.i586 Jóse, did I make any obvious mistakes with this update? Should I have only updated phpseclib to 1.0.0 perhaps? CC:
(none) =>
lists.jjorge (In reply to claire robinson from comment #4) > Mariadb seems to have go back a version Bill, is that correct or a typo? > > From mariadb-10.0.23-1.mga5.i586 to mariadb-10.0.22-1.mga5.i586 sorry, s/b: [root@localhost wilcal]# urpmi mariadb Package mariadb-10.0.23-1.mga5.i586 is already installed [root@localhost wilcal]# urpmi phpmyadmin Package phpmyadmin-4.4.15.3-1.mga5.noarch is already installed Still fails. (In reply to David Walser from comment #5) > Jóse, did I make any obvious mistakes with this update? Should I have only > updated phpseclib to 1.0.0 perhaps? What fails? (In reply to José Jorge from comment #7) > What fails? When I go to: http://localhost/phpmyadmin/ that page opens to all white. Sounds like an upstream issue. They made a bugfix release today (January 29): https://www.phpmyadmin.net/news/2016/1/29/phpmyadmin-401014-44154-and-451/ Advisory: ======================== Updated phpmyadmin package fixes security vulnerabilities: Password suggestion functionality uses Math.random() which does not provide cryptographically secure random numbers (CVE-2016-1927). By calling some scripts that are part of phpMyAdmin in an unexpected way, it is possible to trigger phpMyAdmin to display a PHP error message which contains the full path of the directory where phpMyAdmin is installed (CVE-2016-2038). The XSRF/CSRF token is generated with a weak algorithm using functions that do not return cryptographically secure values (CVE-2016-2039). With a crafted table name it is possible to trigger an XSS attack in the database search page. With a crafted SET value or a crafted search query, it is possible to trigger an XSS attacks in the zoom search page. With a crafted hostname header, it is possible to trigger an XSS attacks in the home page (CVE-2016-2040). The comparison of the XSRF/CSRF token parameter with the value saved in the session is vulnerable to timing attacks. Moreover, the comparison could be bypassed if the XSRF/CSRF token matches a particular pattern (CVE-2016-2041). The phpmyadmin package has been updated to version 4.4.15.4 in the 4.4.x stable branch, and the phpseclib dependency has been updated to version 2.0.1. References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-1927 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2038 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2039 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2040 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2041 https://www.phpmyadmin.net/security/PMASA-2016-1/ https://www.phpmyadmin.net/security/PMASA-2016-2/ https://www.phpmyadmin.net/security/PMASA-2016-3/ https://www.phpmyadmin.net/security/PMASA-2016-4/ https://www.phpmyadmin.net/security/PMASA-2016-5/ https://www.phpmyadmin.net/files/4.4.15.4/ https://www.phpmyadmin.net/news/2016/1/28/phpmyadmin-454-44153-and-401013-are-released/ https://www.phpmyadmin.net/news/2016/1/29/phpmyadmin-401014-44154-and-451/ ======================== Updated packages in core/updates_testing: ======================== phpseclib-2.0.1-1.mga5 phpmyadmin-4.4.15.4-1.mga5 from SRPMS: phpseclib-2.0.1-1.mga5.src.rpm phpmyadmin-4.4.15.4-1.mga5.src.rpm In VirtualBox, M5, KDE, 32-bit Package(s) under test: mariadb phpmyadmin default install of mariadb & phpmyadmin [root@localhost wilcal]# urpmi mariadb Package mariadb-10.0.23-1.mga5.i586 is already installed [root@localhost wilcal]# urpmi phpmyadmin Package phpmyadmin-4.2.13.3-1.3.mga5.noarch is already installed start mysqladmin, set password, open http://localhost/phpmyadmin/ create new database called test01. Close browser. Successfully reopen: http://localhost/phpmyadmin/ install phpmyadmin from updates_testing [root@localhost wilcal]# urpmi mariadb Package mariadb-10.0.23-1.mga5.i586 is already installed [root@localhost wilcal]# urpmi phpmyadmin Package phpmyadmin-4.4.15.4-1.mga5.noarch is already installed open http://localhost/phpmyadmin/ phpmyadmin successfully opens. Previously create db test01 is still there. create new database called test02. Close browser. Successfully reopen: http://localhost/phpmyadmin/ db's test01 & test02 are still there and accessable. In VirtualBox, M5, KDE, 64-bit Package(s) under test: mariadb phpmyadmin default install of mariadb & phpmyadmin [root@localhost wilcal]# urpmi mariadb Package mariadb-10.0.23-1.mga5.x86_64 is already installed [root@localhost wilcal]# urpmi phpmyadmin Package phpmyadmin-4.2.13.3-1.3.mga5.noarch is already installed start mysqladmin, set password, open http://localhost/phpmyadmin/ create new database called test01. Close browser. Successfully reopen: http://localhost/phpmyadmin/ install phpmyadmin from updates_testing [root@localhost wilcal]# urpmi mariadb Package mariadb-10.0.23-1.mga5.x86_64 is already installed [root@localhost wilcal]# urpmi phpmyadmin Package phpmyadmin-4.4.15.4-1.mga5.noarch is already installed open http://localhost/phpmyadmin/ phpmyadmin successfully opens. Previously created db test01 is still there. create new database called test02. Close browser. Successfully reopen: http://localhost/phpmyadmin/ db's test01 & test02 are still there and accessable. This update works fine. Testing complete for MGA5, 32-bit & 64-bit Validating the update. Could someone from the sysadmin team push to updates. Thanks Keywords:
(none) =>
validated_update LWN reference for two of the CVEs: http://lwn.net/Vulnerabilities/674259/ URL:
(none) =>
http://lwn.net/Vulnerabilities/674263/
Dave Hodgins
2016-02-03 02:48:31 CET
CC:
(none) =>
davidwhodgins An update for this issue has been pushed to Mageia Updates repository. http://advisories.mageia.org/MGASA-2016-0051.html Status:
NEW =>
RESOLVED |