Information AboutPax |
| CATEGORIES ABOUT PAX | |
| latin words and phrases | |
|
In Computer Security , PaX is a Patch for the Linux Kernel that implements least privilege protections for Memory Page s. The least-privilege approach allows Computer Program s to do only what they have to do in order to be able to execute properly, and nothing more. PaX was first released in 2000. PaX flags data memory as non-executable and program memory as non-writable, and randomly arranges the program memory. This effectively prevents many Security Exploits , such as some kinds of Buffer Overflow s. The former prevents direct Code Execution absolutely, while the latter makes so-called Return-to-libc (ret2libc) attacks difficult to exploit, relying on luck to succeed, but doesn't prevent variables and pointers overwriting. PaX was written by The PaX Team. The principal author of PaX declared his wish to remain anonymous. Mascot , Tux .]] SIGNIFICANCE Many, and perhaps even most, computer insecurities are due to errors in programs that make it possible to alter the function of the program, effectively allowing a program to be "rewritten" while running. The first 44 s, 11.4% from Integer Overflow s, and 15.9% from other bad handling of malformed data. These types of bugs often open the possibility to inject and execute foreign code, or execute existing code out of order, and make up 61.4% of the sample group, discarding overlap. This analysis is very crude; a more comprehensive analysis of individual vulnerabilities would likely give very different numbers, possibly higher or lower. Many Worms , Viruses , and attempts to take over a machine rely on changing the contents of memory so that the Malware code is executed; or on executing "data" contents by misdirection. If execution of such malware could be blocked, it could do little or even no damage even after being installed on a computer; many, such as the Sasser Worm , could be prevented from being installed at all. PaX was designed to do just that for a large number of possible attacks, and to do so in a very generally applicable way. It prevents execution of improper code by controlling access to memory (read, write, or execute access; or combinations thereof) and is designed to do so without interfering with execution of proper code. At the cost of a small amount of overhead, PaX reduces many security exploits to a Denial Of Service (DoS) or a remote code-flow control; exploits which would normally give attackers Root Access , allow access to important information on a hard drive, or cause other damage will instead cause the affected program or process to Crash with little effect on the rest of the system. A DoS attack (or its equivalent) is generally an annoyance, and may in some situations cause loss of time or resources (e.g. lost sales for a Business whose website is affected); however, no data should be compromised when PaX intervenes, as no information will be improperly copied elsewhere. Nevertheless, the equivalent of a DoS attack is in some environments unacceptable; some businesses have Level Of Service Contracts or other conditions which make successful intruder entry a less costly problem than loss of or reduction in service. The PaX approach is thus not well suited to all circumstances; however, in many cases, it is an acceptable method of protecting Confidential Information by preventing successful security breaches. Many, but not all, programming bugs cause memory corruption. Of those that do, and are triggerable by intent, some will make it possible to induce the program to do various things it wasn't meant to, such as give a high-privileged shell. The focus of PaX is not on the finding and fixing of such bugs, but rather on prevention and containment of exploit techniques which may stem from such programmer error. A Subset of these bugs will be reduced in severity; programs terminate, rather than improperly provide service. PaX does not directly prevent buffer overflows; instead, it effectively prevents many of these and related programming bugs from being used to gain unauthorized entry into a computer system. Other systems such as Stack-Smashing Protector and StackGuard do attempt to directly detect buffer overflows, and kill the offending program when identified; this approach is called Stack-smashing Protection , and attempts to block such attacks before they can be made. PaX's more general approach, on the other hand, prevents damage after the attempt begins. Although both approaches can achieve some of the same goals, they are not entirely redundant. Therefore, employing both will, in principle, make an operating system more secure. Some Linux distributions already use the PaX with Stack Smash Protection combination. As of mid 2004, PaX has not been submitted for the mainline kernel tree because The PaX Team does not think it yet appropriate; although PaX is fully functional on many CPU Architecture s, including the popular X86 architecture used by most, it still remains partially or fully unimplemented on some architectures. Those that PaX is effective on include IA-32 ( X86 ), AMD64 , IA-64 , Alpha , PA-RISC , and 32 and 64 Bit MIPS , PowerPC , and SPARC architectures. Limitations PaX cannot block fundamental design flaws in either executable programs or in the kernel that allow an exploit to abuse supplied services, as these are in principle undetectable. For example, a script engine which allows file and network access may allow malicious scripts to steal confidential data through privileged users' accounts. PaX also cannot block some Format String Bug based attacks, which may allow arbitrary reading from and writing to data locations in memory using already existing code; the attacker does not need to know any internal addresses or inject any code into a program to execute these types of attacks. The PaX documentation {Link without Title} , maintained on the PaX Web site, describes three classes of attacks which PaX attempts to protect against. The documentation discusses both attacks for which PaX will be effective in protecting a system and those for which it will not. All assume a full, position independent executable base with full Executable Space Protections and full Address Space Layout Randomization. Briefly, then, blockable attacks are: # Those which introduce and execute arbitrary code. These types of attacks frequently involve Shellcode . # Those which attempt to execute existing program code out of the original order intended by the computer programmer(s). This is commonly called a Return-to-libc Attack , or ret2libc for short. # Those which attempt to execute existing program code in the intended order with arbitrary data. This issue existed in Zlib versions before 1.1.4—a corrupt compressed stream could cause a double-free. Because PaX is aimed at preventing damage from such attacks rather than finding and fixing the bugs that permit them, it is not yet possible to prevent all attacks; indeed, preventing all attacks is Impossible . The third class of attacks is still possible with 100% reliability in spite of using PaX if the attacker does not need advance knowledge of addresses in the attacked task. The second and third classes of attacks are also possible with 100% reliability, if the attacker needs advance knowledge of Address Space Layout and can derive this knowledge by reading the attacked task's address space. This is possible if the target has a bug which leaks information, eg, if the attacker has access to /proc/(pid)/maps. There is an obscurity patch which NULLs out the values for the address ranges and inodes in every information source accessible from userland to close most of these holes; however, it is not currently included in PaX. The second and third classes of attacks are possible with a small probability if the attacker needs advance knowledge of address space layout, but cannot derive this knowledge without resorting to guessing or to a brute force search. The ASLR documentation {Link without Title} describes how one can further quantify the "small probability" these attacks have of success. The first class of attacks is possible if the attacker can have the attacked task create, write to, and Mmap() a file. This in turn requires the second attack method to be possible, so an analysis of that applies here as well. Although not part of PaX, it is recommended — among other things — that production systems use an access control system that prevents this type of attack. Responsible system administration is still required even on PaXified systems. PaX prevents or blocks attacks which exploit Memory Corruption bugs, such as those leading to Shellcode and ret2libc attacks. Most attacks that PaX can prevent are related to buffer overflow bugs. This group includes the most common schemes used to exploit memory management problems. Still, PaX cannot prevent all of such attacks. WHAT PAX OFFERS PaX offers Executable Space Protections , using (or Emulating in operating system software) the functionality of an NX Bit (i.e., built-in CPU / MMU support for memory contents execution privilege tagging). It also provides Address Space Layout Randomization to defeat ''ret2libc'' attacks and all other attacks relying on known structure of a program's Virtual Memory . Executable space protections The major feature of PaX is the executable space protection it offers. These protections take advantage of the NX bit on certain processors to prevent the execution of arbitrary code. This staves off attacks involving code injection or shellcode. On IA-32 CPU s where there is no NX bit, PaX can emulate the functionality of one in various ways. Many operating systems, Linux included, take advantage of existing NX functionality in hardware to apply proper restrictions to memory. Fig. 1 shows a simple set of memory segments in a program with one loaded library; green segments are data and blue are code. In normal cases, the address space on AMD64 and other such processors will by default look more like Fig. 1, with clearly defined data and code. Unfortunately, Linux by default does not prohibit an application from changing any of its memory protections; any program may create Data-code Confusion , marking areas of code as writable and areas of data as executable. PaX prevents such changes, as well as guaranteeing the most restrictive default set suitable for typical operation. When the Executable Space Protections are enabled, including the Mprotect () restrictions, PaX guarantees that no Memory Mappings will be marked in any way in which they may be executed as program code after it has been possible to alter them from their original state. The effect of this is that it becomes impossible to execute memory during and after it has been possible to write to it, until that memory is destroyed; and thus, that code cannot be injected into the application, malicious or otherwise, from an internal or external source. The fact that programs cannot themselves execute data they originated as program code poses an impassable problem for applications that need to generate code at runtime as a basic function, such as Just-in-time compilers for Java ; however, most programs that have difficulty functioning properly under these restrictions can be Debugged by the programmer and fixed so that they do not rely on this functionality. For those that simply need this functionality, or those that haven't yet been fixed, the program's executable file can be marked by the system administrator so that it does not have these restrictions applied to it. The PaX team had to make some design decisions about how to handle the Mmap () System Call . This function is used to either map Shared Memory , or to load shared libraries. Because of this, it needs to supply writable or executable RAM, depending on the conditions it is used under. The current implementation of PaX supplies writable anonymous memory mappings by default; file backed memory mappings are made writable only if the mmap() call specifies the write permission. The mmap() function will never return mappings that are both writable and executable, even if those permissions are explicitly requested in the call. Enforced non-executable pages By default, Linux does not supply the most secure usage of non-executable memory pages, via the NX bit. Furthermore, some architectures do not even explicitly supply a way of marking memory pages non-executable. PaX supplies a Policy to take advantage of non-executable pages in the most secure way possible. In addition, if the CPU does not provide an explicit NX bit, PaX can emulate (supply) an NX bit by one of several methods. This degrades performance of the system, but increases security greatly. Furthermore, the performance loss in some methods may be low enough to be ignored. = PAGEEXEC PAGEEXEC uses or emulates an NX bit. On processors which do not support a hardware NX, each page is given an emulated NX bit. The method used to do this is based on the architecture of the CPU. If a hardware NX bit is available, PAGEEXEC will use it instead of emulating one, incurring no performance costs. On IA-32 architectures, NX bit emulation is done by changing the permission level of non-executable pages. The Supervisor bit is overloaded to represent NX. This causes a Protection Fault when access occurs to the page ''and'' it is not yet cached in the Translation Lookaside Buffer . In this case, the Memory Management Unit alerts the operating system; on IA-32, the MMU typically has separate TLB caches for execution (ITLB) and read/write (DTLB), so this fault also allows Linux and PaX to determine whether the program was trying to execute the page as code. If an ITLB fault is caught, the process is terminated; otherwise Linux forces a DTLB load to be allowed, and execution continues as normal. PAGEEXEC has the advantage of not dividing the Memory Address Space in half; tasks still each get a 3 GB virtual ramspace rather than a 1.5/1.5 split. However, for emulation, it is slower than SEGMEXEC and caused a severe Performance detriment in some cases. Since May 2004, the newer PAGEEXEC code for IA-32 in PaX tracks the highest executable page in virtual memory, and marks all higher pages as user pages. This allows data pages above this limit —such as the stack—to be handled as normal, with no performance loss. Everything below this area is still handled as before. This change is similar to the Exec Shield NX implementation, and the OpenBSD W^X implementation; except that PaX uses the Supervisor bit overloading method to handle NX pages in the code segment as well. = SEGMEXEC SEGMEXEC emulates the functionality of an NX bit on IA-32 (x86) CPUs by splitting the address space in half and mirroring the code mappings across the address space. When there is an Instruction Fetch , the fetch is translated across the split. If the code isn't mapped there, then the program is killed. SEGMEXEC cuts the task's virtual memory space in half. Under normal circumstances, programs get a VM space 3GiB wide, which has Physical Memory mapped into it. Under SEGMEXEC, this becomes a 1.5/1.5 GiB split, with the top half used for the mirroring. Despite this, it does increase performance if emulation must be done on IA-32 (x86) architectures. The mapping in the upper and lower half of the memory space is to the same physical memory page, and so does not double RAM usage. Restricted mprotect() PaX is supposed to guarantee that no RAM is both writable and executable. One function, the mprotect() function, changes the permissions on a memory area. The Single UNIX Specification defines mprotect() with the following note in its description: If an implementation cannot support the combination of access types specified by prot, the call to mprotect() shall fail. |
|
|