GHOST glibc Linux Remote Code Execution Vulnerability / gethostbyname CVE-2015-0235

[SeLLeRoNe]

Ok, thank you

Regards

 

[ditto]

Is the reboot required after the update?

GLIBC GHOST - do you really have to reboot? http://cloudlinux.com/blog/clnews/614.php

 

[SeLLeRoNe]

So my guess was valid xD

Not a big issue, a reboot last night took 3mins... no one noticed it xD

Regards

 

[Richard G]

I was just wondering.
It was said this security flaw was already present since 2010 and fixed with a glibc update later on. Only thing was they did not know there was an issue they fixed.
You can also read this in the statements:

We identified a number of factors that mitigate the impact of this
bug. In particular, we discovered that it was fixed on May 21, 2013
(between the releases of glibc-2.17 and glibc-2.18).

So am I correct nobody's vulnarable, as long as they upgraded their OS everytime (like doing a weekly yum update and update kernels and glibc etc. etc.)?

 

[Arieh]

I was just wondering.
It was said this security flaw was already present since 2010 and fixed with a glibc update later on. Only thing was they did not know there was an issue they fixed.
You can also read this in the statements:

So am I correct nobody's vulnarable, as long as they upgraded their OS everytime (like doing a weekly yum update and update kernels and glibc etc. etc.)?

It says right after that:

Unfortunately, it
was not recognized as a security threat; as a result, most stable and
long-term-support distributions were left exposed (and still are):
Debian 7 (wheezy), Red Hat Enterprise Linux 6 & 7, CentOS 6 & 7,
Ubuntu 12.04, for example.

So everyone using normal yum updates were vulnerable, up to a few days ago when they updated the packages.

 

[Richard G]

Well that's the part i don't understand.
I thought those systems were left explosed because maybe a lot of admins don't update with yum.

So what I don't understand is.... it's fixed in 2013, but not recognized as a thread. But it -is- fixed. So if you upgraded in 2013 to that fixed version, how can there be systems left exposed?
Isn't it so that this can only happen if people did not upgrade to that new glibc in 2013?

I don't quite understand this, looks contradictory to me (or how do you say that in English).

Just in Dutch because I know you understand this.
Als er dus in 2013 een nieuwe versie was met een fix, dan maakt het toch niet uit of ze wel of niet weten dat ze een gat gefixed hebben? Die nieuwe versie van 2013 is dan toch een gefixte versie, als je glibc toen dus geupdate hebt, moet je toch veilig zijn?
Daarom snap ik dat tweede deel tekst niet. Dacht dat 2de deel alleen betrekking had op admins die installeren en nadien niet meer updaten.

 

[Arieh]

I think you'll get it in English

Distributions like CentOS Debian etc don't use clean releases of software in their packages, they maintain them themselves. That way people can install it faster, the software is modified to fit the OS its standards, paths and updating things.

So if there are updates for the software/libraries etc. They often just take the specific changes in the updates and apply them to their own packages. For instance it is fixed in glibc 2.18, but Debian 7 most recent package is 2.13-38+deb7u7, in which they fixed the bug.

 

[ben29]

now new kernel has been released:
for centos 7
kernel-3.10.0-123.20.1.el7

 

[Richard G]

@Arieh: Aha, like that. No sorry I did not know that they only took out what was needed. I thought if there were upgrades, it was updated as fully as possible, but only make them compatible to work under their OS.
It seems I was wrong. And now I do understand why it was still vulnarable. Thank you for explaining. Indeed I understood this in English too.