Significance PaX

various types of computer insecurities caused errors in programs make possible alter function, allowing them rewritten while running. first 44 security notices issued ubuntu can categorized show 41% of vulnerabilities stem buffer overflows, 11% integer overflows, , 16% other bad handling of malformed data. these types of bugs open possibility inject , execute foreign code, or execute existing code out of order, , make 61% of sample group, discarding overlap. (this crude analysis; more comprehensive analysis of individual vulnerabilities give different numbers.) many worms, viruses, , attempts take on machine rely on changing contents of memory malware code executed; or on executing data contents misdirection. if execution of such malware blocked, little or no damage after being installed on computer; many, such sasser worm, prevented being installed @ all.

pax designed large number of possible attacks, , in applicable way. prevents execution of improper code controlling access memory (read, write, or execute access; or combinations thereof) , designed without interfering execution of proper code. @ cost of small amount of overhead, pax reduces many security exploits denial of service (dos) or remote code-flow control; exploits give attackers root access, allow access important information on hard drive, or cause other damage instead cause affected program or process crash little effect on rest of system.

a dos attack (or equivalent) annoyance, , may in situations cause loss of time or resources (e.g. lost sales business website affected); however, no data should compromised when pax intervenes, no information improperly copied elsewhere. nevertheless, equivalent of dos attack in environments unacceptable; businesses have level of service contracts or other conditions make successful intruder entry less costly problem loss of or reduction in service. pax approach not suited circumstances; however, in many cases, acceptable method of protecting confidential information preventing successful security breaches.

many, not all, programming bugs cause memory corruption. of do, , triggerable intent, make possible induce program various things not meant to, such producing high-privilege shell. focus of pax not on finding , fixing of such bugs, rather on prevention , containment of exploit techniques may stem such programmer error. subset of these bugs reduced in severity; programs terminate, rather improperly provide service.

pax not directly prevent buffer overflows; instead, prevents many of these , related programming bugs being used gain unauthorized entry computer system. other systems such stack-smashing protector , stackguard attempt directly detect buffer overflows, , kill offending program when identified; approach called stack-smashing protection, , attempts block such attacks before can made. pax s more general approach, on other hand, prevents damage after attempt begins. although both approaches can achieve of same goals, not entirely redundant. therefore, employing both will, in principle, make operating system more secure.

as of mid-2004, pax has not been submitted mainline kernel tree because pax team not find appropriate yet; although pax functional on many cpu architectures, including used x86 architecture, still remains partially or unimplemented on architectures. pax effective on include ia-32 (x86), amd64, ia-64, alpha, pa-risc, , 32 , 64 bit mips, powerpc, , sparc architectures.

limitations

pax cannot block fundamental design flaws in either executable programs or in kernel allow exploit abuse supplied services, these in principle undetectable. example, script engine allows file , network access may allow malicious scripts steal confidential data through privileged users accounts. pax cannot block format string bug based attacks, may allow arbitrary reading , writing data locations in memory using existing code; attacker not need know internal addresses or inject code program execute these types of attacks.

the pax documentation, maintained on pax web site, describes 3 classes of attacks pax attempts protect against. documentation discusses both attacks pax effective in protecting system , not. assume full, position independent executable base full executable space protections , full address space layout randomization. briefly, then, blockable attacks are:

because pax aimed @ preventing damage specific types attacks rather finding , fixing bugs permit them, cannot protect against kinds of attacks; indeed, preventing attacks impossible.

the first class of attacks still possible 100% reliability in spite of using pax if attacker not need advance knowledge of addresses in attacked task.

the second , third classes of attacks possible 100% reliability, if attacker needs advance knowledge of address space layout , can derive knowledge reading attacked task s address space. possible if target has bug leaks information, e.g., if attacker has access /proc/(pid)/maps. there obscurity patch nulls out values address ranges , inodes in every information source accessible userland close of these holes; however, not included in pax.

the second , third classes of attacks possible small probability if attacker needs advance knowledge of address space layout, cannot derive knowledge without resorting guessing or brute force search. aslr documentation describes how 1 can further quantify small probability these attacks have of success.

the first class of attacks possible if attacker can have attacked task create, write to, , mmap() file. in turn requires second attack method possible, analysis of applies here well. although not part of pax, recommended—among other things—that production systems use access control system prevents type of attack.

responsible system administration still required on paxified systems. pax prevents or blocks attacks exploit memory corruption bugs, such leading shellcode , ret2libc attacks. attacks pax can prevent related buffer overflow bugs. group includes common schemes used exploit memory management problems. still, pax cannot prevent of such attacks.