The Ghost security hole perfectly illustrates the efficiency of open source

A new security hole has been found (and patched) on Linux systems. Jack Wallen uses this example as yet more proof the open-source community exemplifies how patching should be done.

Ghost security hole

If you're reading this piece, you probably already know there's a ghost in the machine of Linux. Specifically, a critical hole in the GNU C Library (glibc). This haunting specter enables remote hackers to gain access to machines without the need for credentials of any kind.

That, my friends, is a nasty, looming hole.

Ghost, as it has been dubbed, is a buffer overflow issue that affects any system running glibc-2.2 or earlier. The official function in the GNU C Library that allows for the buffer overflow is _nss_hostname_digits_dots().

You can find out which version you are running from the command line. For example, on a Ubuntu (or Debian-based) system, issue the command:

dpkg -l libc6

On my Ubuntu 14.10 machine, I am returned:

ii libc6:amd64 2.19-10ubunt amd64 GNU C Library: Shared libraries

ii libc6:i386 2.19-10ubunt i386 GNU C Library: Shared libraries

For a distribution that uses the rpm package manager, that command would be:

rpm -qi libc6

I'm safe from this issue. If you're running 2.2 or earlier, you're not safe, and you need to upgrade as quickly as possible (to at least 2.18). Canonical has patched all LTS releases back to 10.04. A Debian fix is on the way, and both Red Hat and CentOS are working on patches. The upstream library was actually fixed at version 2.18 -- but the security flaw hadn't been recognized at that point.

If you find that your system is vulnerable, update IMMEDIATELY, and then reboot the machine. That's right... reboot. This flaw takes advantage of gethostbyname, which is called upon by a large number of subsystems. When you update, a reboot is the only way to make sure the patch takes effect.

Red Hat was notified of the issue and, within a week, released a fix for 5, 6, and 7. The key to that sentence is "within a week." That's a fast turn around for three releases.

What this nasty mess of a security hole illustrates for me is simple -- the open-source community can react very efficiently. Within moments of the flaws discovery, it was revealed which versions were safe, and patches were on the way. The second the patches are rolled into libc6, they'll be released without hesitation, and systems will once again be safe. This is how the open source community works. There's very little bureaucracy in the way of releasing major bug fixes -- it just happens and happens with an efficiency no proprietary software can match.

Naturally, there'll be those who point out the fact that there have been a few rather serious flaws found in Linux of late, which is very true. However, if you spend your days searching for holes, you'll find holes -- ways and means to exploit a piece of software -- regardless of the platform. They exist. In even the most secure package, at some point, someone will look at the code in a way no one else has and find a hole. No operating system is 100% safe. That lends a massive importance to the efficiency of patching holes.

That, my friends, is an inevitability in the age of digital dependency. And the more we use them, the more people are out there looking for ways to get into systems. This is exacerbated when you figure in the cloud, plus the depth and breadth of users connected to and dependent on a single system. That very scenario is exactly why swift patching is no longer even remotely optional. It's also why patching is superior within the open-source community:

  1. Hole is found
  2. Hole is publicized
  3. Hole is patched
  4. Patch is released

Open source exemplifies this. As more people become dependent on Linux, they'll understand how easily the patching of a security hole can be. In many instances, Joan Q. Public will be completely unaware a security hole has been found, patched, and their software updated. As for administrators of Linux systems -- or any system, for that matter -- you fully understand the importance of keeping up with security patches. Those that administer both proprietary and open systems know well how bugs are patched and how quickly a major flaw in a piece of open-source software is fixed.

And let's not forget about the transparency. Found, announced, fixed, released -- it doesn't get much more efficient and transparent than that. There is no obfuscation of the flaw. It's made public without shame or game -- it's stated as fact, and then it's fixed.

What's your take? Do you think open source handles the patching of major flaws with more efficiency than other platforms? If not, what is the underlying problem? Share your thoughts in the discussion thread below.

By Jack Wallen

Jack Wallen is an award-winning writer for TechRepublic, The New Stack, and Linux New Media. He's covered a variety of topics for over twenty years and is an avid promoter of open source. For more news about Jack Wallen, visit his website jackwallen....