Bug 1183461 - (CVE-2015-0235) CVE-2015-0235 glibc: __nss_hostname_digits_dots() heap-based buffer overflow
CVE-2015-0235 glibc: __nss_hostname_digits_dots() heap-based buffer overflow
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
urgent Severity urgent
: ---
: ---
Assigned To: Red Hat Product Security
impact=critical,public=20150127,repor...
: Security
Depends On: 1183532 1183533 1183534 1183535 1183545 1183549 1183550 1183551 1183552 1183553 1183608 1189850 1189851
Blocks: 1183494
  Show dependency treegraph
 
Reported: 2015-01-19 02:02 EST by Huzaifa S. Sidhpurwala
Modified: 2016-09-29 10:05 EDT (History)
50 users (show)

See Also:
Fixed In Version: glibc 2.18
Doc Type: Bug Fix
Doc Text:
A heap-based buffer overflow was found in glibc's __nss_hostname_digits_dots() function, which is used by the gethostbyname() and gethostbyname2() glibc function calls. A remote attacker able to make an application call either of these functions could use this flaw to execute arbitrary code with the permissions of the user running the application.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-01-29 00:22:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Sourceware 15014 None None None Never

  None (edit)
Description Huzaifa S. Sidhpurwala 2015-01-19 02:02:19 EST
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.
Comment 7 Huzaifa S. Sidhpurwala 2015-01-27 10:03:14 EST
Public via:

http://www.frsag.org/pipermail/frsag/2015-January/005722.html
Comment 8 Martin Prpic 2015-01-27 10:42:04 EST
Acknowledgements:

Red Hat would like to thank Qualys for reporting this issue.
Comment 9 errata-xmlrpc 2015-01-27 11:06:47 EST
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
Comment 10 Tomas Hoger 2015-01-27 11:44:45 EST
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).
Comment 12 Gordon Messmer 2015-01-27 13:01:02 EST
GHOST appears to also affect RHEL 6 and 7.  Are patches being published for those releases?
Comment 13 errata-xmlrpc 2015-01-27 13:16:11 EST
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
Comment 14 Josh Baird 2015-01-27 14:01:39 EST
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?
Comment 15 Gordon Messmer 2015-01-27 14:17:46 EST
Those are not the versions currently referenced by RHSA-2015:0092
Comment 16 Josh Baird 2015-01-27 14:35:45 EST
Oops - sorry for the noise.  Doesn't look like the new packages are available on CDN yet.
Comment 18 Scott Chapman 2015-01-27 19:05:03 EST
Where's the fix for Enterprise Linux Server 6.6 x86_64?
Comment 19 Mike Myers 2015-01-27 20:08:47 EST
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
Comment 20 Steven Haigh 2015-01-28 01:42:30 EST
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.
Comment 21 Akemi Yagi 2015-01-28 04:04:46 EST
(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.
Comment 22 Steven Haigh 2015-01-28 04:33:11 EST
(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.
Comment 24 Andre 2015-01-28 06:37:06 EST
Does a statement about RHEL4 exist yet seeing that it is in extended life cycle support still ? (it looks vulnerable)
Comment 25 Eric Warnke 2015-01-28 08:33:48 EST
It appears that compat-glibc is using a vulnerable version of glibc, will it be receiving patches as well?
Comment 26 errata-xmlrpc 2015-01-28 10:51:05 EST
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
Comment 27 Josh Bressers 2015-01-28 11:08:12 EST
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.
Comment 28 errata-xmlrpc 2015-01-28 12:13:21 EST
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
Comment 29 Dex 2015-01-28 12:37:48 EST
Hello,

are there any recommendations on after-update steps ?

It is needed to restart any services ?

Thank you
Comment 30 Rob@Eire 2015-01-28 12:46:02 EST
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.
Comment 31 Robert Scheck 2015-01-29 06:07:52 EST
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.
Comment 32 Aleksandr Orlov 2015-01-29 08:00:49 EST
Hello,

I wonder if RHEL 6.3 will get this update
Current RHSAs doesn't include it
Comment 33 Durval Menezes 2015-01-29 11:41:19 EST
(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.
Comment 35 Vincent Danen 2015-01-29 14:08:16 EST
(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
Comment 36 Josh Hildebrand 2015-01-29 14:37:39 EST
(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.. ;(
Comment 37 Robert Scheck 2015-01-29 15:09:29 EST
Vincent, my NEEDINFO was set via comment #31 which is IMHO not addressed.
Comment 38 Andre 2015-02-02 12:45:19 EST
(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.
Comment 39 Frank Ch. Eigler 2015-02-03 21:48:28 EST
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
Comment 40 errata-xmlrpc 2015-02-04 12:53:16 EST
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

Note You need to log in before you can comment on or make changes to this bug.