Issue #6 April 2005

What's new in security for Red Hat® Enterprise Linux® 4

Keeping any operating system up to date is a challenging task for even the most experienced system administrator. Red Hat Enterprise Linux is no exception in this respect, especially during times when a large number of security updates are released. While Red Hat Network greatly simplifies this process, getting everything updated still takes some time. Red Hat is continually developing technologies and processes to allow end users to more easily deal with threats. A number of these have been consolidated into Red Hat Enterprise Linux 4. Since no software will ever be bug free, the easiest solution is to leverage external technologies to help reduce the risk posed from malicious sources. The most notable technical changes would be the addition of SELinux and ExecShield. ExecShield is a project which encompasses support for the No eXecute (NX) memory permission, simulating NX via segment limits, Position Independent Executables (PIE), gcc, and glibc hardening. In addition to these technical changes, the process for communicating with the customer has been improved by adding a new security severity field to our security errata.

The threat posed by outside attackers has changed drastically over the last few years. In the past a system had to be protected from a dedicated attacker targeting a specific machine. Today the biggest threat posed to machines is large scale automated attacks such as worms and viruses. Compromised machines can then be used for Distributed Denial of Service attacks, attacking other machines, or propagating spam.

SELinux

One of the most visible technologies added to Red Hat Enterprise Linux 4 is Security-enhanced Linux, or SELinux. SELinux represents a technology which extends the current Linux security model beyond that of having merely a superuser. On a normal Linux system, an attacker that can acquire root privileges has complete access to the system. SELinux can limit the access even root has under certain circumstances, mitigating the amount of damage an attacker can do. These restrictions are controlled at the kernel level by policies specific to each protected program or library.

One of the best examples of SELinux usage is the Apache HTTP server. Under normal circumstances, the HTTP server is a well written and secure application; however, it is also the most widely used web server on the Internet. This means that when there is a security issue that affects the Apache HTTP server, the potential for damage is extremely high. Under normal circumstances, an attacker would be able to view and execute most files on the system upon successful exploitation. With SELinux support enabled, all an attacker will be able to do is execute and read web-related files. This of course is still not an ideal situation, but it can help prevent an attacker from leveraging additional services and misconfigurations to gain root access on a compromised machine.

ExecShield

ExecShield is a project that can make the exploitation of several types of security vulnerabilities much more difficult. The goal of a malicious attacker, be it a worm, virus, or person, is to have the ability to execute arbitrary instructions on a victim's machine. These attacks will focus on services that are accessible from the Internet or applications that can process an attacker's data such as an email client or web browser. The various technologies that are part of ExecShield can help prevent arbitrary code execution and simply cause the application to quit. This still leaves the potential for a Denial of Service type attack, but is much more ideal than arbitrary code execution.

Buffer overflows represent a class of security issues that are easy to exploit and exist in many programs. A buffer overflow is basically a flaw that allows an attacker to inject executable code of their choice into an already-running application. The ability to run arbitrary code rests on knowing certain memory addresses that the binary is using along with being able to execute the instructions from anywhere in memory. The NX and PIE technologies help make exploitation of a buffer overflow significantly harder. PIE can prevent the memory locations of the stack and heap from being predictable. In the event an attacker is able to locate a suitable memory location for exploitation, NX and segment limits will make exploitation very difficult.

It is possible for these technologies to be disabled at compile time. Some programs use memory in a manner that is incompatible with these technologies. Additional information can be found in the New Security Enhancements in Red Hat Enterprise Linux v.3, update 3 whitepaper.

gcc and glibc

Any time a piece of software is written, it has the potential to contain a number of common mistakes such as buffer overflows and format string flaws. C and C++ are especially susceptible to these issues since memory handling must be done by the programmer and can be very difficult. Sometimes these problems are very easy to detect and fix but are not always caught before something is released to the public. The added features to gcc and glibc in Red Hat Enterprise Linux 4 allow some of these flaws to be prevented.

A new feature has been added to gcc known as FORTIFY_SOURCE. During compilation of software when using the FORTIFY_SOURCE option, a warning is issued when a problem is detected. The FORTIFY_SOURCE option of course can not detect all problems, but it does help locate some very common issues that the programmer may miss such as buffer overflows. FORTIFY_SOURCE is not enabled in the programs compiled for Red Hat Enterprise Linux 4 yet but is available for ISVs to leverage in their own products.

Additionally a number of checks have been added to glibc to help prevent common programming mistakes. While a program is running, it is possible for bugs such as freeing a block of memory twice to be leveraged for malicious use. A feature has been added to glibc that can detect double free attempts and stop execution before malicious actions can be taken. It is also now possible for glibc to detect instructions which can lead to heap and stack corruption. The heap and stack are areas of memory that contain the data the running program uses. Careful corruption of these areas of memory can lead to arbitrary code execution or other malicious actions.

Errata classifications

Part of the challenge of producing security errata is the ability of the Red Hat Security Response Team to accurately relay information to the customer. We strive for the most accurate information possible along with a standardized format to make our advisories easy to understand. One of the goals of the Security Response Team is to ensure that the description of the issues being fixed is complete enough that risk assessment should be possible. When a customer views a security advisory, they should be able to easily identify how serious the problem being fixed is along with how it will affect their particular usage of a given program. This becomes more important when multiple advisories are released at the same time. Each customer deals with security updates in their own way, so by giving an accurate and clear severity overview, available resources may be leveraged to deal with the most important updates first.

Each advisory now contains a severity rating of low, moderate, important, or critical. The basic thought behind the severity ratings is "How worried is Red Hat." Issues that receive a rating of low are considered to pose the least security threat. Very unusual configurations, nearly harmless consequences, or heavy user interaction will be typically needed. Moderate issues pose a threat that needs user input or non-standard configurations for exploitation to be successful. Important issues can compromise the integrity or computing ability of the user. Many denial of service issues fall under this classification. Critical issues are those that require no user input and could be used by virus or worm writers for automatic propagation.

Each security advisory now contains one of these severities in the synopsis. Advisories that fix multiple issues display the most significant severity. If an advisory fixes an important and low issue, it is classified as "important." More information regarding the severity ratings can be found in the Classification of Security Issues whitepaper. When applying these criteria to the errata, we only lower the severity rating when one of our technologies completely blocks the issue rather than just reduces the risk.

Conclusion

None of these technologies will completely prevent security issues from happening, but they can help mitigate the threat. Separately, each technology has its own strengths, but when combined, they can have a significant impact on lowering the threat level. Many attacks are not directed at a specific computer but rather are just looking for a vulnerable machine. The added security technologies in Red Hat Enterprise Linux 4 prevent each machine from looking the same from the viewpoint of malware, thus stifling their ability to easily spread. Additionally, by explaining the advisories in a consistent manner, less time is required by a system administrator to decide which issues are the most important. The advisory clarification and added technologies will help system administrators spend less time worrying about updates and more time administering their systems.

About the author

Josh Bressers is a member of the Red Hat Security response team. He has been involved in information security for many years and has been a Linux enthusiast and user for even longer.