This vendor-written tech primer has been edited by Network World to eliminate product promotion, but readers should note it will likely favor the submitter's approach.
If you're scrambling this week to install patches after the discovery of the GHOST vulnerability affecting Linux systems, you're not alone. The fact that we've been down this road before doesn't make it any less frustrating. It wasn't that long ago that the news broke about Shellshock. And not long before that, Heartbleed.
Being in reactive mode because of serious emerging software security threats might seem like the new normal but you don't have to accept that. You can do more than just react. What if your organization could make software security pre-emptive, heading off many vulnerabilities before any damage is done?
By focusing on what I like to call "open source hygiene," you can do just that more on this shortly. But first, let's examine why GHOST is making software security experts so nervous.
GHOST in the Linux machine
The GHOST vulnerability in the Linux GNU C Library (glibc 2.2) is a gaping one. Version 2.2 is native to a range of standard Linux distributions, especially ones built on Debian Wheezy, but also on Red Hat platform versions. This system population includes a wide variety of embedded systems along with servers and desktops.
The affected API, "gethostbyname()," is an integral part of the POSIX standard, which is the definition of UNIX-type systems, including Linux. This API is part of the core functionality of Linux. The glibc library is the primary library used by all types of programs running on Linux to interact with the kernel and to perform core input/output operations. Put another way, everything runs through glibc it's like Grand Central Station.
Perhaps most worrisome is the fact that the exploit can be triggered remotely through benign actions such as processing email. And unlike bash, which was central to the Shellshock threat, glibc is a reasonably well-curated library. So the issue with GHOST is not that there haven't been enough eyes on the code. In fact, it's constantly being updated and tested. Rather, the issue is that not all of those eyes are sufficiently security-savvy.
Taking charge of open source security
Even with many eyes on the code, software vulnerabilities like GHOST and its predecessors are inevitable. IT organizations are stretched thin, trying to do more with less and deliver innovative applications faster than ever. Choosing open source components as part of the development process helps them achieve these goals. What's more, participating in and contributing to open source communities is a critical part of how forward-thinking IT organizations innovate.
So how can software development organizations balance open source software security concerns with the drive to keep innovating at an ever-faster pace?
Sign up for Computerworld eNewsletters.