buffer overflow in information security and programming a buffer overflow or buffer overrun is an anomaly where a program while writing data to a buffer overruns the buffers boundary and overwrites adjacent memory locations buffers are areas of memory set aside to hold data often while moving it from one section of a program to another or between programs buffer overflows can often be triggered by malformed inputs if one assumes all inputs will be smaller than a certain size and the buffer is created to be that size then an anomalous transaction that produces more data could cause it to write past the end of the buffer if this overwrites adjacent data or executable code this may result in erratic program behavior including memory access errors incorrect results and crashes exploiting the behavior of a buffer overflow is a wellknown security exploit on many systems the memory layout of a program or the system as a whole is well defined by sending in data designed to cause a buffer overflow it is possible to write into areas known to hold executable code and replace it with malicious code or to selectively overwrite data pertaining to the programs state therefore causing behavior that was not intended by the original programmer buffers are widespread in operating system os code so it is possible to make attacks that perform privilege escalation and gain unlimited access to the computers resources the famed morris worm in 1988 used this as one of its attack techniques programming languages commonly associated with buffer overflows include c and c which provide no builtin protection against accessing or overwriting data in any part of memory and do not automatically check that data written to an array the builtin buffer type is within the boundaries of that array bounds checking can prevent buffer overflows but requires additional code and processing time modern operating systems use a variety of techniques to combat malicious buffer overflows notably by randomizing the layout of memory or deliberately leaving space between buffers and looking for actions that write into those areas canaries technical description a buffer overflow occurs when data written to a buffer also corrupts data values in memory addresses adjacent to the destination buffer due to insufficient bounds checking this can occur when copying data from one buffer to another without first checking that the data fits within the destination buffer example further information on stackbased overflows stack buffer overflow in the following example expressed in c a program has two variables which are adjacent in memory an 8bytelong string buffer a and a twobyte bigendian integer b char a unsigned short b 1979 initially a contains nothing but zero bytes and b contains the number 1979 variable name a b value 1979 hex value 00 00 00 00 00 00 00 00 07 bb now the program attempts to store the nullterminated string excessive with ascii encoding in the a buffer strcpya excessive excessive is 9 characters long and encodes to 10 bytes including the null terminator but a can take only 8 bytes by failing to check the length of the string it also overwrites the value of b variable name a b value e x c e s s i v 25856 hex 65 78 63 65 73 73 69 76 65 00 bs value has now been inadvertently replaced by a number formed from part of the character string in this example e followed by a zero byte would become 25856 writing data past the end of allocated memory can sometimes be detected by the operating system to generate a segmentation fault error that terminates the process to prevent the buffer overflow from happening in this example the call to strcpy could be replaced with strncpy which takes the maximum capacity of a as an additional parameter and ensures that no more than this amount of data is written to a strncpya excessive sizeofa note that the above code is not free from problems either while a buffer overrun has been prevented this time the strncpy library function does not nullterminate the destination buffer if the source strings length is greater than or equal to the size of the buffer the third argument passed to the function therefore a is in this case not nullterminated and cannot be treated as a valid cstyle string exploitation the techniques to exploit a buffer overflow vulnerability vary by architecture by operating system and by memory region for example exploitation on the heap used for dynamically allocated memory differs markedly from exploitation on the call stack stackbased exploitation stack buffer overflow a technically inclined user may exploit stackbased buffer overflows to manipulate the program to their advantage in one of several ways by overwriting a local variable that is located near the vulnerable buffer on the stack in order to change the behavior of the program by overwriting the return address in a stack frame once the function returns execution will resume at the return address as specified by the attacker usually a userinput filled buffer by overwriting a function pointer or exception handler which is subsequently executed by overwriting a local variable or pointer of a different stack frame which will be used by the function which owns that frame later if the address of the usersupplied data used to affect the stack buffer overflow is unpredictable exploiting a stack buffer overflow to cause remote code execution becomes much more difficult one technique that can be used to exploit such a buffer overflow is called trampolining in that technique an attacker will find a pointer to the vulnerable stack buffer and compute the location of their shellcode relative to that pointer then they will use the overwrite to jump to an instruction already in memory which will make a second jump this time relative to the pointer that second jump will branch execution into the shellcode suitable instructions are often present in large code the metasploit project for example maintains a database of suitable opcodes though it lists only those found in the windows operating system heapbased exploitation heap overflow a buffer overflow occurring in the heap data area is referred to as a heap overflow and is exploitable in a manner different from that of stackbased overflows memory on the heap is dynamically allocated by the application at runtime and typically contains program data exploitation is performed by corrupting this data in specific ways to cause the application to overwrite internal structures such as linked list pointers the canonical heap overflow technique overwrites dynamic memory allocation linkage such as malloc meta data and uses the resulting pointer exchange to overwrite a program function pointer microsofts gdi vulnerability in handling jpegs is an example of the danger a heap overflow can present barriers to exploitation manipulation of the buffer which occurs before it is read or executed may lead to the failure of an exploitation attempt these manipulations can mitigate the threat of exploitation but may not make it impossible manipulations could include conversion to upper or lower case removal of metacharacters and filtering out of nonalphanumeric strings however techniques exist to bypass these filters and manipulations alphanumeric code polymorphic code selfmodifying code and returntolibc attacks the same methods can be used to avoid detection by intrusion detection systems in some cases including where code is converted into unicode the threat of the vulnerability has been misrepresented by the disclosers as only denial of service when in fact the remote execution of arbitrary code is possible practicalities of exploitation in realworld exploits there are a variety of challenges which need to be overcome for exploits to operate reliably these factors include null bytes in addresses variability in the location of shellcode differences between environments and various countermeasures in operation nop sled technique nop slide illustration of a nopsled payload on the stack a nopsled is the oldest and most widely known technique for successfully exploiting a stack buffer overflow because of the popularity of this technique many vendors of intrusion prevention systems will search for this pattern of noop machine instructions in an attempt to detect shellcode in use it is important to note that a nopsled does not necessarily contain only traditional noop machine instructions any instruction that does not corrupt the machine state to a point where the shellcode will not run can be used in place of the hardware assisted noop as a result it has become common practice for exploit writers to compose the noop sled with randomly chosen instructions which will have no real effect on the shellcode execution while this method greatly improves the chances that an attack will be successful it is not without problems exploits using this technique still must rely on some amount of luck that they will guess offsets on the stack that are within the nopsled region an incorrect guess will usually result in the target program crashing and could alert the system administrator to the attackers activities another problem is that the nopsled requires a much larger amount of memory in which to hold a nopsled large enough to be of any use this can be a problem when the allocated size of the affected buffer is too small and the current depth of the stack is shallow ie there is not much space from the end of the current stack frame to the start of the stack despite its problems the nopsled is often the only method that will work for a given platform environment or situation and as such it is still an important technique the jump to address stored in a register technique the jump to register technique allows for reliable exploitation of stack buffer overflows without the need for extra room for a nopsled and without having to guess stack offsets the strategy is to overwrite the return pointer with something that will cause the program to jump to a known pointer stored within a register which points to the controlled buffer and thus the shellcode for example if register a contains a pointer to the start of a buffer then any jump or call taking that register as an operand can be used to gain control of the flow of execution an instruction from ntdlldll to call the dbgprint routine contains the i386 machine opcode for jmp esp in practice a program may not intentionally contain instructions to jump to a particular register the traditional solution is to find an unintentional instance of a suitable opcode at a fixed location somewhere within the program memory in figure e on the left you can see an example of such an unintentional instance of the i386 jmp esp instruction the opcode for this instruction is ff e4 when this technique is possible the severity of the vulnerability increases considerably this is because exploitation will work reliably enough to automate an attack with a virtual guarantee of success when it is run for this reason this is the technique most commonly used in internet worms that exploit stack buffer overflow vulnerabilities this method also allows shellcode to be placed after the overwritten return address on the windows platform since executables are mostly based at address 0x00400000 and x86 is a little endian architecture the last byte of the return address must be a null which terminates the buffer copy and nothing is written beyond that this limits the size of the shellcode to the size of the buffer which may be overly restrictive dlls are located in high memory above 0x01000000 and so have addresses containing no null bytes so this method can remove null bytes or other disallowed characters from the overwritten return address used in this way the method is often referred to as dll trampolining protective countermeasures various techniques have been used to detect or prevent buffer overflows with various tradeoffs the most reliable way to avoid or prevent buffer overflows is to use automatic protection at the language level this sort of protection however cannot be applied to legacy code and often technical business or cultural constraints call for a vulnerable language the following sections describe the choices and implementations available choice of programming language assembly and cc are popular programming languages that are vulnerable to buffer overflow in part because they allow direct access to memory and are not strongly typed however c behaves just like c if the bounds check is not explicitly called techniques to avoid buffer overflows also exist for c languages that are strongly typed and dont allow direct memory access such as cobol java python and others prevent buffer overflow from occurring in most cases many programming languages other than cc provide runtime checking and in some cases even compiletime checking which might send a warning or raise an exception when c or c would overwrite data and continue to execute further instructions until erroneous results are obtained which might or might not cause the program to crash examples of such languages include ada eiffel lisp modula2 smalltalk ocaml and such cderivatives as cyclone rust and d the java and net framework bytecode environments also require bounds checking on all arrays nearly every interpreted language will protect against buffer overflows signaling a welldefined error condition often where a language provides enough type information to do bounds checking an option is provided to enable or disable it static code analysis can remove many dynamic bound and type checks but poor implementations and awkward cases can significantly decrease performance software engineers must carefully consider the tradeoffs of safety versus performance costs when deciding which language and compiler setting to use use of safe libraries the problem of buffer overflows is common in the c and c languages because they expose low level representational details of buffers as containers for data types buffer overflows must thus be avoided by maintaining a high degree of correctness in code which performs buffer management it has also long been recommended to avoid standard library functions which are not bounds checked such as gets scanf and strcpy the morris worm exploited a gets call in fingerd wellwritten and tested abstract data type libraries which centralize and automatically perform buffer management including bounds checking can reduce the occurrence and impact of buffer overflows the two main buildingblock data types in these languages in which buffer overflows commonly occur are strings and arrays thus libraries preventing buffer overflows in these data types can provide the vast majority of the necessary coverage still failure to use these safe libraries correctly can result in buffer overflows and other vulnerabilities and naturally any bug in the library itself is a potential vulnerability safe library implementations include the better string library the openbsd operating systems c library provides the strlcpy and strlcat functions but these are more limited than full safe library implementations in september 2007 technical report 24731 prepared by the c standards committee was published buffer overflow protection buffer overflow protection buffer overflow protection is used to detect the most common buffer overflows by checking that the stack has not been altered when a function returns if it has been altered the program exits with a segmentation fault three such systems are libsafe gcc patches microsofts implementation of data execution prevention dep mode explicitly protects the pointer to the structured exception handler seh from being overwritten stronger stack protection is possible by splitting the stack in two one for data and one for function returns this split is present in the forth language though it was not a securitybased design decision regardless this is not a complete solution to buffer overflows as sensitive data other than the return address may still be overwritten pointer protection buffer overflows work by manipulating pointers including stored addresses pointguard was proposed as a compilerextension to prevent attackers from being able to reliably manipulate pointers and addresses rather than implement pointer protection as an automatic feature microsoft added an api routine that can be called at the discretion of the programmer this allows for better performance because it is not used all of the time but places the burden on the programmer to know when it is necessary because xor is linear an attacker may be able to manipulate an encoded pointer by overwriting only the lower bytes of an address this can allow an attack to succeed if the attacker is able to attempt the exploit multiple times or is able to complete an attack by causing a pointer to point to one of several locations such as any location within a nop sled executable space protection executable space protection executable space protection is an approach to buffer overflow protection which prevents execution of code on the stack or the heap an attacker may use buffer overflows to insert arbitrary code into the memory of a program but with executable space protection any attempt to execute that code will cause an exception some cpus support a feature called nx no execute or xd execute disabled bit which in conjunction with software can be used to mark pages of data such as those containing the stack and the heap as readable and writable but not executable some unix operating systems eg openbsd macos ship with executable space protection eg wx some optional packages include pax exec shield openwall newer variants of microsoft windows also support executable space protection called data execution prevention proprietary addons include buffershield stackdefender executable space protection does not generally protect against returntolibc attacks or any other attack which does not rely on the execution of the attackers code however on 64bit systems using aslr as described below executable space protection makes it far more difficult to execute such attacks address space layout randomization address space layout randomization address space layout randomization aslr is a computer security feature which involves arranging the positions of key data areas usually including the base of the executable and position of libraries heap and stack randomly in a process address space randomization of the virtual memory addresses at which functions and variables can be found can make exploitation of a buffer overflow more difficult but not impossible it also forces the attacker to tailor the exploitation attempt to the individual system which foils the attempts of internet worms a similar but less effective method is to rebase processes and libraries in the virtual address space deep packet inspection deep packet inspection the use of deep packet inspection dpi can detect at the network perimeter very basic remote attempts to exploit buffer overflows by use of attack signatures and heuristics these are able to block packets which have the signature of a known attack or if a long series of nooperation instructions known as a nopsled is detected these were once used when the location of the exploits payload is slightly variable packet scanning is not an effective method since it can only prevent known attacks and there are many ways that a nopsled can be encoded shellcode used by attackers can be made alphanumeric metamorphic or selfmodifying to evade detection by heuristic packet scanners and intrusion detection systems testing checking for buffer overflows and patching the bugs that cause them naturally helps prevent buffer overflows one common automated technique for discovering them is fuzzing once a potential buffer overflow is detected it must be patched this makes the testing approach useful for software that is in development but less useful for legacy software that is no longer maintained or supported history buffer overflows were understood and partially publicly documented as early as 1972 when the computer security technology planning study laid out the technique the code performing this function does not check the source and destination addresses properly permitting portions of the monitor to be overlaid by the user this can be used to inject code into the monitor that will permit the user to seize control of the machine page 61 today the monitor would be referred to as the kernel the earliest documented hostile exploitation of a buffer overflow was in 1988 it was one of several exploits used by the morris worm to propagate itself over the internet the program exploited was a service on unix called finger a stepbystep introduction to exploiting stackbased buffer overflow vulnerabilities since then at least two major internet worms have exploited buffer overflows to compromise a large number of systems in 2001 the code red worm exploited a buffer overflow in microsofts internet information services iis 50 in 2003 buffer overflows present in licensed xbox games have been exploited to allow unlicensed software including homebrew games to run on the console without the need for hardware modifications known as modchips the ps2 independence exploit also used a buffer overflow to achieve the same for the playstation 2 the twilight hack accomplished the same with the wii using a buffer overflow in the legend of zelda twilight princess software testing portal computer science portal billion laughs buffer overread computer security endoffile heap overflow ping of death port scanner returntolibc attack securityfocused operating system selfmodifying code shellcode stack buffer overflow uncontrolled format string discovering and exploiting a remote buffer overflow vulnerability in an ftp server by raykoid666 smashing the stack for fun and profit by aleph one an overview and example of the bufferoverflow exploit pps 1621 cert secure coding standards cert secure coding initiative secure coding in c and c sans inside the buffer overflow attack advances in adjacent memory overflows by nomenumbra a comparison of buffer overflow prevention implementations and weaknesses more security whitepapers about buffer overflows chapter 12 writing exploits iii from sockets shellcode porting coding reverse engineering exploits and tool coding for security professionals by james c foster isbn1597490059 detailed explanation of how to use metasploit to develop a buffer overflow exploit from scratch computer security technology planning study james p anderson esdtr7351 esdafsc hanscom afb bedford ma 01731 october 1972 buffer overflows anatomy of an exploit by nevermore secure programming with gcc and glibc 2008 by marcel holtmann vtememory management memory management as a function of an operating system manual memory management static memory allocation c dynamic memory allocation new and delete c virtual memory demand paging page table paging virtual memory compression hardware memory management unit translation lookaside buffer garbage collection boehm garbage collector concurrent mark sweep collector finalizer garbage garbagefirst collector markcompact algorithm reference counting tracing garbage collection strong reference weak reference memory segmentation protected mode real mode virtual 8086 mode x86 memory segmentation memory safety buffer overflow buffer overread dangling pointer stack overflow issues fragmentation memory leak unreachable memory other automatic variable international symposium on memory management regionbased memory management authority control gnd 47524509 