2005. Programming Languages Security - A Survey, страница 10

Thisapproach aims at protecting against all known and unknownmemory error exploits.The techniques used in achieving this randomization aresketched below.PointGuardPointGuard is a C compiler enhancement that seeks to protect pointers by encrypting them when they are stored in memory and decrypting them just prior to dereferencing, i.e.

whenthey are loaded into CPU registers, where they are not threatened by overwriting, as registers are not directly addressable thru calculated addresses. Attackers will still be able tocorrupt pointers stored in memory, but cannot produce predictable pointer values as they have no knowledge of the decryption key.“PointGuard critically depends on a load/store instructiondiscipline” [18], where pointers are always loaded into registers before being dereferenced and operated upon.The encryption key is generated when program executionbegins, using some source of randomness such as a valuefrom /dev/random.

This key is then kept secret withinthe process’s address space, but is available to other processesthat share memory. Encryption is done by XOR’ing pointersagainst the key, and decryption is done in a similar fashion byXOR’ing again against the same key. Brute force guessing isimpractical, as incorrect guesses cause the process to abort,and the new process will have a different key.A possible way to bypass PointGuard protection is to guessthe decryption key by causing the program to print out pointerinformation via some other means.The encryption has been kept simple so as to avoid performance overheads and performance costs have been found tobe between 0%-20%.PointGuard is no longer available.4.5• Randomizing variables on the stack – at run-time thepositions of variables on the stack are continuouslychanged.

This is done via:1. Shadow stack – arrays and structures are allocatedon a different stack, thereby preventing overflowsfrom corrupting return addresses or pointer variables. The allocation order of these buffer variablesis also varied for each call.2. Randomizing the base of stackframes – to blur thelocation of other data on the stack, the base of thestack is randomized, and stack frames are separatedby random-sized gaps.• Static data randomization – the location and relative order of static variables is determined at the start of thetransformed program execution.

Accesses to these staticvariables are then converted to be carried out in an indirect manner. This is done by converting the program toonly have static pointer variables that store the locationof these static variables. The static pointer variables arestored in read-only memory to prevent against attacks.Kernel and Operating System AlterationsKernel and Operating system modifications try to prevent amalicious user’s injected code from executing.

The focus hereis not on finding and fixing exploitation of software bugs butrather on prevention and containment of exploit techniques.To use these tools the kernel of the operating system needsto be patched with them and the system built and rebootedwith the patched kernel. Minor modifications might evenneed to be made to some of the system configuration files.• Code randomization – code is randomized at the function granularity level.

Each function is associated witha function pointer and every function call is transformed19into an indirect call via the function pointer. By updatingthe function pointers to point to different locations of thefunction body, the order of functions can be changed inthe executable. Function pointers are write-protected toprevent against attacks.Shacham et al. [83] have shown that Pax ASLR is not veryeffective on 32-bit architectures. The randomization that itintroduces is not resistant to brute force attacks.PaX is functional and effective on many CPU architectures,including IA-32 (x86), IA-64, Alpha, PA-RISC, PowerPC,SPARC and SPARC64.In addition to these steps, “the base of the heap, gaps between heap allocations, and the location of functions in sharedlibraries” [76] are randomized.The tool has been built for RedHat Linux 9.0 and isshipped under GPL.4.6Library PatchesLibrary patches help make programs that are dynamicallylinked safe without requiring them to be recompiled.After the libraries have been installed, programs will needto be either implicitly or explicitly linked to them at run-time.The loader will look for these libraries and add the relevantdata from them into the process’s memory space.Solar Designer’s Non-executable stackStack smashing attacks are based on overwriting a function’s return address on the stack to point to some arbitrarycode in the stack, which is executed when the function returns.

Solar Designer’s Linux kernel patch [55] makes thestack segment non-executable so the operating system will notallow instructions to be executed in the this portion of a userprocess’s virtual address space, making buffer overflow vulnerabilities more difficult to exploit.However, making the stack non-executable can cause certain programs (some Lisp compilers) that rely on its executability to break [100]. The non-executable stack cannot prevent buffer overflow attacks that do not use the stackto place their attack code.

Attack code injected into heapallocated or statically allocated buffers can be used as exploits.The stack patch can also be circumvented by using a returnto-libc attack [98].The patch does not impose any performance overhead norrequire program recompilation. Its use however requires thekernel of the operating system to be patched. The patch isavailable for Linux 2.0.x, 2.2.x and 2.4.x.Libsafe - LibverifyLibsafe - Libverify [3] are methods to overcome bufferoverflow attacks. Both methods are implemented as dynamically loadable libraries and have performance overhead rangesbetween 0% - 15%.Libsafe replaces calls to known vulnerable library functions with a comparable version that ensures that any bufferoverflows are contained within the local stackframe. It triesto automatically approximate a safe upper limit on the size ofbuffers by recognizing that such local buffers cannot extendbeyond the end of the current stack frame; i.e.

it uses the calling function’s frame pointer as an upper limit for writing tostack variables. The substitute function then enforces theseboundaries, preventing the return address located on the stackfrom being overwritten.Libsafe does not need access to program source code, nordoes it require recompilation of binaries.

It however fails toprovide protection against heap-based buffer overflow attacksor to programs that do not use the standard C library functionsto copy into the buffer [84].It does not substitute the standard C library; instead it relies on the loader searching for it before the standard C library,so that the safe LibSafe functions are used instead of the standard unsafe library functions.

By suitably setting environmentvariables LibSafe can be installed as the default library.It is implemented on Linux and the source code is availableunder the GNU Lesser General Public License from here [54].Libverify inserts checks dynamically into a processes’memory to implement a scheme that verifies a function’sreturn address before it is used. Like Libsafe it works withpre-compiled binaries. On entering a function, it copies thereturn address onto a return address stack (canary stack ),which is in the heap, and on exiting the function the savedreturn address and the actual return address are compared.

Ifthere is a mismatch, execution is halted and an alert raised.PaXPaX [68] is a Linux kernel patch that implements nonexecutable stack and heap memory pages. It prevents execution of unsafe code by moderating access to memory pagesand is able to do so without interfering with execution ofproper code. Unlike Solar Designer’s non-executable stackpatch, PaX is able to protect the heap as well.It implements least privilege protection for memory pagesi.e. only data in a processes’s address space that needs to beexecutable will be granted execute permissions.Pax provides protection in two ways – making all writablememory pages non-executable (PAGEEXEC) and by usingaddress space layout randomization (ASLR).

It uses ASLRto randomize mmap()’ed library base addresses. This counteracts many security exploits, such as buffer overflow andreturn-to-libc attacks, but in effect reduces them to denialof service (DoS) attacks. It incurs a small amount of overhead [69].20It however does not protect the integrity of the canary stack.Libverify does not require access to the source code of theapplication, and hence can be used for legacy programs aswell.ily signify that the tool completely defends against that particular vulnerability. It only suggests that the tool has somemechanism for dealing with that vulnerability.