Linux vulnerabilities: from detection to treatment

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 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. This guide explains what is available, from vulnerability to treatment.

Linux Vulnerabilities

What is a vulnerability?

As with many technical terms, the details are in the definition. The exact definition of a vulnerability differs 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 contains vulnerabilities in the operating system and software packages. The second category describes weaknesses in the configuration of software.

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.

Programming defects

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.

Weak configurations

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.

Example: Django

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.

Vulnerabilities with fancy names

The last few years several serious vulnerabilities found their way to the media, like:

• GHOST
• Heartbleed
• POODLE
• Shellshock

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/TLS, often used by implementations in network services. Last, but not least, Shellshock which is named after a flaw in Bash.

Vulnerability 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.

Notifications

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.

• Arch Linux Security Advisories
• Debian Security Advisories
• Gentoo Announcements (including security)
• Ubuntu Security Notices

Package audit tools

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.

Linux security auditing

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.

Vulnerability scanners

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. There are more open source vulnerability scanners available, each with their own specialization.

Vulnerability prevention and reduction

Now we discussed some of the detection methods, it is time to get some preventative and corrective measures in place.

Minimal installation

The easiest way to prevent weaknesses from happening is by not installing what you don’t need. In other words, apply a minimal installation. This way you only run the minimum required processes to provide a service to your users. This actually also applies to the users on the system. Remove those users that no longer belong on the system.

Code auditing

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 exist.

Traffic filter with a firewall

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.

More ways to reduce risks

Every step that you take should be the outcome of a well-balanced decision between benefits and cost. In the end, reducing risks will be relying on your risk appetite and the resources you have available. Part of these resources is the available knowledge about a particular subject, including Linux security measures. To better understand the available measures, have a look at the article covering security for Linux systems.

Vulnerability treatment

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.

Software upgrades

The most obvious corrective measure 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.

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 and 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

Benefits

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 regularly 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.

Conclusion

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.