GHOST: glibc vulnerability (CVE-2015-0235)
Red Hat Product Security has been made aware of a critical vulnerability in the glibc library, which has been assigned CVE-2015-0235 and is commonly referred to as 'GHOST'. All versions of glibc shipped with all variants of Red Hat Enterprise Linux are affected.
Background Information
GHOST is a 'buffer overflow' bug affecting the gethostbyname() and gethostbyname2() function calls in the glibc library. This vulnerability allows a remote attacker that is able to make an application call to either of these functions to execute arbitrary code with the permissions of the user running the application.
Impact
The gethostbyname() function calls are used for DNS resolving, which is a very common event. To exploit this vulnerability, an attacker must trigger a buffer overflow by supplying an invalid hostname argument to an application that performs a DNS resolution.
Determining Vulnerability
As a Red Hat customer, the easiest way to check for the vulnerability and confirm remediation is the Red Hat Access Lab: glibc (GHOST) Detector. Please make sure that you have installed the correct version prior and if you are downloading the package for RHEL 4, you must be subscribed to the ELS channel or have downloaded the ELS version of the package. The RHEL 4 non-ELS subscription version will show a "vulnerable" message.
Resolution
To eliminate the possibility of an exploit:
1. Update the glibc and nscd packages on your system using the packages released with the following errata:
- Red Hat Enterprise Linux Server 5: RHSA-2015:0090
- Red Hat Enterprise Linux Server (v. 6): RHSA-2015:0092
- Red Hat Enterprise Linux Server (v. 7): RHSA-2015:0092
- Red Hat Enterprise Linux Desktop 5: RHSA-2015:0090
- Red Hat Enterprise Linux Desktop 6: RHSA-2015:0092
- Red Hat Enterprise Linux Desktop 7: RHSA-2015:0092
- Red Hat Enterprise Linux HPC Node 6: RHSA-2015:0092
- Red Hat Enterprise Linux HPC Node 7: RHSA-2015:0092
- Red Hat Enterprise Linux Workstation 6: RHSA-2015:0092
- Red Hat Enterprise Linux Workstation 7: RHSA-2015:0092
- Red Hat Enterprise Linux Server EUS (v. 6.6): RHSA-2015:0092
- Red Hat Enterprise Linux Server EUS (v. 6.5): RHSA-2015:0099
- Red Hat Enterprise Linux Server EUS (v. 6.4): RHSA-2015:0099
- Red Hat Enterprise Linux Server EUS (v. 5.9): RHSA-2015:0099
- Red Hat Enterprise Linux ELS (v. 4): RHSA-2015:0101
- An active ELS subscription is required for access to this patch in RHEL 4. (What is the Red Hat Enterprise Linux Extended Life Cycle Support Add-On (ELS)?)
- Please contact Red Hat sales or your specific sales representative for more information if your account does not have an active ELS subscription: Contact Sales.
2. Reboot the system or restart all affected services:
Because this vulnerability affects a large amount of applications on the system, the safest and recommended way to assure every application uses the updated glibc packages is to restart the system.
In case you are unable to restart the entire system after applying the update, execute the following command to list all running processes (not restricted to services) still using the old [in-memory] version of glibc on your system.
lsof +c0 -d DEL | awk 'NR==1 || /libc-/ {print $2,$1,$4,$NF}' | column -t
From the resulting list, identify the public-facing services and restart them. While this process may work as a temporary workaround, it is not supported by Red Hat and, should a problem arise, you will be requested to reboot the system before any troubleshooting begins.
73 Comments
Hello RedHat support,
We have multiple RHEL versions in our env, how we should process GHOST fixup, if we have running in parallel
5.1, 5.2, 5.4, 5.8, and 6.5
For 6.5 I see that yum should do the job, but what about outdated 5.x versions? Can we update only glibc, or firs we have to update to latest 5.x branch?
You only need to update glibc
Is it affected? Not in the list of errata in the article.
Installed glibc version(s)
- glibc-2.5-81.el5_8.2.i686: vulnerable
This system is vulnerable to CVE-2015-0235. https://access.redhat.com/security/cve/CVE-2015-0235
Please refer to https://access.redhat.com/articles/1332213 for remediation steps
[root@coalmont86 chuach]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.8 (Tikanga)
Yes, it's packages needs to be updated.
What about this? Not in the list.
Installed glibc version(s)
- glibc-2.12-1.80.el6.x86_64: vulnerable
- glibc-2.12-1.80.el6.i686: vulnerable
This system is vulnerable to CVE-2015-0235. https://access.redhat.com/security/cve/CVE-2015-0235
Please refer to https://access.redhat.com/articles/1332213 for remediation steps
[root@coalgood81 rightaccess]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.3 (Santiago)
Hi RedHat team,
we don't have satellite server and internet on server's
Is there any way to download and install these package?
rpm -q glibc
glibc-2.12-1.107.el6.x86_64
glibc-2.12-1.107.el6.i686
cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.4 (Santiago)
uname -a
Linux lnx-indusmed1 2.6.32-358.el6.x86_64 #1 SMP Tue Jan 29 11:47:41 EST 2013 x86_64 x86_64 x86_64 GNU/Linux
Download and install the following packages from the portal:
- glibc-2.12-1.149.el6_6.5.x86_64
- glibc-2.12-1.149.el6_6.5.i686
- glibc-common-2.12-1.149.el6_6.5.x86_64
- glibc-devel-2.12-1.149.el6_6.5.x86_64
- glibc-headers-2.12-1.149.el6_6.5.x86_64
- nscd-2.12-1.149.el6_6.5.x86_64
If you just want to update your system regarding GHOST vulnerability :
yum update glibc* -y && reboot
What is the correct CLI syntax to download the script for the glibc GHOST detector, running RHEL 7 x64 please.
Thank you
Hi Terry,
You can use, for example:
Are RHEL 3 and RHEL4 systems vulnerable? If they are, when will a fix be available for them?
Thanks
Hi Beverley, RHEL 3 ELS reached end of life on January 30, 2014 and is thus no longer supported; it will not receive any updates. A fix for RHEL 4 ELS is available via RHSA-2015:0101.
Sorry, when I click respond, I get a full page of code, anyway, I can download the script, locate it on the server but I'm unable to run it. The server returns: command not found, (capitals correct) I've logged in at sudo, tried ./ GHOST-test.sh that others have posted. (Permission denied) or (No such file or directory) What is the default CLI command after retrieving the file using:
wget https://access.redhat.com/labs/ghost/GHOST-test.sh?
thank you
Hi Terry,
Did you make the script executable? The instructions are on the lab page.
We have EUS on our RHEL 3 servers. Doesn't that mean you fix secure vulnerabilities like this?
Thanks
Beverley, RHEL 3 has been unsupported for one year exactly today. Please see our support policy:
https://access.redhat.com/support/policy/updates/errata/#Life_Cycle_Dates
When a product version reaches its end of life, we do not provide any updates for it.
The C code at http://www.cyberciti.biz/faq/cve-2015-0235-patch-ghost-on-debian-ubuntu-fedora-centos-rhel-linux/ named ghosttest.c seems a better test of the exploit. JUst saying...Trust but verify,.
Thanks Robert, Sorry to add new comments, I can't reply for some reason. So, I've made the script executable, and whn I run it, I get:'
./GHOST-test.sh: line 1: syntax error near unexpected token 'newline'
./GHOST-test.sh: line 1: `
Thanks
Terry, so sorry to have misled you before. Unfortunately, you only downloaded a webpage telling you that you need to log in. Which is why you got that error when trying to run the script. Please, use the following command to download it:
Substitute 'username' and 'password' with your Customer Portal credentials. This should download the script file properly. Just to be on the safe side, please run
head -1 GHOST-test.shafter you download it. It should show#!/bin/bash.Then you need to make the file executable again, or just run it directly with:
Thank you very much. I learn from everything.
I'll post results when I'm done, hopefully will help the novice like myself!
The information in RHSA-2015:0090-1 (https://rhn.redhat.com/errata/RHSA-2015-0090.html) pertaining which versions of glibc and nscd are needed to fix this issue are incorrect!
The document states to update to glibc-2.5-123.el5. Running the GHOST-test.sh reveals:
[testusr@rhel5dev ~]# rpm -qa | sort | grep glibc
glibc-2.5-123
glibc-2.5-123
glibc-common-2.5-123
glibc-devel-2.5-123
glibc-devel-2.5-123
glibc-headers-2.5-123
[testusr@rhel5dev ~]# rpm -qa | sort | grep nscd
nscd-2.5-123
[testusr@rhel5dev ~]# /home/testusr/glibc/GHOST-test.sh
Installed glibc version(s)
- glibc-2.5-123.x86_64: vulnerable
- glibc-2.5-123.i686: vulnerable
This system is vulnerable to CVE-2015-0235. https://access.redhat.com/security/cve/CVE-2015-0235
Please refer to https://access.redhat.com/articles/1332213 for remediation steps
What are the RHEL5 updates that actually patch this issue?
The fix is in "glibc-2.5-123.el5_11.1."
Hi Team,
All my servers are RHEL5.5 - I have tried downloading the errata RPMs and updating it (rpm -Uvh glibc-* nscd*), but facing the below library dependency issue. Can you please provide the "base URL" path for the repository configuration to update the glibc using "yum update".
Error :
error: Failed dependencies:
libc.so.6.1()(64bit) is needed by nscd-2.5-123.el5_11.1.ia64
libc.so.6.1(GLIBC_2.2)(64bit) is needed by nscd-2.5-123.el5_11.1.ia64
libc.so.6.1(GLIBC_2.2.2)(64bit) is needed by nscd-2.5-123.el5_11.1.ia64
libc.so.6.1(GLIBC_2.2.4)(64bit) is needed by nscd-2.5-123.el5_11.1.ia64
libc.so.6.1(GLIBC_2.3)(64bit) is needed by nscd-2.5-123.el5_11.1.ia64
libc.so.6.1(GLIBC_2.3.2)(64bit) is needed by nscd-2.5-123.el5_11.1.ia64
libc.so.6.1(GLIBC_2.3.4)(64bit) is needed by nscd-2.5-123.el5_11.1.ia64
libc.so.6.1(GLIBC_2.4)(64bit) is needed by nscd-2.5-123.el5_11.1.ia64
libnsl.so.1(GLIBC_2.1)(64bit) is needed by nscd-2.5-123.el5_11.1.ia64
libpthread.so.0(GLIBC_2.2)(64bit) is needed by nscd-2.5-123.el5_11.1.ia64
librt.so.1(GLIBC_2.2)(64bit) is needed by nscd-2.5-123.el5_11.1.ia64
Please open a support case, attaching the sosreport from the server in question.
I realise that RHEL 3 has reached EOL. But we purchase "Red Hat Enterprise Linux Extended Life Cycle" support for these servers. I was under the impression that this meant we would still be able to get fixes for critical vulnerabilities. If this is not the case, what does extended life cycle subdcription give us?
Thanks
RHEL 3 's extended life cycle support phase got over by January 2014. You can use ELS subscription for obtaining critical updates for RHEL4.
Refer the below url for more information
https://access.redhat.com/support/policy/updates/errata/
From the page I linked above, you can see that Extended Lifecycle Support (ELS) started on October 31, 2010 and ended at said January 30, 2014. As much as we'd like to support all of our products for ever, even the most extended support offerings have an expiration date, which means no more updates :-) Your best bet is upgrading to a newer version of RHEL. RHEL 4 currently offers ELS until March 31, 2017.
I have RHEL 4 servers but when i do up2date -l glibc it says that the server is already up to date but when running the GHOST-test.sh script it says that it is vulnerable.
cat /etc/redhat-release
Red Hat Enterprise Linux ES release 4 (Nahant Update 9)
rpm -qa glibc
glibc-2.3.4-2.57
up2date -l glibc
Fetching Obsoletes list for channel: rhel-i386-es-4...
Fetching rpm headers...
Name Version Rel Arch
The following packages you requested are already updated:
glibc
./GHOST-test.sh
Installed glibc version(s)
- glibc-2.3.4-2.57.i686: vulnerable
any ideas
Larry
Do you have Red Hat Enterprise Linux 4 Extended lifecycle support subscription ?. If not, then you need this subscription to access the latest updates.
Please contact Sales if you do not have the subscription http://www.redhat.com/en/about/contact/sales . If you are not able to update the package inspite of having the ELS subscription, then please contact Red Hat Technical Support
I have a selection of servers that have no connection to the internet.
The O/S versions include 5.4 , 5.7, 6.0, 6.1, 6.3, 6.4, 6.5 and 6.6 so I have downloaded the
recommended packages from RHSA-2015:0090-1 & RHSA-2015:0092-1 and am using
"yum localinstall ..." to apply the security fix(es).
First off: Am I doing something stupid in the above approach or is it valid?
Some servers have worked fine but there seems to be something missing in that list as if I try
to patch a server running 2.6.32-279.el6.i686 then although it will (reasonably) not accept any
x86_64 rpms, it still requires glibc-common-2.12-1.149.el6_6.5 and there is no .i686 version listed.
Can anyone straighten me out on this please?
Thanks,
Frank
Hi Frank,
To answer your first question: there's nothing wrong in that approach.
Regarding the second question: if you trying apply updates on a 32bit version of RHEL, ensure the download the following dependencies:
Download and install the following packages from the portal:
- glibc-common
- glibc-devel
- glibc-headers
- nscd
And install them in one go, ie "yum locainstall glibc glibc-common....
Hi Sibu,
That worked fine - thanks!
Frank
Would this patch have any chance to cause apps (Oracle, Websphere, etc) to misbehave?
What sort of testing would be wise during patch rollout aside from the glibc/nscd version check?
Given a range of RH5 and RH6 systems, the onus is on me to assure the patch will do no harm to all current production apps, aside from the reboot. a statement from Redhat would be very helpful.
There can be application impacts if they are not compatible with the glibc-* upgrades.
This should not happen in most cases. The times that it could happen is if a very old glibc version is in use. We don't expect that there should be a problem, but if you are concerned please review the application compatibility guide:
Red Hat Enterprise Linux: Application Compatibility GUIDE
https://access.redhat.com/articles/rhel-abi-compatibility
Last Friday, the packages for 2015:0101 were available through this search: https://access.redhat.com/products/red-hat-enterprise-linux/errata#?&col=portal_errata&language=All&keyword=2015:0101&portal_product=Red+Hat+Enterprise+Linux
Now that search comes up empty. A search for RHEL v4 and glibc at that site also comes up emtpy. I have ELS access. I want to download the packages, not use up2date directly via RHN. Where can I get the RHEL v4 ELS updates for CVE 2015-0235?
Hello,
I have a server that have no connection to the internet.
The O/S versions is 5.4 ,so I downloaded the recommended packages from RHSA-2015:0090
glibc-2.5-123.el5_11.1.i386.rpm
glibc-2.5-123.el5_11.1.i686.rpm
glibc-common-2.5-123.el5_11.1.i386.rpm
glibc-devel-2.5-123.el5_11.1.i386.rpm
glibc-headers-2.5-123.el5_11.1.i386.rpm
glibc-utils-2.5-123.el5_11.1.i386.rpm
nscd-2.5-123.el5_11.1.i386.rpm
and I used to apply the security fix(es) to force the circular dependencies.
$ rpm -Fvh glibc*
$ rpm -Fvh nscd*
But it gave the errors bellow due to dependencies I think.
rpm - Fvh glibc*
attention: glibc-2.5-123.el5_11.1.i386.rpm: Entete V3 DSA signature: NOKEY, key ID 37017186
attention: package glibc = 2.5-123.el5_11.1 was already added, skipping glibc < 2.5-123.el5_11.1
erreur: Dependances requises:
glibc = 2.5-42 est necessaire pour (deja installé) nscd-2.5-42.i386
rpm -Fvh nscd*
attention : nscd-2.5-123.el5_11.1.i386.rpm: Entete V3 DSA signature : NOKEY, key ID 37017186
erreur; Dependances requises:
glibc = 2.5-123.el5_11.1 est necessaire pour nscd-2.5-123.el5_11.1.i386
What is the best way to apply those erradata and the command to do that?
Can anyone advise me on this please?
Thanks,
Ismail
Hi Ismail,
Please try as below:
rpm -Fvh glibc*
It gives the same error as I mentionned on my first post
rpm -Fvh glibc*
attention: glibc-2.5-123.el5_11.1.i386.rpm: Entete V3 DSA signature: NOKEY, key ID 37017186
attention: package glibc = 2.5-123.el5_11.1 was already added, skipping glibc < 2.5-123.el5_11.1
erreur: Dependances requises:
glibc = 2.5-42 est necessaire pour (deja installé) nscd-2.5-42.i386
Hi Ismail,
Sorry there was a typo in my command. Please run the below:
rpm -Fvh glibc* nscd*
If the issue persist, please open a support case.
Hello,
I managed to get the dependencies working with this command #yum localinstall *.rpm
but I got only one dependency missing with glibc-utils, the libgd.so.2.
Can you tell me what package contain this library?
regards
Hello Salah,
Try this: # yum search libgd
It shows the following:
============================================================================ Matched: libgd ============================================================================
gd.i686 : A graphics library for quick creation of PNG or JPEG images
gd.x86_64 : A graphics library for quick creation of PNG or JPEG images
gnome-utils-libs.i686 : gnome-utils libraries
gnome-utils-libs.x86_64 : gnome-utils libraries
Hi,
I have a problem performing the manual update, when i try to update, it shows conflict as below:-
rpm -q glibc
glibc-2.5-42
glibc-2.5-42
rpm -q glibc-common
glibc-common-2.5-42
rpm -ivh glibc-2.5-123.el5_11.1.i686.rpm
warning: glibc-2.5-123.el5_11.1.i686.rpm: Header V3 DSA signature: NOKEY, key ID 37017186
error: Failed dependencies:
glibc-common = 2.5-123.el5_11.1 is needed by glibc-2.5-123.el5_11.1.i686
rpm -ivh glibc-common-2.5-123.el5_11.1.x86_64.rpm
.......(truncated)
from install of glibc-common-2.5-123.el5_11.1.x86_64 conflicts with file from package glibc-common-2.5-42.x86_64
What is the correct way to perform a manual update?
Thanks and regards,
Kwan
As per the information that you have shown in your post, you need to download both 32bit and 64 bit version of glibc and 64 bit version of glibc-common
After downloading the above package use rpm -Uvh <pkgname1.rpm> <packagemam2.rpm> <packagename-3.rpm>
If you are still noticing any issues, then I would recommend you to contact Red Hat Technical Support
Hello Kwan,
Try rpm -Uvh instead of -ivh since the package is already installed
Please post "rpm -qa glibc" output so the packages installed and their architectures can be reviewed.
Hello
Please help!
We want to download glibc-devel-2.3.4-2.57.el4.2.i386.rpm, where can we find it ?
We has a ELS.
Thanks
Can you contact Red Hat Technical Support so that we can provide you with the required download url
Hello Ranjith Rajaram
How can I contact Red Hat Technical Support ? By mail or by phone ?
I am a new one , so please show me some more detail information.
Thanks
Hello
Via Web:
Access https://access.redhat.com/home
You should see "open a support case" option
Via Phone
https://access.redhat.com/support/contact/technicalSupport
download URL for glibc-devel-2.3.4-2.57.el4.2.i386.rpm
https://access.redhat.com/downloads/content/rhel---4/x86_64/1826/glibc-devel/2.3.4-2.57.el4.2/i386/db42a60e/package
Please contact Technical support if you notice any dependency issues
Hello Ranjith Rajaram
Thanks a lot.
I accessed URL you listed, and found glibc-devel-2.3.4-2.57.el4.2.i386.rpm.
Hello Ranjith Rajaram
Now I have understood what I should do.
I downloaded all rpms that lised on https://rhn.redhat.com/errata/RHSA-2015-0101.html for x86_64 platform.
Hi ,
I am facing issue while doping manual update ,
[root@opscenter opscenter]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.8 (Tikanga)
[root@opscenter opscenter]# uname -i
x86_64
So I have downloaded and updated the x86_64 glibc packages with depencies..
[root@opscenter opscenter]# rpm -q glibc
glibc-2.5-81
glibc-2.5-123.1
[root@opscenter opscenter]# ./GHOST-test.sh
Installed glibc version(s)
- glibc-2.5-81.i686: vulnerable
- glibc-2.5-123.1.x86_64: not vulnerable
This system is vulnerable to CVE-2015-0235. https://access.redhat.com/security/cve/CVE-2015-0235
Please refer to https://access.redhat.com/articles/1332213 for remediation steps
Now the package with i686 showing vulnerable , So I have downloaded i686 glibc package and tried to install it but receiving below error,
[root@opscenter opscenter]# rpm -Uvh glibc-2.5-123.el5_11.1.i686.rpm --nodeps
warning: glibc-2.5-123.el5_11.1.i686.rpm: Header V3 DSA signature: NOKEY, key ID 37017186
Preparing... ########################################### [100%]
package glibc-2.5-123.1.x86_64 (which is newer than glibc-2.5-123.el5_11.1.i686) is already installed
Kindly help me on the same .Thanks in advance.
You should never use nodeps especially when upgrading glibc packages.
Looking at this information
[root@opscenter opscenter]# rpm -q glibc
glibc-2.5-81
glibc-2.5-123.1
Looks like you have already upgraded the glibc package without resolving the dependencies
From where did you download glibc-2.5-123.1.x86_64 package ?. I did a quick search I can't seem to find it in our Red Hat customer portal
It would request you to contact Red HatTechnical support so that we can resolve the request as it needs a little bit of care
I have upgraded the dependencies packages also
[root@opscenter opscenter]# rpm -qa | grep glibc
glibc-2.5-81
glibc-devel-2.5-123.1
glibc-utils-2.5-81
compat-glibc-2.3.4-2.26
glibc-2.5-123.1
glibc-common-2.5-123.1
glibc-headers-2.5-123.1
compat-glibc-headers-2.3.4-2.26
compat-glibc-2.3.4-2.26
glibc-devel-2.5-81
I have upgraded the below mentioned packages,
[root@opscenter opscenter]# ls -ltr /usr/src/redhat/RPMS/x86_64/
total 87164
-rw-r--r-- 1 root root 5015812 Feb 10 13:40 glibc-2.5-123.1.x86_64.rpm
-rw-r--r-- 1 root root 627069 Feb 10 13:40 glibc-headers-2.5-123.1.x86_64.rpm
-rw-r--r-- 1 root root 2548275 Feb 10 13:40 glibc-devel-2.5-123.1.x86_64.rpm
-rw-r--r-- 1 root root 181401 Feb 10 13:41 nscd-2.5-123.1.x86_64.rpm
-rw-r--r-- 1 root root 142958 Feb 10 13:41 glibc-utils-2.5-123.1.x86_64.rpm
-rw-r--r-- 1 root root 17444754 Feb 10 13:41 glibc-common-2.5-123.1.x86_64.rpm
I have downloaded the sorce rpm from redhat ftp site only..
Vinayak
Not sure why you download the source package instead of directly downloading the relevant rpms (i386/x86_64) from the portal.
When you compiled the package, the version of the package has been changed. The compiled package is technically one version higher than what is shipped with RHEL5
This is why you are getting the following message
"package glibc-2.5-123.1.x86_64 (which is newer than glibc-2.5-123.el5_11.1.i686) is already installed"
So now you have downloaded the i686 version from the portal. Same way you could have downloaded the relevant x86_64 version from portal for RHEL5 instead of compiling it from source provided you are not including any other custom patches
There is an option --oldpackage which can be used with the rpm command. I wouldnt recommend to use it as of now as you might get other warnings
I would request you to contact Red Hat Technical support so that we can help you to revert the packages and upgrade the glibc i686 packages
JFYI
As per Red Hat SLA, Red Hat does not provide support for issues that arises from the usage of custom compiled packages.
Support is not provided even if you use the source package provided by Red Hat. SLA for reference https://access.redhat.com/support/offerings/production/soc [Custom compiled rpms are considered as modified rpm's]
Hi Ranjith ,
Now we are doing it in the testing phase only . Once it gets upgraded correctly we will move to production.For this issue case has been raised.
So for all other servers we have to do manual upgrade only .
I have try to upgrade in different server without --nodeps option as given below,
$ rpm -Uvh glibc-2.5-123.el5_11.1.x86_64.rpm
warning: glibc-2.5-123.el5_11.1.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 37017186
error: Failed dependencies:
glibc-common = 2.5-123.el5_11.1 is needed by glibc-2.5-123.el5_11.1.x86_64
$ rpm -Uvh glibc-common-2.5-123.el5_11.1.x86_64.rpm
warning: glibc-common-2.5-123.el5_11.1.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 37017186
error: Failed dependencies:
glibc-common = 2.5-81 is needed by (installed) glibc-2.5-81.x86_64
glibc-common = 2.5-81 is needed by (installed) glibc-2.5-81.i686
So kindly guide us steps to do manual upgrade and also dependency packages issues.
Since you have raised a case, you will get further help from our Technical support. Lets dont use kbase comment option for support
This is what I would do
find all the glibc packages on the system
update the packages together
Hi Ranjith,
Thanks for the help. Successfully upgraded the packages.
rpm -qa |grep ^glibc
glibc-devel-2.5-123.el5_11.1
glibc-utils-2.5-123.el5_11.1
glibc-devel-2.5-123.el5_11.1
glibc-headers-2.5-123.el5_11.1
glibc-2.5-123.el5_11.1
glibc-2.5-123.el5_11.1
glibc-common-2.5-123.el5_11.1
And also checked with GHOST script,
./GHOST-test.sh
Installed glibc version(s)
- glibc-2.5-123.el5_11.1.x86_64: not vulnerable
- glibc-2.5-123.el5_11.1.i686: not vulnerable
Kindly let us know , Is the reboot is must.
Because we have to follow this for all production servers and it will cause more downtime. Or else any other way is there instead of reboot.
In the above kbase article, we have covered this topic under the heading "2. Reboot the system or restart all affected services"
I would recommend to reboot the system
It would be beneficial to update the tzdata package on the system to cover the leap second event as well
Refer: https://access.redhat.com/solutions/1317263
Hi Team,
We are facing below error on our environment after updating the glibc package.
Redhat Case 01362449
Larry
Very less likely to be a glibc issue. Thank you for opening a support request
Hi,
We have a internal yum repository which I have reposync'd to get all the latest updates
When we run yum update gblic on our Red Hat 6.5 clients
It only says glib version glibc-2.12-1.149.el6 which is reported as vulnerable
We need it to update to glibc-2.12-1.149.el6_6.5
Any ideas?
I have tried yum clean all and tried it on 2 different clients
Have you verified that the reposync has pulled all the latest packages
If the download path is /var/www/html, did you execute createrepo --update after reposync
example: createrepo --update /var/www/html
I have a RHEL 5.7 Server, a 5.2, a 5.9, etc. Did a "yum update glibc" on them all, and this package was installed: glibc-2.5-123.el5_11.1.x86_64.rpm. The script now reports that all the servers are not vulnerable anymore.
I've always thought that it was OK to install a RPM with a newer minor, as long it was in the same RHEL distro version. Example: Installing a 6_6 rpm in a 6_2 server.
But as I read this comments I find out that this is not advisable. But it can be done anyway!? God, this is so confusing!
Hi,
Is there a patch available for glibc-2.5-117 for x86_64 RHEL server 5.10?
Thanks
On your RHEL 5.10 system run the following command to determine if there is an update for glibc:
yum list update glibc
This should tell you if a patch is available. I observed on other versions including older 5.x versions that updates were available.
My server corrupted two times during glibc patching upgrading,The server stuck with segmentation fault and unable to boot.
Any body can share the reason
Please open a support case to investigate the issue.
Hi,
Based on this articele could you clarify whether this will affect Apache webser.What temporaly solution can be done apart from patching.
We had an issue of segmentation fault during upgrading glibc package to RHEL 5.9(32BIT) and as a result OS corrupted.
It is impossible for us to get sosreport after system corrupted
Apache server is also affected. There are no temporary workarounds. We could try to recover the system from rescue mode. It would be better to contact Red Hat Technical Support
Correction: Apache is not directly affected but can be used to exploit the vulnerability in glibc , Any application that uses gethostbyname. If you have a php application hosted in your webserver that ends up calling gethostbyname() can be used by a remote attacker to exploit the glibc vulnerability
Hi,
I used rpm -uvh xxx to upgrade the patch in rhel 5.9.When execute the command can see the status of the updating,But suddenly it is giving segmentation fault and as a result OS corrupted.Our server running with xen package installed and two vm on the physical server.
Kia, this is not something anyone can troubleshoot with you via a knowledgebase article. Please open a support case.
Hi ,
I had sementation fault issue during glibc upgrade .
This is the affected server(Linux myedu3fe1 2.6.18-371.9.1.el5xen #1 SMP Tue May 13 06:59:31 EDT 2014 i686 i686 i386 GNU/Linux).This is a VM
This is server abled to updated sucessfully(Linux myedu3db2 2.6.18-402.el5PAE #1 SMP Thu Jan 8 06:43:53 EST 2015 i686 i686 i 386 GNU/Linux).This is physical server
Is there any difference between causing segmentation fault.
Pages