New Glibc For CentOS-6 And CentOS-7 And CVE-2015-7547
I normally just let the daily announce post to this list show what is available for updates, but there is a CVE (CVE-2015-7547) that needs a bit more attention which will be on today’s announce list of updates.
We released a new glibc yesterday for CentOS-6 and CentOS-7 .. it is VERY important that all users update to these versions: This update is rated as Critical by Red Hat, meaning that it is remotely exploitable under some circumstances. Make sure this update works in your environments and update as soon as you can.
CentOS-7:
https://lists.CentOS.org/pipermail/CentOS-announce/2016-February/021672.html
https://rhn.redhat.com/errata/RHSA-2016-0176.html
CentOS-6:
https://lists.CentOS.org/pipermail/CentOS-announce/2016-February/021668.html
https://rhn.redhat.com/errata/RHSA-2016-0175.html
These mitigate CVE-2015-7547:
https://access.redhat.com/security/cve/CVE-2015-7547
https://bugzilla.redhat.com/show_bug.cgi?id=1293532
Can’t stress how important this update is .. here are a couple stories:
http://arstechnica.com/security/2016/02/extremely-severe-bug-leaves-dizzying-number-of-apps-and-devices-vulnerable/
http://www.theregister.co.uk/2016/02/16/glibc_linux_dns_vulernability/
Please note that the ONLY way this is tested to work is with ALL updates from CentOS-6 or CentOS-7 applied along with the glibc updates. So a yum update with base and updates repo enabled is the ONLY tested scenario. Did I say *ONLY* enough?
Thanks, Johnny Hughes
12 thoughts on - New Glibc For CentOS-6 And CentOS-7 And CVE-2015-7547
Hi Johnny,
Thank you as always, Should I be rebooting servers to ensure that all services are using the new glibc?
sorry for the rookie question, just need some clarification.
thanks
Michael
https://rhn.redhat.com/errata/RHSA-2016-0176.html https://rhn.redhat.com/errata/RHSA-2016-0175.html Please note that the ONLY way this is tested to work is with ALL
It depends on your environment : it’s adviced to restart the node, but if you can’t, you can list the service[s] that depend on libc and
(selectively) restart those (like sshd/httpd/postfix/…) on public facing nodes :
lsof +c0 -d DEL | awk ‘NR==1 || /libc-/ {print $2,$1,$4,$NF}’ | column -t
Source : https://access.redhat.com/articles/2161461
–
I am trying to find conclusive info on whether pre glibc version 2.9
needs to be of concern. I have some older CentOS-5 machines running some older software, and they currently have glibc 2.5-123 installed. Some technical info i have read on this vulnerability states that the issue was introduced in version 2.9. But other less technical articles mention that older version “could” be vulnerable. Would appreciate any comments from the community on this.
The easy answer is yes .. glibc requires so many things to be restarted, that is the best bet. Or certainly the easiest.
Note: in CentOS 7, there is also a kernel update which is rated as Important .. so you should boot to that anyway:
https://lists.CentOS.org/pipermail/CentOS-announce/2016-February/021705.html
Here is a good link to figure out what to restart if you don’t want to reboot:
https://rwmj.wordpress.com/2014/07/10/which-services-need-restarting-after-an-upgrade/
and there is this thread:
http://markmail.org/message/dodinyrhwgey35mh
But generalyl, after a glibc update or a kernel update .. rebooting is easiest and it ensures everything is protected.
Red Hat says no:
https://access.redhat.com/security/cve/CVE-2015-7547
Is it possible they are wrong .. I guess, anything is possible.
You can test with this:
https://github.com/fjserna/CVE-2015-7547
Wow, so, I updated my server (yum update -y) which applied a new kernel and the new glibc among other things, After the update completed it knocked my master PostgreSQL database offline.
Feb 17 13:46:11 db1 systemd: Starting PostgreSQL database server… Feb 17 13:46:11 db1 pg_ctl: LOG: invalid value for parameter
“max_stack_depth”: 16384
Feb 17 13:46:11 db1 pg_ctl: DETAIL: “max_stack_depth” must not exceed
7680kB. Feb 17 13:46:11 db1 pg_ctl: HINT: Increase the platform’s stack depth limit via “ulimit -s” or local equivalent. Feb 17 13:46:11 db1 pg_ctl: FATAL: configuration file
“/var/lib/pgsql/data/PostgreSQL.conf” contains errors Feb 17 13:46:16 db1 pg_ctl: pg_ctl: could not start server Feb 17 13:46:16 db1 pg_ctl: Examine the log output. Feb 17 13:46:16 db1 systemd: PostgreSQL.service: control process exited, code=exited status=1
Feb 17 13:46:16 db1 systemd: Failed to start PostgreSQL database server. Feb 17 13:46:16 db1 systemd: Unit PostgreSQL.service entered failed state. Feb 17 13:46:16 db1 systemd: PostgreSQL.service failed.
I have kernel parameters specified in /etc/sysctl.conf
vm.swappiness=0
vm.overcommit_memory=2
vm.overcommit_ratio
Since you are talking about SystemD .. I assume c7.
In c7 .. there is a symlink to /etc/sysctl.d/99-sysctl.conf to
/etc/sysctl.conf
Have you verified your sysctl.conf actually contains those settings still.
Your best bet on CentOS-7 is to create a new file in /etc/sysctl.d/
called something like 99-postgres.conf and put youjr mods in there. That way it will never change.
Also .. verify all the files in /etc/sysctl.d/ and /etc/sysctl.conf are set to this label for selinux:
unconfined_u:object_r:etc_t:s0
See this for labeling:
red.ht/1ooTpiI
But, /etc/sysctl.conf should still work in CentOS-7.
Looks like that is working (it seems to be reading your /etc/sysctl.conf file) based on your other post in this thread.
Here is a good link to figure out what to restart if you don’t want to and there is this thread:
Contents are still in tact.
# ll -dZ /etc/sysctl.d drwxr-xr-x. root root system_u:object_r:etc_t:s0 /etc/sysctl.d
# ll -Z /etc/sysctl.conf
-rw-r–r–. root root system_u:object_r:system_conf_t:s0 /etc/sysctl.conf
I tried restorecon -Frv /etc/sysctl* to no avail.
Should I manually re-label these or is this an issue with the selinux-policy package having the incorrect defaults?
Thanks,
Michael
Hi Johnny,
Excuse my ignorance, if the sysctl.conf is working then why would my database throw this error still?
state.
Should my output from ulimit -a not correspond to my sysctl.conf parameters?
This server was tested heavily and rebooted tens of times before it moved into production, I can’t understand what has changed other than now I get inconsistent output from
sysctl -a and ulimit -a. I am quite confident this wasn’t the case before I updated today.
ulimit -s is definitely not showing the correct parameter that I
specified in /etc/sysctl.conf.
Thanks,
Michael
Are you not confusing two unrelated things?
man systemd.exec / LimitSTACK no?
https://bugzilla.redhat.com/show_bug.cgi?idu0923 may point you further.
jh
Hi Jonny,
A little google and I found my original conversation on here about setting it initially. Sorry for wasting your time on this,
https://lists.CentOS.org/pipermail/CentOS/2015-August/154290.html
So, the answer is that the service requires the LimitSTACK=[stack-size-in-bytes]
in the [Service] section of
/etc/systemd/system/multi-user.target.wants/PostgreSQL.service
Thank you!
Michael