The state of Linux security
Lessons learned from 2016’s most important Linux security events.
In the last 10 years, GNU/Linux achieved something some foresaw as almost impossible: powering both the smallest and biggest devices in the world, and everything in between. Only the desktop is not a conquered terrain yet.
The year 2016 had an impact on the world, from both a real life and digital perspective. Some people found their personal details leaked on the internet; others found their software being backdoored. Let’s have a look back on what happened last year regarding Linux security.
Why this report?
We want to capture the most important events of the last year in the hope that, by looking back, we might be able to better predict what is to come next. Any feedback is welcome via firstname.lastname@example.org or on Twitter (@mboelen).
This extensive article is created by the people at CISOfy. We focus on Linux and UNIX security, and we created the open source tool Lynis and its bigger brother Lynis Enterprise, which performs security scans on your systems and helps you stay compliant with regulations.
25 years of Linux
Last year included the celebration of the Linux project. It was 25 years ago that Linus Torvalds shared his initial creation. One of the lessons we can learn from his first announcement is that security had to find its place. At that time you needed to spawn 64 processes just to perform a denial of service—a reasonable defect, considering the age of the project.
Security highlight: backdoors
Backdoor in Linux Mint (February 2016)
The popular Linux Mint distribution got a bad surprise. Users who downloaded the distribution on the 20th of February picked up a backdoored release.
The server of the project was apparently breached via WordPress. The attackers were able to put up a new ISO with a backdoor in it. If your distribution had the file /var/lib/man.cy, then it was confirmed that this was the bad release.
Stop using MD5. If you still use SHA1, then add also the SHA256 or SHA512 hashes.
Linux kernel security and self-protection
A hot topic is kernel hardening and the concept of ‘self-protection’. The kernel should be able to defend itself against a basic set of attacks. Typically these are buffer overflows and result in unauthorized access to memory segments. Fortunately, some of these protections are now being discussed and the first set of patches have been applied to the official kernel sources.
One of these examples is the 4.9 release of Linux. The kernel can now enforce proper memory protections, based on the type of data stored in memory. Code memory is marked executable and read-only, with read-only data being marked read-only and non-executable, and writable data as non-executable.
Another recent addition is adding guard pages between stacks. Stacks are used for maintaining a list of activities of a process and determining the next step. The kernel has all these process stacks mapped together, with the risk of one process performing stack exhaustion (like a buffer overflow but for stacks). If that succeeds, a process can directly influence another process. With the guard pages this is protected, resulting in the kernel sending back a fault and thwarting the attack.
- Thwarting Unknown Bugs: Hardening Features in the Mainline Linux Kernel (29 minutes)
- Kernel self-protection project
Relevant kernel parameters
- CONFIG_CPU_SW_DOMAIN_PAN (ARM)
- CONFIG_ARM64_PAN (ARM64)
- CONFIG_X86_SMAP (X86)
- CONFIG_KASAN_INLINE (for testing)
- CONFIG_KASAN_OUTLINE (for testing)
Live patching of the kernel
The technology of patching a running kernel is not new. Several technologies were being developed over the years:
- kGraft (SUSE)
- kpatch (Red Hat)
- Ksplice (Ksplice, now Oracle)
With support for kGraft in the kernel sources, distributions can now leverage this functionality. When a new security vulnerability hits the kernel, the distribution can create a related patch. This is then loaded as a kernel module and applies a bypass to the affected function that had the vulnerability. Great care should be put into creating these patches as they will change the running kernel. For this same reason, the kernel will mark itself as tainted to reflect this. It is similar to backdooring the kernel, except for a good cause. If you don’t allow loading kernel modules, then this technique won’t work obviously.
Canonical announced in October 2016 the availability of using Livepatch in Ubuntu. This service became available to both customers and free users, although limited to three systems for the latter.
Average lifetime of security bugs
Kees Cook, currently working for Google, shared an interesting insight regarding the lifetime of security bugs before they are fixed. This easily can be between 3 and 6 years for high and critical issues.
Like previous years, 2016 had a fair number of serious vulnerabilities. With differences in timing between discovery and public disclosure, this list is ordered by CVE number.
CVE-2015-7547 – glibc
Issues in glibc, a very generic library affecting almost all Linux systems, caused some attention early in the year. Discovered by troubleshooting strange issues with SSH, it was determined that the cause was at another location: glibc.
CVE-2016-1247 – NGINX (root privilege escalation)
Rotation of log files on systems running NGINX on Debian or derivatives could be tricked into escalating privileges.
CVE-2016-0636 – OpenJDK
An issue in some versions of Java 7 and 8 hit in particular desktops, including those running on Linux. With the tendency of security professionals advising to disable Java and Flash, we wouldn’t be surprised that issues with this kind of package will slowly decrease. Oracle bulletin for CVE-2016-0636
CVE-2016-0800 – DROWN attack
The DROWN attack was a discovered weakness with SSLv2. Although many web servers are now properly configured, there are still systems around having it enabled. And even if your web server is not vulnerable, it can be if SSLv2 is enabled on another system (e.g., mail) while reusing the same key for the SSL certificate.
CVE-2016-0728 – 0-day Linux root exploit
An issue in the keyrings functionality could trigger a leakage of data. Those who discovered the issue explain how it can result in root privileges in their great write-up.
CVE-2016-5696 – Linux kernel vulnerability for 4.6
Luckily without affecting many servers and desktops, it affected Android 4.4 KitKat and later. This vulnerability could be used to hijack TCP sessions.
CVE-2016-6662 – Critical issue in MySQL and MariaDB
This vulnerability could result in root privileges. An extensive write-up explains how it works.
CVE-2016-4484 – Linux Disk Encryption Bypass
This issue is very similar to the GRUB2 authentication bypass discovered in 2015. This time it resulted in a root shell on the machine. Although you still can’t access data of the encrypted disks, it should not be there. This issue was limited to systems running Debian or a derivative.
CVE-2016-5195 – Dirty COW
These are copy-on-write issues in memory resulting in “dirty COW”, this time with another great logo and official website.
A lot of the things that hit the media in 2016 were related to malicious software. Malware is not new on Linux and may have existed since the beginning. In the early 2000’s we saw rootkits, backdoored binaries, and an arsenal of tools to crash well-known software. We can say that the quality of most software increased. This is especially true when considering the addition of security settings and an ongoing trend to enable them by default. And while the effectiveness of most rootkits diminished, malware on Linux looks to be growing.
Botnets are a powerful tool for those who want to perform denial-of-service attacks, send spam email, or simply harvest bitcoins at the cost of others. Linux has a past of botnet clients, varying from simple IRC clients that could execute commands, up to heavily encrypted binaries with different mechanisms to be controlled by the botnet master. Fortinet disassembled the Mirai.B worm on their blog.
Core Infrastructure Initiative
The Linux Foundation released funds and put energy into making Linux more secure—not just improving the Linux kernel, but also securing commonly used software components like OpenSSL and supporting other open source projects. This work is done under the Core Infrastructure Initiative (CII).
The CII is composed of four projects that enhance each other and help projects all over the world. One of them is tooling, as in offering the right tools. This helps with reproducible builds—something being used with Debian now—and fuzzing tools, which throw garbage at tools to detect missing input validation or memory issues. Besides tooling there is education, helping projects to connect and find the right security resources.
Then there are those special projects that need a little bit more attention because they are used by many other projects, or consist of a library. A flaw like we have seen in glibc can have a high impact due to this relationship with other software. These projects are tracked with the Census project and scored on risk.
Conferences are a great way to share knowledge and insights. Two particular conferences can be highlighted that really focus on security in the area of Linux and open source.
Most security conferences focus on the offensive side. Think Black Hat and DEF CON. Rarely do we see conferences focused on defense. O’Reilly made the bold move to organize two events in 2016, one in New York, the other in Amsterdam. The recordings are available if you have a subscription to Safari. The next O’Reilly Security Conference is October 29-November 1, 2017, in New York.
Linux Security Summit
This yearly summit provides good insight on the status of Linux security. There is so much to tell and to see. So have a look at the playlist.
Other interesting reads
Can’t get enough? Here are some topics you might also like:
- Linux Security: A Closer Look at the Latest Linux Threats (Trend Micro)
- MiKey (Linux key logger)