Bug 1183461 (CVE-2015-0235) - CVE-2015-0235 glibc: __nss_hostname_digits_dots() heap-based buffer overflow
Summary: CVE-2015-0235 glibc: __nss_hostname_digits_dots() heap-based buffer overflow
Status: CLOSED ERRATA
Alias: CVE-2015-0235
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
urgent
urgent
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard: impact=critical,public=20150127,repor...
Keywords: Security
Depends On: 1183532 1183533 1183534 1183535 1183545 1183549 1183550 1183551 1183552 1183553 1183608 1189850 1189851
Blocks: 1183494
TreeView+ depends on / blocked
 
Reported: 2015-01-19 07:02 UTC by Huzaifa S. Sidhpurwala
Modified: 2019-03-22 07:33 UTC (History)
50 users (show)

(edit)
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.
Clone Of:
(edit)
Last Closed: 2015-01-29 05:22:14 UTC


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:0090 normal SHIPPED_LIVE Critical: glibc security update 2015-01-27 21:06:37 UTC
Sourceware 15014 None None None 2019-03-25 03:06 UTC
Red Hat Product Errata RHSA-2015:0092 normal SHIPPED_LIVE Critical: glibc security update 2015-01-27 23:15:18 UTC
Red Hat Product Errata RHSA-2015:0099 normal SHIPPED_LIVE Critical: glibc security update 2015-01-28 20:50:01 UTC
Red Hat Product Errata RHSA-2015:0101 normal SHIPPED_LIVE Critical: glibc security update 2015-01-28 22:13:00 UTC
Red Hat Product Errata RHSA-2015:0126 normal SHIPPED_LIVE Critical: rhev-hypervisor6 security update 2015-02-04 22:52:31 UTC

Description Huzaifa S. Sidhpurwala 2015-01-19 07:02:19 UTC
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 15:03:14 UTC
Public via:

http://www.frsag.org/pipermail/frsag/2015-January/005722.html

Comment 8 Martin Prpič 2015-01-27 15:42:04 UTC
Acknowledgements:

Red Hat would like to thank Qualys for reporting this issue.

Comment 9 errata-xmlrpc 2015-01-27 16:06:47 UTC
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 16:44:45 UTC
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 18:01:02 UTC
GHOST appears to also affect RHEL 6 and 7.  Are patches being published for those releases?

Comment 13 errata-xmlrpc 2015-01-27 18:16:11 UTC
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 19:01:39 UTC
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 19:17:46 UTC
Those are not the versions currently referenced by RHSA-2015:0092

Comment 16 Josh Baird 2015-01-27 19:35:45 UTC
Oops - sorry for the noise.  Doesn't look like the new packages are available on CDN yet.

Comment 18 Scott Chapman 2015-01-28 00:05:03 UTC
Where's the fix for Enterprise Linux Server 6.6 x86_64?

Comment 19 Mike Myers 2015-01-28 01:08:47 UTC
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 06:42:30 UTC
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 09:04:46 UTC
(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 09:33:11 UTC
(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 11:37:06 UTC
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 13:33:48 UTC
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 15:51:05 UTC
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 16:08:12 UTC
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 17:13:21 UTC
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 17:37:48 UTC
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 17:46:02 UTC
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 11:07:52 UTC
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 13:00:49 UTC
Hello,

I wonder if RHEL 6.3 will get this update
Current RHSAs doesn't include it

Comment 33 Durval Menezes 2015-01-29 16:41:19 UTC
(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 19:08:16 UTC
(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 19:37:39 UTC
(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 20:09:29 UTC
Vincent, my NEEDINFO was set via comment #31 which is IMHO not addressed.

Comment 38 Andre 2015-02-02 17:45:19 UTC
(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-04 02:48:28 UTC
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 17:53:16 UTC
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.