New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
New glibc vulnerability
Abdussamad
Member
Google and Redhat researchers have discovered a new vulnerability in glibc that allows remote code execution:
https://googleonlinesecurity.blogspot.com/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html
Comments
It is the second or third vulnerability in less than a year.
The POC is not working on cPanel servers, just returns normal DNS responses without segmentation faults. It seems that the patch is already applied on them with the daily automatic updates.
thanks for the heads up.
updated my CentOS and Debian VPSes.
I read about it already at BBC news. updated all servers
For anybody interested, these are the patched versions of glibc on Debian and CentOS (along with how to check):
rpm -qa | grep glibc
CentOS 6 = glibc-2.12-1.166.el6_7.7
CentOS 7 = glibc-2.17-106.el7_2.4
dpkg -s libc-bin | grep Version
Debian 6 = 2.11.3-4+deb6u11
Debian 7 = 2.13-38+deb7u10
Debian 8 = 2.19-18+deb8u3
Debian Sid = 2.21-8
Thanks @KuJoe
I got what I needed already, but it took me half an hour to find the name of the Debian7 file to confirm that I was OK after update. Funny how nobody except you seemed to realize that this would be useful.
Yeah, it took some digging for me also which is why I posted it here to save somebody some time. The CentOS versions were posted on their forum after somebody asked them (and after they were told to sign up for their newsletter for the answer).
Im not techie just running apt-get update && apt-get -y upgrade
Arch Linux Security Advisory ASA-201602-14
Severity: Critical
Date : 2016-02-17
CVE-ID : CVE-2015-7547 CVE-2015-8776 CVE-2015-8777 CVE-2015-8778
CVE-2015-8779
Package : glibc
Type : multiple issues
Remote : Yes
Link : https://wiki.archlinux.org/index.php/CVE
Summary
The package glibc before version 2.22-4 is vulnerable to multiple issues
including but not limited to arbitrary code execution, information
disclosure and denial of service.
It is advised to restart all services that may perform DNS lookups.
Resolution
Upgrade to 2.22-4.
pacman -Syu "glibc>=2.22-4"
The problems have been fixed upstream but no release is available yet.
Workaround
None.
Description
A stack-based buffer overflow was found in the way the libresolv library
performed dual A/AAAA DNS queries. A remote attacker could create a
specially crafted DNS response which could cause libresolv to crash or,
potentially, execute code with the permissions of the user running the
library. Note: this issue is only exposed when libresolv is called from
the nss_dns NSS service module.
It was found that out-of-range time values passed to the strftime
function may cause it to crash, leading to a denial of service, or
potentially disclosure information.
LD_POINTER_GUARD was an environment variable which controls
security-related behavior, but was not ignored for privileged binaries
(in AT_SECURE mode). This might allow local attackers (who can supply
the environment variable) to bypass intended security restrictions.
An integer overflow in hcreate and hcreate_r which can result in
an out-of-bound memory access. This could lead to application crashes
or, potentially, arbitrary code execution.
A stack overflow (unbounded alloca) in the catopen function can cause
applications which pass long strings to the catopen function to crash
or, potentially execute arbitrary code.
Impact
A remote attacker is able to execute arbitrary code, potentially
disclosure sensitive information or perform a denial of service attack
via multiple vectors.
References
https://access.redhat.com/security/cve/CVE-2015-7547
https://access.redhat.com/security/cve/CVE-2015-8776
https://access.redhat.com/security/cve/CVE-2015-8777
https://access.redhat.com/security/cve/CVE-2015-8778
https://access.redhat.com/security/cve/CVE-2015-8779
http://seclists.org/oss-sec/2016/q1/153
There is probably so many Odays for GNU/Linux... Dunno if it's really safer than M$ Windows...
That myth has gone down in flames in the recent years
https://www.cvedetails.com/top-50-vendors.php?year=2015
https://www.cvedetails.com/top-50-vendors.php?year=2016
https://www.cvedetails.com/top-50-vendors.php?year=2016
Did not expect that. So Microsoft was more secure that Apple last year...
The number of vulnerabilities does not indicate any particular level of security.
So how do you know for sure you got the patch you need?
Yep!
https://www.cvedetails.com/top-50-vendors.php?year=2016
Right, but that means only known / patched vulnerabilities, isn't it?...
Um don't you have to reboot for the patch to be effective? Don't think just an update & upgrade solves this.
Correct me if I am wrong.
You can use lsof to find all services and applications using libc and then restart these services/apps only. No reboot required.
"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."
Source: https://access.redhat.com/articles/1332213
[edit: fck'd up the formatting.]
That is true but is it "safe" enough? I went with the reboot approach.
And for Ubuntu:
Ubuntu 15.10:
libc6 2.21-0ubuntu4.1
Ubuntu 14.04 LTS:
libc6 2.19-0ubuntu6.7
Ubuntu 12.04 LTS:
libc6 2.15-0ubuntu10.13
In case somebody doesn't know how to check which one is installed, before or after, use this:
ldd --versionNumber of vulnerabilities found doesn't define one product is worse or better.
The fact that apple had the most means that in effect they are patching more security issues and are patching exploits that have been found.
Which I see personally as a good thing.
If we assume that both companies are taking the same efforts to discover issues (although I bet MS, being the company for servers, is taking more actions) then the number of discovered exploits is a very good metric of how a base system was designed. Although, it gets complicated when we have so many variables. I wouldn't consider it to be bad, but defiantly not a good thing in any right.
I think mobile posting got worst somehow...
I've seen some pretty genius(crazy?) Suggestions to mitigate this temporarily, my favorite being limiting DNS inbound/outbound to 512bytes... sigh
@silvenga
I don't think you are correct on that statement at all. Their are numerous issues with IE alone that date back to its initial release that were only found in 2014. To make an argument one is doing better because one does servers is absolutely idiotic.
https://forums.fogproject.org/topic/2702/attention-avoid-internet-explorer-major-exploit-found
To make it simpler, your assumption is absolute shit. Both companies are not taking the same effort to discover issues. Clearly Microsoft is doing diddly if they had an exploit floating around in IE for 12+ years.
MS has been trying to end IE support for years. If anything, the reason why they had so many issue was because they were trying to maintain backwards support of systems created at the birth of the Internet. Very recently, MS is dropping support and starting over and the effects are impressive.
I didn't say MS is more secure because of servers, I said more people are checking because there's more risk. Simplistically, more eyes but less discoveries is a good thing. Less eyes more discoveries is a bad thing. I would say there's more security analysts checking Windows than Mac for exploits right now.
@silvenga
I would still say you are wrong.
Edge is nothing more then rebranded IE.
https://www.cvedetails.com/vulnerability-list/vendor_id-26/product_id-32367/year-2015/Microsoft-Edge.html
Both systems are closed source and so people can't look at the code.
I think more over many of the patches at apple are for iPhones and iOS systems.
Apple iPhones have a huge market when you really consider it, and apple has been making them extremely secure. Even requiring the FBI to request apple to physically alter the device to access the device. That shows that Apple is by far more secure then you think.
https://www.apple.com/customer-letter/
So is the current iOS using the affected glibc?