Bug 1375198 (CVE-2016-6662)
Summary: | CVE-2016-6662 mysql: general_log can write to configuration files, leading to privilege escalation (CPU Oct 2016) | ||
---|---|---|---|
Product: | [Other] Security Response | Reporter: | Adam Mariš <amaris> |
Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
Status: | CLOSED ERRATA | QA Contact: | |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | unspecified | CC: | anazmy, aortega, apevec, apmukher, avibelli, ayoung, btotty, byte, carnil, cheese, chrisw, coneill, cperry, cvsbot-xmlrpc, databases-maint, dciabrin, dowdle, ehedgren, fdinitto, gerald.prock, gnaik, gsterlin, hasuzuki, hhorak, igor.cherfas, jbalunas, jorton, jschluet, jshepherd, jstanek, kbasil, kent, kvolny, lhh, lpeer, markmc, mbayer, mickygough, mjc, mmuzila, pdwyer, praiskup, puiterwijk, rbryant, redhat-bugzilla, robert.scheck, rrajasek, rvstaveren, samirjafferali, sclewis, slong, srevivo, tdecacqu, tjay, tkirby, upendra.gandhi, vigneshb4u, williamt, ykawada, yozone |
Target Milestone: | --- | Keywords: | Security |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | mysql 5.5.52, mysql 5.6.33, mysql 5.7.15, mariadb 5.5.51, mariadb 10.0.27, mariadb 10.1.17 | Doc Type: | If docs needed, set a value |
Doc Text: |
It was discovered that the MySQL logging functionality allowed writing to MySQL configuration files. An administrative database user, or a database user with FILE privileges, could possibly use this flaw to run arbitrary commands with root privileges on the system running the database server.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2017-01-24 12:00:16 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 1375200, 1375201, 1375202, 1377974, 1379492, 1379493, 1379494, 1379495, 1379496, 1379497, 1379498, 1379499, 1384960, 1384961, 1384962, 1384963, 1386744, 1386745, 1393306, 1393309, 1393313, 1393314, 1397309, 1397310, 1429972, 1429973 | ||
Bug Blocks: | 1323912, 1375204, 1386598 |
Description
Adam Mariš
2016-09-12 13:16:58 UTC
Created mariadb tracking bugs for this issue: Affects: fedora-all [bug 1375201] Created community-mysql tracking bugs for this issue: Affects: fedora-all [bug 1375200] Created mariadb-galera tracking bugs for this issue: Affects: fedora-all [bug 1375202] MariaDB upstream bug report: https://jira.mariadb.org/browse/MDEV-10465 It does not have any details on how this bug was addressed, but its id can be used to locate relevant commits in changelogs for the versions listed as correcting this issue: https://mariadb.com/kb/en/mariadb/mariadb-5551-changelog/ https://mariadb.com/kb/en/mariadb/mariadb-10027-changelog/ https://mariadb.com/kb/en/mariadb/mariadb-10117-changelog/ These link the following commits as related to MDEV-10465: https://github.com/MariaDB/server/commit/470f259 https://github.com/MariaDB/server/commit/2a54a53 https://github.com/MariaDB/server/commit/0098d78 These commits prevent general_log from writing into files with names ending with my.cnf or my.ini. MySQL seems to be fixed in versions 5.5.52, 5.6.33, and 5.7.15: https://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-52.html https://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-33.html https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-15.html The following changes are described, corresponding to the linked commits: For mysqld_safe, the argument to --malloc-lib now must be one of the directories /usr/lib, /usr/lib64, /usr/lib/i386-linux-gnu, or /usr/lib/x86_64-linux-gnu. In addition, the --mysqld and --mysqld-version options can be used only on the command line and not in an option file. (Bug #24464380) https://github.com/mysql/mysql-server/commit/684a165f28b3718160a3e4c5ebd18a465d85e97c https://github.com/mysql/mysql-server/commit/754e7eff2872995e2b6e62f9da7448587a411c7b It was possible to write log files ending with .ini or .cnf that later could be parsed as option files. The general query log and slow query log can no longer be written to a file ending with .ini or .cnf. (Bug #24388753) https://github.com/mysql/mysql-server/commit/48bd8b16fe382be302c6f0b45931be5aa6f29a0e The second change is similar to MariaDB fix, but is more strict by preventing overwrite of any file ending with .cnf or .ini. MySQL 5.7.15 also includes this additional change: mysqld_safe attempted to read my.cnf in the data directory, although that is no longer a standard option file location. (Bug #24482156) https://github.com/mysql/mysql-server/commit/71f48ab393bce80a59e5a2e498cd1f46f6b43f9a Oracle is probably not going to acknowledge these fixes with CVEs until the next CPU scheduled for mid-October. All MySQL and MariaDB packages in Red Hat Enterprise Linux and Red Hat Software Collections install my.cnf configuration file as root-owned and not writeable to the mysql user under which mysqld is run. The configuration file is created in /etc and not inside the data directory. All MySQL and MariaDB packages in at least Red Hat Enterprise Linux 6 and later, and Red Hat Software Collections allow database users with FILE privileges to create my.cnf file inside data directory that is not world-writeable, and hence is not ignored by mysqld / mysqld_safe. All MySQL and MariaDB packages for Red Hat Enterprise Linux 7 (either directly from Red Hat Enterprise Linux 7 or from Red Hat Software Collections for Red Hat Enterprise Linux 7) run mysqld_safe with mysql user privileges and not root privileges. Therefore, the worst impact of this issue on Red Hat Enterprise Linux 7 is escalation form database user with FILE privileges to arbitrary code execution as mysql system user. Additionally, the init script / systemd unit for rh-mariadb101 collection for Red Hat Enterprise Linux 7 does not use mysqld_safe at all and is therefore not vulnerable to the published exploit. The MySQL 5.1 packages in Red Hat Enterprise Linux 6 include the version of mysqld_safe that does not implement support for library preloading. Therefore, the published remote exploit does not affect those packages. Note that there is still a possibility of local privilege escalation - a database user with FILE privileges that also has local unprivileged shell access can escalate their privileges to root. For certain MySQL / MariaDB packages running on Red Hat Enterprise Linux 7, the issue is further mitigated by SELinux, which prevents loading of the injected shared library. Mitigating factors: - The attack can only be performed by an attacker with database access with FILE privileges. The FILE privilege is not commonly granted to non-administrative database users, and as noted in the reporter's advisory, it allows gaining full administrative privileges (unless restricted with the secure_file_priv setting). As noted in the advisory, SQL injection flaws in web applications may open up this issue to attackers who are not meant to have direct database access. Ensure that the FILE privilege is not granted to any non-administrative database user. Note that reporter claims existence of another, not yet disclosed vulnerability which makes exploitation of this issue possible without FILE privilege. The CVE-2016-6663 was reserved for the additional vulnerability. - Published exploit depends on an already existing my.cnf that is writeable to the mysql user. As noted above, in the default configuration of MySQL/MariaDB packages in Red Hat Enterprise Linux and Red Hat Software Collections, the configuration file is not writeable to the mysql user. While the advisory describes how to create a new my.cnf in the data directory that is read by mysqld / mysqld_safe, the newly created file is rejected as malformed as it does not start with a valid INI file section delimiter. The advisory does not mention any way to avoid this exploitation obstacle. The combination of the above two factors imply that the published exploit does not work against the default configuration of MySQL and MariaDB in Red Hat products. Statement: All MySQL and MariaDB packages in Red Hat Enterprise Linux and Red Hat Software Collections install the my.cnf configuration file in /etc as root-owned and not writeable to mysqld's mysql user. This default configuration stops the published exploit for this issue. All MySQL and MariaDB packages for Red Hat Enterprise Linux 7 (either those directly included in Red Hat Enterprise Linux 7 or from Red Hat Software Collections for Red Hat Enterprise Linux 7) run mysqld_safe with mysql user privileges and not root privileges, limiting the potential impact to code execution as mysql system user. The MySQL 5.1 packages in Red Hat Enterprise Linux 6 do not implement support for library preloading, completely preventing the remote attack vector used by the published exploit. For additional details, refer to: https://bugzilla.redhat.com/show_bug.cgi?id=1375198#c12 Mitigation: - Ensure all MySQL / MariaDB configuration files are not writeable to the mysql user. This is the default configuration in Red Hat products. - Ensure that non-administrative database users are not granted FILE privilege. Applications accessing data in MySQL / MariaDB databases, including web application potentially vulnerable to SQL injections, should use database accounts with the lowest privileges required. - If FILE permission needs to be granted to some non-administrative database users, use secure_file_priv setting to limit where files can be written to or read from. (In reply to Tomas Hoger from comment #12) > The MySQL 5.1 packages in Red Hat Enterprise Linux 6 include the version of > mysqld_safe that does not implement support for library preloading. > Therefore, the published remote exploit does not affect those packages. The same applies to MySQL 5.0 packages in Red Hat Enterprise Linux 5. Additionally, MySQL 5.0 does not support general_log, which is also required by this exploit. The support for general_log was added in version 5.1.29: Important Change: The --log option now is deprecated and will be removed (along with the log system variable) in the future. Instead, use the --general_log option to enable the general query log and the --general_log_file=file_name option to set the general query log file name. The values of these options are available in the general_log and general_log_file system variables, which can be changed at runtime. http://downloads.mysql.com/docs/mysql-5.1-relnotes-en.pdf As hinted by the above, --log could not be changed at runtime. It seams, that the bug is already abused in the wild. We have some LAMP server with infected configuration files in the /var/lib/mysql/ folder and with the logrotate the restart fails. At the moment we have been lucky and there was no link to a *.so file but otherwise the mysql_safe would load them on start with root permissions. Example for RHEL7: --------------------------------------- 1) Write file to /var/lib/mysql/my.cnf als user: $ mysql Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 17828 Server version: 5.5.47-MariaDB MariaDB Server Copyright (c) 2000, 2015, Oracle, MariaDB Corporation Ab and others. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. MariaDB [(none)]> MariaDB [(none)]> set global general_log_file = '/var/lib/mysql/my.cnf'; Query OK, 0 rows affected (0.00 sec) MariaDB [(none)]> set global general_log = on; Query OK, 0 rows affected (0.02 sec) MariaDB [(none)]> select 'blablablub ... i kill the restart ... ggg'; +-------------------------------------------+ | blablablub ... i kill the restart ... ggg | +-------------------------------------------+ | blablablub ... i kill the restart ... ggg | +-------------------------------------------+ 1 row in set (0.00 sec) MariaDB [(none)]> set global general_log = off; Query OK, 0 rows affected (0.00 sec) MariaDB [(none)]> quit Bye --------------------------------------- 2) Content of the created file: $ cat /var/lib/mysql/my.cnf /usr/libexec/mysqld, Version: 5.5.47-MariaDB (MariaDB Server). started with: Tcp port: 3306 Unix socket: /var/lib/mysql/mysql.sock Time Id Command Argument 160920 16:07:21 17828 Query select 'blablablub ... i kill the restart ... ggg' 160920 16:07:33 17828 Query set global general_log = off --------------------------------------- 3) Restart of the database: # systemctl restart mariadb Job for mariadb.service failed because the control process exited with error code. See "systemctl status mariadb.service" and "journalctl -xe" for details. --------------------------------------- 4) Log of the start: # systemctl status mariadb.service ● mariadb.service - MariaDB database server Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Tue 2016-09-20 16:08:49 CEST; 9s ago Process: 12779 ExecStartPost=/usr/libexec/mariadb-wait-ready $MAINPID (code=exited, status=1/FAILURE) Process: 12778 ExecStart=/usr/bin/mysqld_safe --basedir=/usr (code=exited, status=0/SUCCESS) Process: 12750 ExecStartPre=/usr/libexec/mariadb-prepare-db-dir %n (code=exited, status=0/SUCCESS) Main PID: 12778 (code=exited, status=0/SUCCESS) Sep 20 16:08:48 rhel7test.vtirol.local mysqld_safe[12778]: Fatal error in defaults handling. Program aborted Sep 20 16:08:48 rhel7test.vtirol.local mysqld_safe[12778]: error: Found option without preceding group in config file: /var/lib/mysql/my.cnf at line: 1 Sep 20 16:08:48 rhel7test.vtirol.local mysqld_safe[12778]: Fatal error in defaults handling. Program aborted Sep 20 16:08:48 rhel7test.vtirol.local mysqld_safe[12778]: 160920 16:08:48 mysqld_safe Logging to '/var/lib/mysql/rhel7test.vtirol.local.err'. Sep 20 16:08:48 rhel7test.vtirol.local mysqld_safe[12778]: 160920 16:08:48 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql Sep 20 16:08:48 rhel7test.vtirol.local mysqld_safe[12778]: 160920 16:08:48 mysqld_safe mysqld from pid file /var/lib/mysql/rhel7test.vtirol.local.pid ended Sep 20 16:08:49 rhel7test.vtirol.local systemd[1]: mariadb.service: control process exited, code=exited status=1 Sep 20 16:08:49 rhel7test.vtirol.local systemd[1]: Failed to start MariaDB database server. Sep 20 16:08:49 rhel7test.vtirol.local systemd[1]: Unit mariadb.service entered failed state. Sep 20 16:08:49 rhel7test.vtirol.local systemd[1]: mariadb.service failed. --------------------------------------- As you see the mysqld_safe is reading the file /var/lib/mysql/my.cnf on startup. It also works with /var/lib/mysql/.my.cnf and with a ~/.my.cnf file. As hotfix a root owned file with 644 in all of the folders would work. But how to identify all folders the database is looking on startup? It would be nice if the rpm would contain that empty files ... (In reply to Gerald Prock from comment #18) > It seams, that the bug is already abused in the wild. > > We have some LAMP server with infected configuration files in the > /var/lib/mysql/ folder and with the logrotate the restart fails. At the > moment we have been lucky and there was no link to a *.so file For this attack, attacker needs to have ability to execute arbitrary SQL queries. Have you figured out how they were able to do so, as that's likely an issue of its own? Do you have untrusted DB users with high privileges, or vulnerable web app which also connects to DB using a privileged DB account? > but otherwise the mysql_safe would load them on start with root permissions. > > Example for RHEL7: Your example is on RHEL-7, where mysqld_safe is not run with root permissions, but as mysql OS user. See above for details. > 1) Write file to /var/lib/mysql/my.cnf als user: > > $ mysql It seems you're connecting as DB admin / root. Comments above note that DB user with sufficient privileges can create new my.cnf file inside of the data directory. That file is read by mysqld, and as it's not valid INI file, it leads to the service restart failure as you describe. Reporter's advisory (linked in comment 0) has been updated few times since the original publication. The most notable changes include: * The list of affected MySQL versions was updated to note that the issue was fixed in versions 5.5.52, 5.6.33, and 5.7.15, as noted in comment 5 above. * Author now more explicitly claims that even though published exploit requires existing my.cnf file that is writeable to the mysql system user, there is a different exploit that has not been published yet, which does not require existing my.cnf with weak permissions. Advisory explains that it is possible to create new my.cnf file in the data directory, which has to be writeable to the mysql user. Such file does not typically exist. When created using the general_log mechanism used by the exploit, it will not start with INI file [section] label, causing it to be rejected by MySQL as invalid and its content ignored. It is unclear if a mechanism used to create a well-formed my.cnf using MySQL logging would be classified as a separate vulnerability. The advisory includes the following mitigation instructions: As temporary mitigations, users should ensure that no mysql config files are owned by mysql user, and create root-owned dummy my.cnf files that are not in use. These are by no means a complete solution and users should apply official vendor patches as soon as they become available. It is unclear why this contradicting information is given, and if the private exploit can work if root-owned my.cnf exist in the data directory. Various MySQL and MariaDB packages in Red Hat Enterprise Linux and Red Hat Software Collections may different default locations for the data directory. A subset of these files are used by each version: /var/lib/mysql/.my.cnf /var/lib/mysql/my.cnf /opt/rh/mysql55/root/var/lib/mysql/my.cnf /var/opt/rh/rh-mysql56/lib/mysql/my.cnf /opt/rh/mariadb55/root/var/lib/mysql/my.cnf /var/opt/rh/rh-mariadb100/lib/mysql/my.cnf /var/opt/rh/rh-mariadb101/lib/mysql/my.cnf Creating the above files if their parent directory exists on a system as root-owned and not writeable to the mysql user follows the mitigation advice from the reporter's advisory. mariadb-10.0.27-1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report. This issue has been addressed in the following products: Red Hat Enterprise Linux OpenStack Platform 7.0 (Kilo) for RHEL 7 Via RHSA-2016:2061 https://rhn.redhat.com/errata/RHSA-2016-2061.html This issue has been addressed in the following products: Red Hat OpenStack Platform 9.0 (Mitaka) Via RHSA-2016:2062 https://rhn.redhat.com/errata/RHSA-2016-2062.html This issue has been addressed in the following products: Red Hat Enterprise Linux OpenStack Platform 5.0 (Icehouse) for RHEL 7 Via RHSA-2016:2059 https://rhn.redhat.com/errata/RHSA-2016-2059.html This issue has been addressed in the following products: Red Hat Enterprise Linux OpenStack Platform 6.0 (Juno) for RHEL 7 Via RHSA-2016:2060 https://rhn.redhat.com/errata/RHSA-2016-2060.html This issue has been addressed in the following products: Red Hat Enterprise Linux OpenStack Platform 5.0 (Icehouse) for RHEL 6 Via RHSA-2016:2058 https://rhn.redhat.com/errata/RHSA-2016-2058.html Additional related changes appeared in MySQL versions 5.5.53, 5.6.34, and 5.7.16. Those versions change change the default for secure_file_priv, the setting which controls where database user with FILE privileges can write files. Depending on the build, it's either NULL (preventing use of FILE privilege), or an empty dedicated directory that is created by Oracle distributed binary packages. Additionally, mysqld now tries to detect insecure secure_file_priv setting at startup and refuse to start if it's insecure. The following settings are considered insecure: - empty secure_file_priv, allowing read/write to any directory - secure_file_priv pointing to data directory or its subdirectory - secure_file_priv pointing to directory accessible to all users http://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-53.html http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-34.html http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-16.html This commit adds these changes: https://github.com/mysql/mysql-server/commit/7cb79a65ba6286ac66d5ebbebea3243ef97f5c41 This CVE is not mentioned in the Oracle CPU Oct 2016: http://www.oracle.com/technetwork/security-advisory/cpuoct2016-2881722.html#AppendixMSQL Note that the CPU lists version 5.5.52, 5.6.33, and 5.7.15 as affected by this issue despite fixes that were applied in those versions - see comment 5. Apparently, changes applied in versions 5.5.53, 5.6.34, and 5.7.16 - see comment 39 - got all listed under the original CVE. This issue has been addressed in the following products: Red Hat OpenStack Platform 8.0 (Liberty) Via RHSA-2016:2077 https://rhn.redhat.com/errata/RHSA-2016-2077.html This issue has been addressed in the following products: Red Hat Software Collections for Red Hat Enterprise Linux 6 Red Hat Software Collections for Red Hat Enterprise Linux 6.6 EUS Red Hat Software Collections for Red Hat Enterprise Linux 6.7 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7 Red Hat Software Collections for Red Hat Enterprise Linux 7.1 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7.2 EUS Via RHSA-2016:2130 https://rhn.redhat.com/errata/RHSA-2016-2130.html This issue has been addressed in the following products: Red Hat Software Collections for Red Hat Enterprise Linux 6 Red Hat Software Collections for Red Hat Enterprise Linux 6.6 EUS Red Hat Software Collections for Red Hat Enterprise Linux 6.7 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7 Red Hat Software Collections for Red Hat Enterprise Linux 7.1 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7.2 EUS Via RHSA-2016:2131 https://rhn.redhat.com/errata/RHSA-2016-2131.html This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2016:2595 https://rhn.redhat.com/errata/RHSA-2016-2595.html This issue has been addressed in the following products: Red Hat Software Collections for Red Hat Enterprise Linux 6 Red Hat Software Collections for Red Hat Enterprise Linux 6.7 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7 Red Hat Software Collections for Red Hat Enterprise Linux 7.1 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7.2 EUS Via RHSA-2016:2749 https://rhn.redhat.com/errata/RHSA-2016-2749.html (In reply to Stefan Cornelius from comment #13) > Statement: > > All MySQL and MariaDB packages in Red Hat Enterprise Linux and Red Hat > Software Collections install the my.cnf configuration file in /etc as > root-owned and not writeable to mysqld's mysql user. This default > configuration stops the published exploit for this issue. > > All MySQL and MariaDB packages for Red Hat Enterprise Linux 7 (either those > directly included in Red Hat Enterprise Linux 7 or from Red Hat Software > Collections for Red Hat Enterprise Linux 7) run mysqld_safe with mysql user > privileges and not root privileges, limiting the potential impact to code > execution as mysql system user. > > The MySQL 5.1 packages in Red Hat Enterprise Linux 6 do not implement > support for library preloading, completely preventing the remote attack > vector used by the published exploit. > > For additional details, refer to: > > https://bugzilla.redhat.com/show_bug.cgi?id=1375198#c12 > > > Mitigation: > Confused if these mitigations are also applicable for MySQL versions >= 5.5.53, 5.6.34, and 5.7.16 too which have the MySQL fix (per https://bugzilla.redhat.com/show_bug.cgi?id=1375198#c5). > - Ensure all MySQL / MariaDB configuration files are not writeable to the > mysql user. This is the default configuration in Red Hat products. > Based on new fix, Even if they are writeable by mysql user (per file permissions), general query log and slow query log can no longer be written to a file ending with .ini or .cnf > - Ensure that non-administrative database users are not granted FILE > privilege. Applications accessing data in MySQL / MariaDB databases, > including web application potentially vulnerable to SQL injections, should > use database accounts with the lowest privileges required. > Based on new fix, Even if non-admin database users are granted FILE privilege, they won't be able to write into .ini or .cnf files. > - If FILE permission needs to be granted to some non-administrative database > users, use secure_file_priv setting to limit where files can be written to > or read from. As I understand, the fix MySQL versions 5.5.53, 5.6.34, and 5.7.16, mitigates this issue completely and there is no need for any additional mitigations. Am I missing something? This issue has been addressed in the following products: Red Hat Software Collections for Red Hat Enterprise Linux 6.7 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7.3 EUS Red Hat Software Collections for Red Hat Enterprise Linux 6 Red Hat Software Collections for Red Hat Enterprise Linux 7 Red Hat Software Collections for Red Hat Enterprise Linux 7.2 EUS Via RHSA-2016:2928 https://rhn.redhat.com/errata/RHSA-2016-2928.html This issue has been addressed in the following products: Red Hat Software Collections for Red Hat Enterprise Linux 6 Red Hat Software Collections for Red Hat Enterprise Linux 6.7 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7 Red Hat Software Collections for Red Hat Enterprise Linux 7.2 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7.3 EUS Via RHSA-2016:2927 https://rhn.redhat.com/errata/RHSA-2016-2927.html This issue has been addressed in the following products: Red Hat Enterprise Linux 6 Via RHSA-2017:0184 https://rhn.redhat.com/errata/RHSA-2017-0184.html |