CVE-2017-2636 strikes Linux kernel with double free vulnerability

Mar 18, 2017 / 2 min read

Table of Contents

That’s why this recent Linux kernel vulnerability is a big deal
Then comes the hard part

We often talk about how open source is not less secure (or more secure) than commercial software. For one thing, commercial software contains so much open source that it’s difficult to find anything that doesn’t include open source. There are, however, characteristics of open source that make it attractive to attackers when vulnerabilities are disclosed. Briefly, when vulnerabilities are present in widely used open source components, and exploits are publicly available, it becomes a target-rich environment.

That’s why this recent Linux kernel vulnerability is a big deal

Linux is used everywhere. It is now the dominant choice for web servers and IT infrastructure and, because free and stripped down versions are available, is used extensively in the Internet of Things (IoT). This is the mother of target-rich environments, and when we talk of IoT, we’re talking about poorly designed and managed environments.

This one is also going to be around to cause problems for a long, long time. Like other vulnerabilities in open source, the first problem is that organizations often don’t know they are using the now-vulnerable components. Because it is so easy for open source to be added — simply download it from your favorite forge — we find that organizations are typically aware of less than half of the code they use. While that’s less of a problem for Linux in some environments, we’ve seen it be a problem when the vulnerable code is in the Linux stack of containers. If you have a Linux distribution containing the vulnerable Linux kernel, and you replicate it across all of your applications in a container environment, you suddenly have a lot of problems to address. Due to the default ioctl settings on Docker, this shouldn’t be executable from within a container. However, if you have access to the container host all bets are off.

In the IoT environment, the problem is three-fold. First, the device manufacturers have to be aware of the vulnerability, and with the lack of software security we typically see, that’s not a sure bet. Next, they need to distribute a patch.

Then comes the hard part

How do you get your users to install the patch? How many consumers ever update their router software (or even know that it’s possible)? The inability to get users to understand the need to update their DVR (or TV, Internet camera, or thermostat) and how to do it means that underlying vulnerabilities are going to be around, and an attack vector, for a long time.

Finally, it’s worth noting how this bug was found. It entered the code base in the summer of 2009, and was discovered in February, 7 ½ years later, by a researcher (with the help of the syzkaller fuzzer). In spite of the tens (hundreds) of thousands of times various versions of Linux have been tested with static and dynamic analysis or pen tested, it still came down to a smart person looking at the application. And it will take visibility to what you’re using for open source, and an ability to patch it, that can prevent this problem for affecting your organization in the long term.