Linux Vulnerabilities Explained
If you worked with a computer the last decade, you know the importance of keeping your software up-to-date. Those who don’t, are stacking up vulnerabilities, waiting for them to being exploited by others. Although GNU/Linux and most software are open source and can be reviewed, security flaws in software packages remain. While it isn’t easy to close every vulnerability on your system, we can at least create a stable process around it. The goals? Know which vulnerabilities exists and how to treat them.
What is a Vulnerability?
As with many technical terms, the details are in the definition. The exact definition of a vulnerability differ for every organization. However, it common to describe it as a weakness in an asset, process, or piece of software. The risk involved in having a vulnerability is that a known or unknown threats (or threat actors) might abuse the weakness. This in its turn can result in a specific bad outcome, like data loss or exposure. For example, a programming flaw has a chance to become a big data leak, with all your personal data in the hands of unauthorized individuals.
For this article, we discuss two main categories of vulnerabilities commonly found on Linux systems. The first category is vulnerabilities in the operating system and software packages. The second category is weaknesses introduced by default and changed software configurations.
Common Linux Vulnerabilities
Linux has weaknesses similar to those other operating systems have. These weaknesses are inherent to how computers work. Most of them are caused during the development cycle of software. The weakness is usually somewhere in the logic involved. One missing “if” statement can be enough to make a piece of software instantly vulnerable to a common attack. The big difference is that every operating system has different ways to deal with them. This starts with the compile flags used during compiling the source code, up to the time when software is being executed.
Most of the security updates provided by Linux distributions solve one or more programming defects. Ranging from buffer overflows to incorrectly handling resources, all of them have a different security risk involved. In all cases, they contain a vulnerability. The million dollar questions are who can abuse them and the impact. Some vulnerabilities can only be triggered by local users, where another one might be part of a commonly used web server.
Software packages usually come with a default configuration. This configuration tells the software how it should work and what logic steps it should, or should not, apply. While most of the individual settings are functional, some of them might negatively impact security measures. The opposite is true as well, it might improve the security of the software, or even system as a whole.
Too often default or adjusted settings result in introducing weaknesses, which we often don’t recognize at first sight. A simple option like turning on debugging functionality might give an end-user detailed knowledge about the system, or even turn off some important checks.
The Django framework is a great example. It has a debug option, which is turned on or off with the DEBUG setting. Even though the Django documentation warns for the impact of using the DEBUG setting, we often are tempted to temporarily disable valuable protections. Many production systems end up with settings which are only suitable for during development.
The last few years several serious vulnerabilities found their way to the media, like:
All these fancy names simply represent a weakness in software components, varying from flaws in protocol design, up to in lacking security checks within the source code of the related programs itself. What these vulnerabilities have in common is that they had (and still have!) a serious impact on common services on the system: GHOST affects glibc, a common systems library. Heartbleed and POODLE were related to SSL/TLSaffects SSL, often used by implementations in network services. Last, but not least, Shellshock which is named after a flaw in Bash.
Shellshock tests for bash in auditing tool Lynis
Detection and Tools
While it would totally make sense to learn first about the ways to protect ourselves against vulnerabilities, we should consider the reality: vulnerabilities happen. It is better to have good detection capabilities and act appropriately, than having preventing measures without 100% guarantees and ending up with a false sense of security. Prevention is great, but prevention plus detection is much better.
Most Linux distributions have a policy in place to describe how they deal with security related issues. Users can report security issues with the website itself, services like bug trackers, or packaged software components. Especially for this last group, notifications are often sent to a related security mailing list.
Package Audit Tool
Receiving notifications is great, but automation is definitely the next level. Most Linux distributions have a package manager available, to control software packages. This may be simple actions of installing a package or removing. These utilities include dpkg, rpm, named after the package format. While this is great for installing and removing, the process of upgrading is slightly more complicated. For that, Linux distributions include more advanced tools, like apt-get, YUM, or dnf. These tools maintain a package database, with the installed packages, available packages and other supporting querying tools.
Newer package managers have the option to retrieve updates, including packages marked which have a security update available.
- Gentoo: glsa-check
- openSUSE: zypper lp (grep security)
- Fedora / RHEL: yum list-sec security
- Ubuntu: apt-check
The package manager can easily be turned into a package auditing tool with these commands. The result is a nice overview of available security updates for your system.
For those running BSD systems, there is “pkg audit” on FreeBSD and “pkg_admin audit” NetBSD.
Like auditing of software packages, we can perform a more in-depth type of audit: the system audit. While an audit sounds like a formal process performed by auditors, this technical checkup can be as simple as running the right set of tools. In the past Tiger was a great tool, now it has replaced with tools like Lynis or using the Security Content Automation Protocol (SCAP).
The benefit of auditing tools is that they look at both your hardening measures (defenses) and flaws in your configuration (vulnerabilities). Too often people focus on only vulnerability scanning. This is a shame, as a technical audit can actually reveal underlying problems and provide better insights. A hidden issue might be a misconfigured set of DNS or NTP servers.
Linux kernel security overview after Lynis audit.
Another great addition for detecting vulnerabilities is (of course) using a vulnerability scanner. These tools often have predefined rules to determine weaknesses in software or their configuration. While not always having the in-depth level of host-based audits, they still provide a quick way to scan the network or a single system. If combined properly with auditing, you have a great way of detecting issues quickly.
Besides many commercial scanners, OpenVAS is probably the most-known tool. It is a fork of version 2 of the previously open source Nessus scanner.
Now we discussed some of the detection methods, it is time to get some preventative and corrective measures in place.
The easiest way to prevent weaknesses from happening, is by not installing what you don’t need. In other words, apply a ‘minimal installation’, which only runs the minimum required set of processes. This also applies to the users on the system.
If you perform software development yourself, a great way to prevent security flaws, is using code auditors. This could be a linting utility, which catches missing variable declarations, or otherwise unexpected logic. There are also commercial and open source utilities to guide with writing more secure software. Since there are so many languages, we might cover that in a later blog post. For now, just search for your programming language and code audit (or lint), and see what common utilities exists.
Many serious vulnerabilities have a high impact because they are available via the network, which increases the risk of being abused. To counter this, firewalls are another level of defense. Configure a local firewall and only allow those services required for the needed functions of the system.
While network filtering with a firewall is great, it doesn’t help with those services you opened. For example when running a web server, access to port 80 (HTTP) and 443 (HTTPS) should be generally available. Still many services have also firewalling on that level. In this case a web application firewall (WAF), which can filter out traffic.
The last level of dealing with vulnerabilities is actually treating them. Usually this is a corrective step, as it acknowledges there is an issue and we want to solve it, or limit its impact.
The most obvious corrective measures is keeping software packages up-to-date. This way when a security leak has been found, and the vendor released an update, it can be fixed quickly. Having a good patch management process in place is key.
Upgrading on a regular basis keeps your system protected
Install Security Updates Only
If you rather don’t want to install all updates, you can opt for doing only the security updates. Depending on your Linux distribution, determine if you can enable this. Sometimes we have to script a little bit to achieve the same, but it is doable. For example with Debian/Ubuntu we can filter out the security-related repositories, and only upgrade packages which are referred to in our custom file.
grep security /etc/apt/sources.list > /tmp/software-security.list
grep security /etc/apt/sources.list.d/* >> /tmp/software-security.list
apt-get upgrade -oDir::Etc::Sourcelist=/tmp/software-security.list -s
The big benefit of only applying security updates is that you solve vulnerabilities, yet don’t update or upgrade the whole system. This way it is much quicker and easier to detect if something does not work after the change. It also allows you to use a double schedule, like installing security patches daily, the remaining patches one a week or month.
Test before you patch
If you or your colleagues are scared of applying patches, then create your own test system. Do a maximum installation of your favorite Linux distribution and install all types of software, you would otherwise find also on other systems within your network. Have this system perform security updates very regurlarly and report on any issues.
Detecting issues with patches can be as simple as adding the system to your monitoring system. Have it test all the processes you expect it to be running. If suddenly something stops, you can quickly determine if this is the result of an applied patch.
Automatic Security Upgrades
Some Linux distributions allow also for automatic patching, so you don’t have to write your own script if automation important. For Debian and Ubuntu system there is the unattended-upgrades utility. Configure it to do security patches only and let it run daily.
Unattended-upgrades in action
Vulnerability management is a diverse set of activities to help discover vulnerabilities, categorizing them and apply the right measures. By using the right tools, the process of detection, prevention and correction, becomes much easier. Another thing we should not forget is that security is a process. You can’t solve security just with one single product, nor is it a one-time event. The right level of monitoring and detection capabilities are needed.
Do you have other tools you use?