2005. Programming Languages Security - A Survey

Programming Languages Security: A Survey For PractitionersNihal A. D’Cunha, Massimiliano Pala, Sean W. SmithDepartment of Computer ScienceDartmouth Collegenihal,pala,sws@cs.dartmouth.eduAbstractSecurity vulnerabilities, such as buffer overflows, induced byprogramming errors are the fundamental cause for softwareinsecurity. Secure protocols and technologies have made incredible advances in the past few years while programmerscontinue to face the same problems and predicaments duringapplication development. This paper focuses on programminglanguages and tools that attempt to guarantee safety and security.

It surveys security vulnerabilities in programming languages, suggests safe language alternatives and reviews therange of software solutions to the security flaws in C in an attempt to provide a complete overview of the existing problemsand their possible solutions.Figure 1: Vulnerabilities reported to CERT/CC 2000-2005In this paper we survey the issues involved in designing,writing and implementing code that is robust against attacks.We look at potential vulnerabilities, outline possible softwaresolutions and review most relevant safe programming languages.Since C is the most prevalent language for software development and because most other language implementationsmake use of C-developed libraries, we take a detailed look atit from a security point of view.We enumerate vulnerabilities in C that permit several dangerous exploits, making it an unsafe programming language,and outline several tools that help detect and prevent these security flaws in C code.The rest of the paper is organized as follows.

Section 2 isa survey of the common security vulnerabilities in programs.Section 3 outlines a few modern day safe programming languages. Section 4 enumerates tools that can be used to detectand overcome security flaws in C. Finally, Section 5 presentsour conclusions.The intended target audiences for this paper are softwaremanagers, developers and programmers.

The paper addressesissues related to building secure applications and writing secure code by making known what choices are available whenstarting out on new safety-critical projects.1IntroductionIn today’s networked world where computers have becomeubiquitous, computer attacks have become a serious problem.Nearly all applications nowadays need to be secure. However,writing secure code is non-trivial. Security holes in softwareare common, and the problem is growing.

Programmers haveto design and write code that is robust and withstands attacksby malicious users. There are numerous exploits and attacksthat deliberately seek out and cause exceptional or uncommonsituations, such that unwarranted privileges are obtained. Statistics from the CERT Coordination Center at Carnegie Mellon University, reveal that after a marginal decrease in thenumber of reported software vulnerabilities in 2003 and 2004,reports are on the rise once again [13], as shown in Figure 1.2Survey of VulnerabilitiesMemory errors are the most commonly used means by whichattackers attempt to gain control over an application [100].Memory-safety is therefore a prerequisite for security, andattacks that exploit memory-safety are most often to blame forinsecurity in deployed software [93].

Attackers exploit these1stringgrowtharguments to functionhigher addressedmemorydard library) without the need to inject malicious code into theprogram.Buffer overflows can also be used to overwrite securitysensitive variables or control data stored in memory areas adjacent to the buffer being overflown.Other stacked-based exploits involve frame pointer overwriting [49] and indirect pointer overwriting [10].Heap-basedDynamically allocated variables (those allocated by themalloc() family of functions) are created on the heap segment at run-time by the application.

Heap-based arrays areoverflown in a manner similar to that of stack-based arrays,except that the heap grows from lower addressed memory tohigher addressed memory while the stack grows from higheraddressed memory to lower addressed memory. As there areno return addresses stored on the heap, alternative methodsare used to manipulate the control-flow.Heap memory is usually divided and allocated in chunkswhich contain memory management information within them.When a heap buffer overflow occurs, it attempts to overwritethe memory management information of the next chunk inmemory with specific values in order to transfer control tothe attack code.Other techniques of overflowing the heap are either byoverwriting function pointers [16] or virtual function pointers [75].function’s return addresssaved frame pointerstackgrowthlocal variables(including buffers)return address overwrittento point back into bufferthat contains injected codelower addressedmemoryFigure 2: Stack smashingvulnerabilities, to transfer program control to code that theyhave injected (which is usually to start a new shell with rootpermissions).

A memory-safe program will never overwhelma buffer or write carelessly over memory that it is not supposedto.2.1Buffer OverflowsBuffer overflows are the cause of several software vulnerabilities that lead to security breaches. Most buffer overflowrelated problems stem from input that is not checked for sanity before use.

In this section we analyze Stack-based andHeap-based types of buffer overflow.Stack-basedA buffer, which is an array of identical datatypes stored incontiguous memory locations, is easy to overflow, as not allprogramming languages implement bounds checking or maintain array-size information. At run-time, programs are able towrite data beyond the end of the array, overwriting adjacentmemory areas which usually contain the address to resumeexecution at after a function has completed execution.For every function call, a new stack frame is added to thetop of the stack.

The stack frame contains arguments to thefunction, the return address, the frame pointer, locally declared variables (including buffers), and other data. When excess data is written into a buffer because proper checking isnot performed, the extra data will overflow into the adjacenthigher addressed memory. This can be abused to overwrite thereturn address and hence change the flow control of the program. When the function returns, control will be transferedvia the modified return address to a specific address which isusually where the attacker’s code is stored, allowing it to execute with the same privileges as the exploited program.

Codethat does this is said to “smash the stack” [1]. A stack smashing attack is shown in Figure 2.A return-to-libc attack modifies the return address to pointto pre-existing functions (e.g., such as those in the libc stan-2.2Dangling Pointer ErrorsA dangling pointer is a reference to an object that no longerexists at that address. Dangling pointers could arise from various conditions [57]:• reference to an object is retained after explicit deallocation of it on calling free().• reference to a stack-allocated object is retained after therelevant stack frame has been popped.• reference to a heap-allocated object is retained after therelevant block has been freed and reused.Conventionally, C compilers do not verify pointer deferences,resulting in dangerous and elusive dangling pointer dereference vulnerabilities.

Programs that deference dangling pointers usually crash, produce garbled output or display unpredictable behavior. Although, a special case of the dangling pointer reference bug called the double free vulnerability could cause memory corruption resulting in an attack [41]. A double free attack could occur when a program attempts to free memory that has already been previously deallocated [22].2than its minimum value. If one tries to put a value intoa datatype that is too small to hold it, the high-order bitsare dropped and only the low-order bits are stored.

That is,modulo-arithmetic is performed on the value before storing itto make sure it fits within the datatype. Most compilers tendto disregard this overflow, causing programs that do not anticipate this unexpected or inaccurate result to potentially fail.If memory is being allocated based on an unsigned integer datatype’s value and the value wraps around, insufficientmemory might be allocated leading to a possible heap overflow.Integer signedness errors occur when an unsigned variable is treated as signed, or when a signed variable is treatedas unsigned.