A heap-based buffer overflow was found in __nss_hostname_digits_dots(), which is used by the gethostbyname() and gethostbyname2() glibc function call. A remote attacker could use this flaw to execute arbitary code with the permissions of the user running the application.
Upstream patch: https://sourceware.org/git/?p=glibc.git;a=commit;h=d5dd6189d506068ed11c8bfa1e1e9bffde04decd
Public via: http://www.frsag.org/pipermail/frsag/2015-January/005722.html
Acknowledgements: Red Hat would like to thank Qualys for reporting this issue.
This issue has been addressed in the following products: Red Hat Enterprise Linux 5 Via RHSA-2015:0090 https://rhn.redhat.com/errata/RHSA-2015-0090.html
This issue was fixed upstream in glibc 2.18. Current Fedora versions 20 and 21 include glibc packages based on fixed upstream versions (2.18 and 2.20 respectively).
External References: http://www.openwall.com/lists/oss-security/2015/01/27/9 https://community.qualys.com/blogs/laws-of-vulnerabilities/2015/01/27/the-ghost-vulnerability https://access.redhat.com/articles/1332213
GHOST appears to also affect RHEL 6 and 7. Are patches being published for those releases?
This issue has been addressed in the following products: Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Via RHSA-2015:0092 https://rhn.redhat.com/errata/RHSA-2015-0092.html
The test script provided by Qualys (in the openwall.com post) still reports that RHEL6/& systems are vulnerable after installing the following packages: RHEL6: glibc-2.12-1.149.el6_6.4.x86_64 glibc-common-2.12-1.149.el6_6.4.x86_64 glibc-devel-2.12-1.149.el6_6.4.x86_64 glibc-headers-2.12-1.149.el6_6.4.x86_64 RHEL7: glibc-common-2.17-55.el7_0.3.x86_64 glibc-2.17-55.el7_0.3.x86_64 glibc-headers-2.17-55.el7_0.3.x86_64 glibc-devel-2.17-55.el7_0.3.x86_64 # ./GHOST vulnerable Is the script reporting a false-positive?
Those are not the versions currently referenced by RHSA-2015:0092
Oops - sorry for the noise. Doesn't look like the new packages are available on CDN yet.
Where's the fix for Enterprise Linux Server 6.6 x86_64?
Looks like https://access.redhat.com/security/cve/CVE-2015-0235 has been updated with info on fixes for RHEL5 (RHSA-2015:0090), RHEL6 and RHEL7 (RHSA-2015:0092 for both). glibc-2.5-123.el5_11.1 glibc-2.12-1.149.el6_6.5 glibc-2.17-55.el7_0.5
For Scientific Linux users, currently updating to these packages causes most tools to segfault: glibc-2.12-1.149.el6_6.5.x86_64 glibc-common-2.12-1.149.el6_6.5.x86_64 Errors in dmesg: sed[785]: segfault at 0 ip 00000030004c4800 sp 00007fff1b4d04c8 error 6 in libc-2.12.so[3000400000+18a000] sed[792]: segfault at 0 ip 00000030004c4800 sp 00007fffae46a6d8 error 6 in libc-2.12.so[3000400000+18a000] grep[925]: segfault at 2a0 ip 00000030004c2003 sp 00007fffbb544dd0 error 6 in libc-2.12.so[3000400000+18a000] grep[937]: segfault at 2a0 ip 00000030004c2003 sp 00007fff830c0130 error 6 in libc-2.12.so[3000400000+18a000] <hundreds more snipped> Reverting to these versions gives a working system: glibc-2.12-1.149.el6_6.4.x86_64 glibc-common-2.12-1.149.el6_6.4.x86_64 I've mailed Pat & the SL-Devel mailing list, post here: http://listserv.fnal.gov/scripts/wa.exe?A2=ind1501&L=scientific-linux-devel&T=0&P=3229 I'm willing to accept that this *may* be a faulty build from the SL team - but putting this here as a placeholder in case we start seeing more reports from CentOS etc.
(In reply to Josh Baird from comment #14) > The test script provided by Qualys (in the openwall.com post) still reports > that RHEL6/& systems are vulnerable after installing the following packages: With my fully updated RHEL-6 and RHEL-7 systems, I was getting a "vulnerable" result when I checked them with the GHOST-test.sh script referenced in : https://access.redhat.com/labs/ghost/ Long story short, an earlier version of this script had a missing if section which caused the faulty output. I then downloaded the current version and all was well. Just wanted to post this info so others don't waste hours of time. I think it's only fair for RH to make this note (that an earlier version had a problem) on that page rather than silently replacing it.
(In reply to Steven Haigh from comment #20) > I'm willing to accept that this *may* be a faulty build from the SL team - > but putting this here as a placeholder in case we start seeing more reports > from CentOS etc. As an update to the above - it seems to have been a one off occurrence (of which I don't know the cause). After downgrading to older packages, then upgrading again I have been unable to reproduce this on the same system - or a dozen other systems with the same upgrade procedure. Apologies for the false alarm - I'm not sure what actually happened.
Does a statement about RHEL4 exist yet seeing that it is in extended life cycle support still ? (it looks vulnerable)
It appears that compat-glibc is using a vulnerable version of glibc, will it be receiving patches as well?
This issue has been addressed in the following products: Red Hat Enterprise Linux 6.5 EUS - Server and Compute Node Only Red Hat Enterprise Linux 6.4 EUS - Server and Compute Node Only Red Hat Enterprise Linux 6.2 AUS Red Hat Enterprise Linux 5.9 EUS - Server Only Red Hat Enterprise Linux 5.6 Long Life Via RHSA-2015:0099 https://rhn.redhat.com/errata/RHSA-2015-0099.html
The dynamic libraries provided by the compat-glibc package are not vulnerable because they do not provide runtime code. As long as the underlying glibc package is updated then dynamically compiled applications built with compat-glibc will execute the updated and fixed code.
This issue has been addressed in the following products: Red Hat Enterprise Linux 4 Extended Lifecycle Support Via RHSA-2015:0101 https://rhn.redhat.com/errata/RHSA-2015-0101.html
Hello, are there any recommendations on after-update steps ? It is needed to restart any services ? Thank you
Hey there, Just ran yum update on CentOS 6.6 (Kernel 2.6.32-504.3.3.el6.x86_64) glibc.x86_64 0:2.12-1.149.el6_6.5 glibc-common.x86_64 0:2.12-1.149.el6_6.5 glibc-devel.x86_64 0:2.12-1.149.el6_6.5 glibc-headers.x86_64 0:2.12-1.149.el6_6.5 The test script provided by Qualys (in the openwall.com post) reports that those systems are NOT vulnerable anymore.
From my point of view the RHEV-H images were not yet updated, the last update is rhevh-6.5-20150115.0.el6ev.iso (which is also not marked as security one); cross-filed also case #01342828 on the Red Hat customer portal to be sure.
Hello, I wonder if RHEL 6.3 will get this update Current RHSAs doesn't include it
(In reply to Andre from comment #24) > Does a statement about RHEL4 exist yet seeing that it is in extended life > cycle support still ? (it looks vulnerable) As my clients still have quite a few EL4 servers in production, I've done the backporting for the patch and retroffited it into the oldie RHEL glibc RPMs, here are updated packages which (according to the ghost.c test program) are no longer vulnerable: http://www.durval.com/RPMS/el4/glibc_-_FIXES_GHOST_AKA_CVE-2015-0235/ Everything is there, including binaries, the .spec file and the complete src.rpm. so you don't have to trust my packages: you can download the SRPM, open it up with rpm2cpio and compare it to RH's standard RPM it's based on, and after checking that my modifications are legit, produce your own binaries from it with "rpmbuild --rebuild". Hope it helps. Cheers, -- Durval Menezes.
(In reply to Aleksandr Orlov from comment #32) > Hello, > > I wonder if RHEL 6.3 will get this update > Current RHSAs doesn't include it It will not. EUS expired for 6.3 on June 30, 2014: https://access.redhat.com/support/policy/updates/errata/#Extended_Update_Support
(In reply to Durval Menezes from comment #33) > (In reply to Andre from comment #24) > > Does a statement about RHEL4 exist yet seeing that it is in extended life > > cycle support still ? (it looks vulnerable) > > As my clients still have quite a few EL4 servers in production, I've done > the backporting for the patch and retroffited it into the oldie RHEL glibc > RPMs, here are updated packages which (according to the ghost.c test > program) are no longer vulnerable: > > http://www.durval.com/RPMS/el4/glibc_-_FIXES_GHOST_AKA_CVE-2015-0235/ > > Everything is there, including binaries, the .spec file and the complete > src.rpm. so you don't have to trust my packages: you can download the SRPM, > open it up with rpm2cpio and compare it to RH's standard RPM it's based on, > and after checking that my modifications are legit, produce your own > binaries from it with "rpmbuild --rebuild". > > Hope it helps. > > Cheers, > -- > Durval Menezes. Durval, thanks for that.. but I don't suppose you built the i686 version, too.. did ya? How about an el3.i686 version? ;) believe it or not, I still have one el3 box.. ;(
Vincent, my NEEDINFO was set via comment #31 which is IMHO not addressed.
(In reply to Josh Hildebrand from comment #36) > Durval, thanks for that.. but I don't suppose you built the i686 version, > too.. did ya? How about an el3.i686 version? ;) believe it or not, I > still have one el3 box.. ;( Josh, if el3.i386 will do. You might find http://www.nullmx.org/ol3-fixes/ useful. (note, I used the ol4 patch because I had that one to hand easily). Durval, thank you for creating the RHEL4 packages before Redhat did.
By the way, a possible systemtap band-aid for this bug may be found here: https://web.elastic.org/~fche/blog3/archive/2015/02/03/belated-ghostbusting-with-systemtap
This issue has been addressed in the following products: RHEV-H and Agents for RHEL-6 Via RHSA-2015:0126 https://rhn.redhat.com/errata/RHSA-2015-0126.html