Linux Systems Patched for Critical glibc Flaw

[RV_]

This one is being reported by the Linux.com and other Linux folks as a critical vulnerability that has just been patched after a 2008 patch for a new vulnerability still in most Linux systems and servers. I start with the more technical descriptions and articles from Linux.com and EWEEK, then more mainstream articles for newcomers to Linux.

 

Excerpt:

 

"Google exposed a critical flaw affecting major Linux distributions. The glibc flaw could have potentially led to remote code execution.

 

Linux users today are scrambling to patch a critical flaw in the core glibc open-source library that could be exposing systems to a remote code execution risk. The glibc vulnerability is identified as CVE-2015-7547 and is titled, "getaddrinfo stack-based buffer overflow."

 

In many cases in Linux, the Security Enhanced Linux (SELinux) mandatory access security controls can mitigate the risk of potential vulnerabilities, but that's not the case with the new glibc issue.

 

"The risk is a compromise of important system functionality due to the execution of arbitrary code supplied by an attacker," Weimer said. "A suitable SELinux policy can contain some of the damage an attacker might do and constrain their access to the system, but DNS is used by many applications and system components, so SELinux policies offer only limited containment for this issue."

 

That whole article with much more is here: http://www.eweek.com/security/linux-systems-patched-for-critical-glibc-flaw.html

 

Other Sources:

 

From Linux.com "Linux Systems Patched for Critical glibc Flaw"

 

"Google exposed a critical flaw affecting major Linux distributions. The glibc flaw could have potentially led to remote code execution.

 

Linux users today are scrambling to patch a critical flaw in the core glibc open-source library that could be exposing systems to a remote code execution risk. The glibc vulnerability is identified as CVE-2015-7547 and is titled, "getaddrinfo stack-based buffer overflow."The glibc, or GNU C Library, is an open-source implementation of the C and C++ programming language libraries and is part of every major Linux distribution. Google engineers came across the CVE-2015-7547 issue when they were attempting to connect into a certain host system and a segmentation fault (segfault) occurred, causing the connection to crash. Further investigation revealed that glibc was at fault and the crash could potentially achieve an arbitrary remote code execution condition."

 

From Fortune Magazine: http://fortune.com/2016/02/17/google-glibc-big/

 

"Like previous open-source bugs, this one also affects a large number of Linux distributions, software and devices.

"Pretty much any Linux system uses glibc, and getaddrinfo is typically used to resolve IP addresses. Which means Linux servers as well as workstations, are vulnerable unless it runs an old version of glibc (pre 2.9)," noted Johannes Ullrich, CTO of the SANS Internet Storm Center.

Ullrich initially believed Android devices are probably also affected by the bug. However, security researcher Kenn White has since pointed out Google opted for the glibc alternative Bionic C software for Android.

 

White also said there is a possibility that CentOS, Oracle, and Amazon Linux may be vulnerable to the glibc vulnerability."

 

 

More info here on ZDNET "Patch Linux now, Google, Red Hat warn, over critical glibc bug" : http://www.zdnet.com/article/patch-linux-now-google-red-hat-warn-over-critical-glibc-bug/?tag=nl.e539&s_cid=e539&ttag=e539&ftag=TRE17cfd61

 

Or here on Infoworld "Patch now! Unix bug puts Linux systems at risk" : http://www.infoworld.com/article/3033862/security/patch-now-unix-bug-puts-linux-android-and-ios-systems-at-risk.html?token=%23tk.IFWNLE_nlt_infoworld_open_source_2016-02-17&idg_eid=6aa01e18b29f7b6f9149f611f8eac228&utm_source=Sailthru&utm_medium=email&utm_campaign=InfoWorld%20Linux%20Report%202016-02-17&utm_term=infoworld_open_source#tk.IFW_nlt_infoworld_open_source_2016-02-17

[Dutch_12078]

Note that the Android OS, although Linux based, is not affected by the glibc vulnerability. Android uses an alternate library called Bionic.

[RV_]

Update:

 

"Magnitude of glibc Vulnerability Coming to Light"

 

Excerpt:

 

"Not since Stagefright have we had a vulnerability with the scale and reach of the glibc flaw disclosed on Tuesday.

 

“It’s pretty bad; you don’t get bugs of this magnitude too often,” said Dan Kaminsky, researcher, cofounder and chief scientist at White Ops. “The code path is widely exposed and available, and it yields remote code execution.”

 

The flaw affects most Linux servers, along with a number of web frameworks and services that make use of the open source GNU C library, including ssh, sudo, curl, PHP, Rails and others. Initial reports about the impact on Android were incorrect given that the OS uses the Bionic libc implementation and not glibc.

 

The harshness of the bug, a stack-based buffer overflow, rests in the fact that it lives in the glibc DNS client-side resolver, or libresolv library. Since DNS is a core network technology and most services rely on it, the horizontal scale of this bug is massive.

 

“An attack would first force a system to make specific DNS queries, using domain names controlled by the attacker. The attacker would then have to run custom-written DNS server software, which generates crafted responses that trigger the vulnerability,” Red Hat engineer Florian Weimer told Threatpost. It’s believed that the most direct exploitation vector would be a man-in-the-middle attack where an attacker would already be on the local network. “We do not know how difficult it is to exploit this over the Internet. We assume this is a possibility,” Weimer said, adding that he was not aware of any public exploits.

 

Carlos O’Donnell of Red Hat wouldn’t commit to that scenario yesterday in an advisory.

 

“A back of the envelope analysis shows that it should be possible to write correctly formed DNS responses with attacker controlled payloads that will penetrate a DNS cache hierarchy and therefore allow attackers to exploit machines behind such caches,” he wrote.

 

Adding to the severity of the issue is the fact that the vulnerability was introduced in glibc 2.9, which dates back to May 2008, giving attackers close to eight years to find and abuse the bug.

 

“We know as fact that multiple research groups found this and successfully coordinated work to fix it, which is very good,” Kaminsky said. “But we know its been around a decent amount of time, and we know it’s a golden vector that gets into all sorts of goodies. Likely, this has been discovered and exploited in the field.

 

”The bug, CVE-2015-7547, was discovered independently by researchers at Red Hat and Google who privately disclosed the issue to upstream glibc maintainers, Weimer told Threatpost. Coordination between the two camps began on Jan. 6, though the initial bug disclosure was made last July, according to an advisory on the glibc mailing list."

 

See more at: https://threatpost.com/magnitude-of-glibc-vulnerability-coming-to-light/116296/#sthash.DRBoc54J.dpuf

[skp51443]

A lot of folks may skip over this because they don't use Linux. Almost all of them will be wrong, they have Linux somewhere in their systems even though it never appears present. TVs, routers, networked storage - video - audio, smart devices like thermostats or light controllers al may have Linux embedded under the hood.

 

 

 

While writing the long post below the -------------- I realized that there was likely another solution for most folks and devices: OpenDNS: https://www.opendns.com/

 

On the bug: https://engineering.opendns.com/2016/02/17/2980/

 

 

The good news is that if you are using OpenDNS, you aren?t affected. If you want the technical details of why, please read on as we dive a little into how we process a DNS response.

 

Much longer tech discussion there and well worth reading.

 

So all my work checking my systems and doing the post below were not really necessary but I had fun doing it anyway and since we got to over 90 yesterday it was a good excuse to stay inside.

 

Short answer, use OpenDNS by putting their addresses into your router for DNS queries:

 

IP v4:

 

208.67.222.222

 

208.67.220.220

 

IP v6: (really, that is an IP v6 address, it is suppressing a lot of 0s between the :: section)

 

2620:0:ccc::2

2620:0:ccd::2

Other DNS servers may also be tweaked to avoid allowing the attack to pass through them too.

 

 

 

Now my original post...

 

------------------

 

How important this is to you varies a lot based on what hardware you are running Linux on, there are several different situations. If you aren't in "A", "B.1.a" or "B.2" you have a real and potentially serious problem. EDIT: And what DNS servers you are using.

 

 

A. Your hardware doesn't use the glibc C library, nothing to worry about as this doesn't apply to you.

B. Your hardware uses the glibc C library. Then:

 

1. It is a version that is vulnerable.

- a. Your vendor has patched it and made the patch available and you took it.

- b. Your vendor hasn't done anything.

 

2. It is a version that isn't vulnerable.

- a. It is already patched, no worries you are not in danger.

- b. It is so old pre-2.9, this doesn't apply but that is ancient and has other issues.

 

C. You have no way of discovering what your hardware uses. This is all too common with cheap hardware like routers and other network attached hardware that fail to follow the GPL (General Public Licence) rules for making information and code available.

 

 

I believe all of the major desktop and server Linux systems have had patches released so if you are taking updates you should be covered. You can confirm you got it by reviewing your patch history or checking the distribution's security page.

 

Small routers often use a different library than the glibc that uses less space and memory and aren't at risk. The only way to be sure is to look at the GPL information and see if the glibc is listed. If it isn't then you are good, if there is no listing then you may have a problem and without tools and skills beyond most folks there is no way to be sure.

 

The same thing applies to things like networked disk drives (like the WD Live series) or other network appliances that might use the DNS system that this bug applies to.

 

---------

 

The question of what to do with gear that you can't insure is not vulnerable comes down to where it is in your network and how it uses DNS. If you are sure it isn't using DNS then you can ignore the bug. If it uses DNS and you can force it to use one of your DNS servers that will filter out the attack (below) you are also protected.

 

 

https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html

 

- Mitigating factors for UDP include:

- A firewall that drops UDP DNS packets > 512 bytes.

- A local resolver (that drops non-compliant responses).

- Avoid dual A and AAAA queries (avoids buffer management error) e.g.

Do not use AF_UNSPEC.

- No use of `options edns0` in /etc/resolv.conf since EDNS0 allows

responses larger than 512 bytes and can lead to valid DNS responses

that overflow.

- No use of `RES_USE_EDNS0` or `RES_USE_DNSSEC` since they can both

lead to valid large EDNS0-based DNS responses that can overflow.

- Mitigating factors for TCP include:

- Limit all replies to 1024 bytes.

 

I checked all my gear and it is either already patched or isn't vulnerable, if they were I'd probably pitch them.

 

------------------

So to update that last line after reading the OpenDNS information:

 

Even using OpenDNS I'd likely pitch stuff that was vulnerable at some point and replace it with different hardware that followed the GPL rules so future issues could be easily evaluated.

[RV_]

Or just go to the security news page of your Linux distro if you want to avoid command line fixes, as Stan keeps describing Linux today has no need to go into anything command line based.

 

For example RedHat Linux has it listed as Critical! and that users of their distribution have had the issue resolved. They describe how the vulnerability works and how it has the potential for remote access and control. That page is here: https://access.redhat.com/security/vulnerabilities/2168451

 

 

Like Linux, Windows is starting to auto install security patches. I have to say that the folks talking about bad patches and systems being corrupted by Windows updates are talking either back in the pre Windows XP-SP3 days, or are discussing large companies with custom coded software with ancient XP and even Earlier DOS foundations that need to be custom applied at great expense. That's the cost of running old OS' with little of today's OS security built into the last three versions of Windows 8, 8.1, 10, with safe boot. Guys, as a power user, I take all patches and do not wait for feedback because much of it is from the types who say that the hard drive shipped was defective and never showed up when connected, (Because they had no idea what "initializing" a bare drive means, let alone ) many of the folks with a bad update patch for Windows claiming it bricked their computer I submit have other issues. I have had two bad patches in the last two years out of all. One caused Outlook to load only in safe mode, it was fixed with a new patch within a week and caused no failure to be able to access it or use it. None bricked my machines, any of them.

 

 

But as Stan restated, if you are taking patches then you are probably patched, and he mentioned to check your patch histories, or as I pointed out, go to the security page for your distro. Many Linux folks don't do updates because of the same issues with not knowing if it will fit their custom configuration. If you think Windows patch days are daunting look at the Red Hat Security Advisories for just today: https://access.redhat.com/security/security-updates/#/security-advisories

 

I post because if friends here run Linux, and miss a vulnerability, because for lack of cheap bandwidth they don't auto patch anything, they can decide if they want this one or not. Since it is considered a critical vulnerability by Linux itself, and all the major distros of Linux, this vulnerability fix decision is a no brainer. Patch.