A guide to security technologies in Red Hat Enterprise Linux

Red Hat has a long history of adopting and creating security technologies to harden our core platforms, such as Red Hat Enterprise Linux (RHEL). When other platforms or layered products are used with RHEL, they inherit many of these protections due to that foundation. 

These protections help, but require expertise to know when they should be applied. It’s important to distinguish between security technologies that are “always-on” and those that require enabling or configuration. For example, Security Enhanced Linux (or SELinux) is the latter. The amount of protection SELinux will afford varies tremendously depending on whether SELinux is enabled (the RHEL default), in permissive mode, or disabled entirely.

In contrast, an example of security features that require no additional effort on the user’s part would be using software that has been built with compilation hardening flags which create hardened binaries. We’ll touch on each of these briefly to describe the type of protection they afford and provide links for those inclined to learn more. In addition, we will investigate the types of attacks we encounter, and how our services protect against them, and if they are possible to protect against. 

So what types of security can you find baked into a Red Hat Enterprise Linux system? 

Configurable Security

One type of security feature RHEL provides is configurable security, settings that can be enabled for greater security. The Linux kernel is remarkable in the ability to customize it depending on one’s needs, due to its open source nature, and we’ll discuss several features it contains to do so. 

SELinux

SELinux is a MAC (Mandatory Access Control) implementation in the Linux kernel, providing an additional layer of security. SELinux is enabled by default in every Red Hat Enterprise Linux system since Red Hat Enterprise Linux 4. It has proven to be capable of mitigating several types of remote code execution flaws when the vulnerable application is confined by SELinux policies. 

A recent example is CVE-2020-11100, a remote code execution flaw in HAProxy. On RHEL, when SELinux is enabled and in enforcing mode, the impact of this flaw may be  reduced because of the increase in the difficulty of exploitation. While SELinux may not render every flaw ineffective, it often limits the risk and reduces the efficacy of successful exploitation. 

Seccomp

Secure Computing Mode (seccomp) is a system call filtering facility that was introduced in the Linux kernel in 2005. After a great deal of work and evolution upstream, we added support for seccomp in RHEL 7. Without enabling and configuring  seccomp, userspace applications have access to a large number of system calls that are often not used during a process’s lifetime, unnecessarily enlarging the attack surface of the kernel. 

It is possible to configure seccomp to filter the system calls a process has access to according to a set of rules. This results in reducing kernel exposure to user space, mitigating possible code execution attacks and data leaks, while also improving resource isolation. When detecting an attempt to execute a system call that is not permitted, the kernel’s seccomp facility intercepts the call and kills the caller. This is particularly useful in scenarios where an attacker manages to trigger arbitrary code execution, rendering it into a denial of service and resultant crash. Like SELinux, seccomp is another threat 

reduction technique that reduces the severity of a vulnerability. Seccomp is used by the OpenShift Container Platform at Red Hat, to help secure containers.

Compiler Hardening

RHEL uses several features to improve compiler hardening, in order to improve the security of shipped binaries. This is important so that users do not need to recompile software, as well as providing consistency across Red Hat products. This mitigates many attacks that rely on buffer overflows or other compiler level breaches. Here are a few of the ways we try to optimize RHEL for security using compiler features when building the operating system.

Relocation Read-Only (RELRO)

Relocation Read-Only (RELRO), is a mechanism for hardening ELF binaries in Linux.  In this technology we ensure that the linker resolves dynamically linked functions at the beginning of the execution, and then makes the GOT read-only.  This technique is called RELRO and can significantly raise the bar and steps required for a GOT overwrite.

FORTIFY_SOURCE 

FORTIFY_SOURCE is a lightweight compile-time and runtime mechanism that provides buffer overflow protections for functions which are heavily used by programmers. As per research, more than 19% of flaws reported to CERT are buffer overflows. At Red Hat, it has been one of the most common causes of flaws for the past three years, with the number declining due to the use of type-safe languages, static analyzers, and the use of FORTIFY_SOURCE. 

Position Independent Executables (PIE)

A PIE binary, as well as all of its dependencies, are loaded into random locations within virtual memory each time the application is executed. This compiler-based hardening mechanism makes Return Oriented Programming (ROP) attacks much more difficult to execute reliably. Starting with RHEL-7 the majority of network daemons are compiled as PIE and from RHEL-8 onwards almost all binaries (97%) are PIE.  

Stack Smashing Protection (SSP)

SSP (also known as StackGuard) is a technology that makes it difficult to exploit stack-based buffer overflows by inserting random canary values on the stack frame. This has been effective in blocking attack techniques like ret2libc, ret2gets, and ret2plt.

Address Space Layout Randomization (ASLR) 

ASLR is a technology that has been present since Red Hat Enterprise Linux 3. It is also known as “Execshield” and it guards against memory corruption. In particular, it defends against exploits of vulnerabilities present in memory management and it does so by randomizing the offsets to several key components such as the stack, locations of shared libraries in memory, and the program heap. 

By randomizing these memory locations, it makes it much more difficult and costly for an attacker to perform a buffer overflow attack, not knowing where the buffer overflows into. You can read more about how Execshield uses ASLR and NX (No eXecute) to accomplish this in Security Technologies: ExecShield.

CWE Statistics

In addition, Red Hat analyzes what vulnerabilities are reported to us, to better serve our users.  Red Hat has been using CWE (Common Weakness Enumeration) to assign weakness types to vulnerabilities for the last decade. Using this data we can see what types of weaknesses are present in Red Hat products and determine the types of protections that are in place to help defend against them, or reduce the severity of successful exploitation. 

For example, a buffer overflow vulnerability that might allow for the execution of arbitrary code could become one that crashes an application only, through protections like FORTIFY_SOURCE. We discuss the three most common sources of vulnerabilities, the top exploited vulnerabilities, and the top critical vulnerabilities. 

Buffer Overflows

CWE identifiers related to buffer overflows are CWE-119, CWE-120, CWE-121, CWE-122, and CWE-680. 

Vulnerabilities in Red Hat products, for the year 2020 as of October 12th, with these CWE’s associated accounted for 8% of the total vulnerabilities handled. For 2019, it was higher at 11%, and for 2018 even higher at 13%. These are above the relative standard error of 1.5% and can be assumed to reflect a meaningful decrease in the occurrence of buffer overflows. 

We believe this is due to the increased use of type-safe programming languages such as Python and the decline of C and other languages which do not enforce bound checking. Although Python and other type-safe languages are not perfectly immune to buffer overflows, they are less likely to occur. Also, the use of static code analysis tools is uncovering potential buffer overflows that can be fixed before code is released. Finally, Red Hat has protections baked in against buffer overflows, such as FORTIFY_SOURCE. 

Memory Buffer Errors

CWE identifies a category of weaknesses called Memory Buffer Errors which includes nine different weaknesses. These are weaknesses that primarily relate to the correct addressing of memory buffers. Technologies that randomize memory layout, add additional integrity checking to control structures or change page mapping protections to be as strict as possible are all technologies that can help mitigate attacks against these flaws especially when used in conjunction with each other. 

Vulnerabilities in Red Hat products, for the year 2020 as of October 12th, with these CWE’s associated accounted for 13% of the total vulnerabilities handled. For 2019, it was lower at 11%, and for 2018, lower at 12%. These differences are above the relative standard error of 0.5%, and this fluctuation does not have an apparent cause. These can be protected against through randomization of address locations, which Red Hat does with ASLR and other techniques. 

Data Neutralization Errors

CWE identifies a category of weaknesses called Data Neutralization Errors which includes 22 different weaknesses. These are weaknesses related to how data is input into protocols. For example, XSS attacks and SQL injections are in this category.

Vulnerabilities in Red Hat products, for the year 2020 as of October 12th, with these CWE’s associated accounted for 1.6% of the total vulnerabilities handled. For 2019, it was lower at 1% than 2020, and for 2018, higher than 2019 at 1.2%, but still lower than 2020. These differences are above the relative standard error of 0.7%, and this fluctuation does not have an apparent cause. 

Top 10 Exploited Vulnerabilities

CERT/CC issued a report detailing the top 10 routinely exploited vulnerabilities in the period of 2016-2019. Of these, only two had an impact on Red Hat products; the first was in Apache Struts 2 (CVE-2017-5638) which was included in Red Hat JBoss Fuse Service Works 6, but was never used in the application. 

Additionally, the other applicable vulnerability was in Adobe Flash Plugin which is shipped as an extra package for Red Hat Enterprise Linux (CVE-2018-4878), which was due to a "use after free" weakness (CWE-416). While in theory this could be mitigated by technologies designed to protect against exploitation of memory corruption, Red Hat does not recompile the Adobe Flash Plugin, and any hardening would have to be applied by the vendor, as Adobe Flash is not open source. Thus, Red Hat is not in a position to prevent this vulnerability.

Commonly Exploited Vulnerabilities at Red Hat

We now detail the most commonly reported vulnerabilities for Red Hat by year. We see that the same vulnerabilities are largely the same in the top for 2020, with new ones appearing in different years. This is reflective of the change in technology and the more modern security methods implemented over time. It is also reflective of the challenge of resolving particular CWEs. Of note are CWE-125, CWE-120, CWE-20, and CWE 400 with over 100 CVEs every year. CWE-120, CWE-125 are buffer overflows, CWE-20 is improper input sanitization, and CWE 400 is uncontrolled resource consumption. These are difficult flaws to protect against. 

Sanitizing input is very difficult to do perfectly, and requires a significant theoretical base to prevent any possible attacks. Uncontrolled resource consumption can be advantageous to fully utilize a piece of hardware. Buffer overflows are a common error in memory-unsafe languages, however the good news is that buffer overflows overall are declining. In general, CVEs are spread across a wider variety of CWEs than in the past. This makes it more challenging for security analysts to discover and fix vulnerabilities, but it underscores Red Hat’s unique position to provide this value-added security service with its subscription-based model. We can address flaws as they are discovered, no matter how tricky they may be to prevent.

Commonly Reported Critical Vulnerabilities at Red Hat

Next, we examine the top Critical CVEs, as opposed to simply the overall pattern of CVEs. As before, we see the increased spread of CVEs across CWEs and an overall decline in Critical CVEs. The same categories are remaining the main culprits, but Red Hat is increasingly preemptively securing the software against attacks. CWE-120 may be a buffer overflow, but as buffer overflows are overall on the decline, we can expect to see fewer Critical CVEs. In addition, Red Hat maintains software over time. We correct existing flaws when they are discovered, and are selective about upgrading to new upstream versions of software to prevent new flaws from being introduced. This results in the software we maintain having fewer vulnerabilities over time.

 

Conclusion

In conclusion, a Red Hat subscription provides a value-added service for security. Red Hat provides numerous tools for the security of our products and a consistent lifecycle with support. We have also documented a reduction in the most common types of attacks, which we attribute to our preventative measures of security by design. 

Despite attacks increasing, there is no indication that Red Hat is affected in 2020 more than in prior years and some evidence that we are affected less. This is due to our support of security and fixes for flaws. For high-security applications, supported open source software offers the benefits of both an open source development model and enterprise software support. Red Hat Enterprise Linux allows security technologies from the open source community to be enabled by default, and for vulnerabilities to be investigated as they are discovered.