New Glibc For CentOS-6 And CentOS-7 And CVE-2015-7547

Home » CentOS » New Glibc For CentOS-6 And CentOS-7 And CVE-2015-7547
CentOS 12 Comments

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.

  • 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

LEAVE A COMMENT