Security
Security-improving technologies which could be deployed now
Linux does not host the same applications as the more popular operating systems; it does not cater to the same host of bugs those applications provide to allow attackers to easily gain privileged access to the system. Still, if the same classes of bugs exist in Linux applications, the same problems arise. Linux is vulnerable to the same exploits as any other operating system when bugs exist to facilitate those exploits.Most popular Linux distributions do not make use of available security technologies that would deflect a large number of these attacks. There are technologies available today that allow the maintainers of distributions such as Gentoo, Debian, or Mandrake to make the system more resilient if not virtually invulnerable to these exploitable bugs. These technologies are open source, GPL licensed solutions to the future problems that Linux will face as it gains popularity.
There are many transparent security technologies available that maintainers could use to improve the security of a Linux distribution, such as Stack Smash Protection, PaX, and Position Independent Executables (PIE). These, such as can be safely and easily integrated with any distribution to improve security without altering the users' experience or administration of the system.
Stack Smash Protection
Stack Smash Protection is a method of detection and mitigation of stack based buffer overflow bugs in programs. There are several implementations; the one focused on here is IBM's Stack Smash Protector (SSP), formerly known as ProPolice. SSP prevents stack based buffer overflow bugs from being used to exploit programs in many cases.A fair number of security exploits begin with stack based buffer overflows. SSP rearranges local variables to put character arrays at the highest address and copies pointers passed to the function to new local variables below these arrays. This prevents a wide range of overflow based attacks. It uses a strategically placed local variable known as a "canary" or "guard value" to check for overflows.
SSP is implemented as a compiler patch to gcc. This patch alters the way functions are generated so that they check for buffer overflows. It can be used via the -fstack-protector and -fstack-protector-all switches, or by passing --enable-stack-protector to the configure script when building gcc. In either case, -fno-stack-protetctor[-all] explicitly disables the protection.
There are still some cases which SSP cannot catch, such as bugs affecting structures with vulnerable layouts; but it is definitely a powerful tool for preventing exploitation of many programming bugs. It may also expose some simple programming bugs, such as those which overflow a buffer by a few bytes. These bugs cause programs to crash during normal operation with SSP.
SSP was developed by Hiroaki Etoh and Kunikazu Yoda of the IBM Research Division, based on StackGuard. It was originally outlined in a paper by its authors. StackGuard was developed by Immunix Inc., and first appeared in 1998 or earlier. There have also been other papers examining stack smash protection techniques and implementation.
PaX
PaX is a patch to the Linux kernel source tree to implement memory protections which make certain classes of exploits difficult or impossible. Depending on architecture, PaX may have a very low or insignificant overhead. It is a powerful tool for preventing a great many potential exploits.
The Exec Shield (ES) technology contributed by Red Hat is somewhat similar to PaX; however, PaX supplies greater control over protections on individual binaries, as well as greater accuracy in its NX emulation on x86 architectures. ES has been compared to PaX on Wikipedia. Unless otherwise specified, full PaX with all features enabled except "Disallow ELF text relocations" will be discussed here.
PaX is a very feature rich technology. Instead of targeting a specific attack vector, PaX targets entire classes of exploits. Attacks using standard code injection are essentially impossible to successfully perform on a task running under full PaX restrictions; many of the more complex attacks are extremely difficult and often impossible to guarantee. Failed attacks result in the immediate termination of the program.
PaX guarantees that no memory is both writable and executable. The system administrator may deny all programs permission to use mprotect() to transition to a state where the page may be executed at any time after it could have been written to. It may emulate an NX bit to accomplish this; this is done on x86 with measurable but low overhead.
PaX also allows full Address Space Layout Randomization (ASLR). ASLR allows the stack, heap, mmap(), and even the .text of ET_EXEC executables to be mapped into randomly chosen bases in Virtual Memory (VM) space. In the absence of an information leak, an attacker would need to essentially guess at where any needed target data is in memory.
Some programs malfunction under PaX. Usually these programs expect behavior contrary to what PaX provides, and upon attempting to execute certain logic, PaX terminates them as if it had detected an exploit. PaX allows binaries to be "marked" with tools available to the system administrator to disable any individual protection supplied by PaX.
PaX was created by an anonymous author, originally supplying NX support based on an observation about the x86 architecture made by the plex86 project. Other features such as ASLR were implemented later. PaX first appeared in 2000, and was later incorporated into the grsecurity project. The PaX project supplies much documentation, and Wikipedia features an article about PaX.
Position Independent Executables
Position Independent Executables, or PIE, are executables compiled as Position Independent Code (PIC). PIC is usually slower than fixed position code; however, it can be easily relocated in memory. PIE allows the safe and efficient randomization of the base of executable binaries in VM by PaX or ES, preventing an attacker from knowing beforehand where preexisting code is in memory.
Compiling PIE binaries is done by passing gcc the -fPIC or -fPIE switches; linking them is done by passing -pie to gcc or to the linker. The -fPIE switch only works with gcc 3.4, but -fPIC will work for all. Regardless of which switch is used, the output is an executable ET_DYN binary.
Using PIE, the code in executable binaries suffers measurable overhead, the magnitude of which varies between CPU architectures. On x86, this is approximately 1%; whereas on x86_64, the overhead is approximately 0.01%. Because this overhead is not applied everywhere, it can usually be said to be negligible on any architecture in relation to PIE.
Deployment
Many security focused open source operating systems deploy these or similar technologies. OpenBSD supplies its own PaX-type system, W^X; OpenBSD also uses SSP; but apparently does not supply a PIE base. Hardened Gentoo and Adamantix supply PaX, SSP, and PIE; along with other, more visible technologies such as SELinux or RSBAC. It is left up to speculation why the most popular Linux distributions do not supply the transparent features, although there is effort to persuade Debian to use these, by the Debian: Secure by Default and the Hardened Debian projects.
New vulnerabilities
cyrus-sasl: remote buffer overflow
| Package(s): | cyrus-sasl | CVE #(s): | CAN-2004-0884 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | October 7, 2004 | Updated: | March 16, 2005 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | cyrus-sasl has a vulnerability involving a buffer overflow in the digestmda5.c file. A remote attacker may be able to compromise the system. Also, a local user may be able to exploit a vulnerability by using the SASL_PATH environment variable. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||
ed: Insecure temporary file handling
| Package(s): | ed | CVE #(s): | CVE-2000-1137 | ||||
| Created: | October 11, 2004 | Updated: | October 13, 2004 | ||||
| Description: | ed insecurely creates temporary files in world-writeable directories with predictable names. Given that ed is used in various system shell scripts, they are by extension affected by the same vulnerability. A local attacker could create symbolic links in the temporary files directory, pointing to a valid file somewhere on the filesystem. When ed is called, this would result in file access with the rights of the user running the utility, which could be the root user. | ||||||
| Alerts: |
| ||||||
gettext: Insecure temporary file handling
| Package(s): | gettext | CVE #(s): | CAN-2004-0966 | ||||||||||||||||||||||||
| Created: | October 11, 2004 | Updated: | March 1, 2006 | ||||||||||||||||||||||||
| Description: | gettext insecurely creates temporary files in world-writeable directories with predictable names. A local attacker could create symbolic links in the temporary files directory, pointing to a valid file somewhere on the filesystem. When gettext is called, this would result in file access with the rights of the user running the utility, which could be the root user. | ||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||
mysql: several vulnerabilities
| Package(s): | mysql | CVE #(s): | CAN-2004-0835 CAN-2004-0836 CAN-2004-0837 | ||||||||||||||||||||||||||||||||||||||||||||
| Created: | October 11, 2004 | Updated: | April 6, 2005 | ||||||||||||||||||||||||||||||||||||||||||||
| Description: | Several problems have been discovered in MySQL. Oleksandr Byelkin noticed that ALTER TABLE ... RENAME checks CREATE/INSERT rights of the old table instead of the new one. (CAN-2004-0835) Lukasz Wojtow noticed a buffer overrun in the mysql_real_connect function. (CAN-2004-0836) Dean Ellis noticed that multiple threads ALTERing the same (or different) MERGE tables to change the UNION can cause the server to crash or stall. (CAN-2004-0837) | ||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||
ncompress: Buffer overflow
| Package(s): | compress uncompress ncompress | CVE #(s): | CAN-2001-1413 | ||||||||
| Created: | October 11, 2004 | Updated: | December 14, 2004 | ||||||||
| Description: | compress and uncompress do not properly check bounds on command line options, including the filename. Large parameters would trigger a buffer overflow. By supplying a carefully crafted filename or other option, an attacker could execute arbitrary code on the system. A local attacker could only execute code with his own rights, but since compress and uncompress are called by various daemon programs, this might also allow a remote attacker to execute code with the rights of the daemon making use of ncompress. | ||||||||||
| Alerts: |
| ||||||||||
squid: denial of service vulnerability
| Package(s): | squid | CVE #(s): | CAN-2004-0918 | ||||||||||||||||||||||||||||||||||||
| Created: | October 7, 2004 | Updated: | November 8, 2004 | ||||||||||||||||||||||||||||||||||||
| Description: | Squid has a potential denial of service vulnerability and a problem with readable passwords due to incorrect permissions on the squid.conf file. | ||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||
tiff: buffer overflows
| Package(s): | tiff | CVE #(s): | CAN-2004-0803 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | October 13, 2004 | Updated: | April 12, 2005 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | The tiff library contains several buffer overflows which may be exploited by way of maliciously-crafted image files. See this advisory for more information. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Resources
Secure programmer: Prevent race conditions (IBM developerWorks)
David A. Wheeler writes about the prevention of race conditions on IBM developerWorks. "Learn what a race condition is and why it can cause security problems. This article shows you how to handle common race conditions on UNIX®-like systems, including how to create lock files correctly, alternatives to lock files, how to handle the filesystem, and how to handle shared directories (and in particular how to correctly create temporary files in the /tmp directory). You'll also learn a bit about signal handling."
Page editor: Jonathan Corbet
Next page:
Kernel development>>