The state of Linux security
Table of Contents
Linux security and its developments
In the last 10 years, GNU/Linux achieved something some foreseen 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 last years had a great impact on the world. Both from a real-life perspective, as digitally. 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 lately and what we can expect regarding Linux security.
Why this report?
With this article, we want to capture the most important events of the last year. By looking back we might be able to better predict what there is to come in the upcoming years. This article is posted on this blog to provide a flexible shell. Any feedback is welcome in the comments section.
This article is created by the people at CISOfy. We focus on Linux and Unix security and created the open source tool Lynis and its bigger brother Lynis Enterprise. Helping you to perform a security scan on your systems and stay compliant with regulations.
25 years of Linux
This 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. You just needed to spawn 64 processes to perform a denial of service. At that time 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 around kernel hardening and the concept of ‘self-protection’. The kernel should be able to defend itself to 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 determine the next step. The kernel has all these process stacks mapped together, with the risk of one process performing stack exhaustion (similar like a buffer overflow but for stacks). If that succeeds, a process can directly influence another process. With the guard pages, this is protected. It kernel will send back a fault and thwart 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 up to three systems for the latter.
The 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 can easily between 3 and 6 years for high and critical issues.
Like previous years, this year 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 discovered 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 packages 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 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
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 were related to malicious software. Malware is not new on Linux and may exist since the beginning. 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 energy into making Linux more secure. Not just the Linux kernel, but also commonly used software components like OpenSSL, or supporting other open source projects. This work is done under the Core Infrastructure Initiative, or CII.
With CII there are four projects which enhance each other and help projects all over the world. One of them is tooling, like offering the right tools. This helps with reproducible builds, something being used with Debian now. Also 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 resources when it comes to security.
Then there are those special projects that need a little bit more attention. For example, 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 Defcon. Rarely we see conferences focused on just defensive. O’Reilly made the bold move to organize two events, one in New York, the other in Amsterdam. The recordings are available if you have a subscription to Safari.
Linux Security Summit
This yearly summit provides a good insight into 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 we might also like:
- Linux Security: A Closer Look at the Latest Linux Threats (Trend Micro)
- MiKey (Linux key logger)
Did you like this report? Share it on your favorite social media channel.