Buffer Overflow Attacks And Types Computer Science Essay
Abstract – Buffer Overflows are one of the main reasons for problems in a computer system. Statistics in this report have shown that the number of attacks in the past 20 years is increasing drastically and it is buffer overflow which is also rated the most occurring attack. This paper basically provides the various prevention techniques for Buffer Overflow attacks, like Canaries, DEP and ASLR, and more which have been deployed and are working well to a certain extent.
Introduction
It is the job of the compiler to check for errors or vulnerabilities in the code. In C, the compiler is not so very efficient to detect these logical errors. The simplest form of a buffer overflow attack would be as follows:-
char buf1[5];
char buf2[10]=”A1B2C3D4E5″;
strcpy(buf1,buf2);
The above 3 lines of code are compiled without any error by the C compiler as there are no syntactical errors. But logically we are copying a string of 10 chars into a buffer which can hold only 5 chars. This might be a small typing error on the programmer’s side, but results in an attack which can overwrite the data which might have been stored in the memory location next to the space allocated for buf1. This is Buffer Overflow. Its types are explained in the section below.
Buffer Overflow Attacks & types.
Buffer Overflow Attack as defined by Kramer (2000) occurs when a program or a process tries to force more data into a buffer than it is actually intended to hold. The simplest examples to explain this is the program above, but in layman’s terms, let us assume 2 jugs, one with a capacity of 2 litres and another of 1 litre. If you try to empty the 2litres of water into the jug which can hold only 1 litre, you spill 1 litre of water. This attack can have many consequences on a system like incorrect results, security breach or even a system crash.
Posey (2005) explains the different types of Buffer Overflow attacks. There are basically two kinds of buffer overflow attacks:
1. Heap-based attacks and
2. Stack-based attacks.
In Heap-based attack the attacker floods the memory space which is actually reserved for the program. This attacks is not exactly easy as it feels, hence the number of attacks with respect to the heap are very rare.
In Stack-based attack, the attacker takes advantage of the stack, a part of the memory reserved for the program to store data or addresses. The attacker then partially crashes the stack and forces the program execution to start from a return address of a malicious program address which is actually written by the attacker.
Statistics
Fig 1. Buffer Overflow Statistics
Statistics from the National Vulnerability Database(2011) show the occurrence of Buffer overflow attacks. It ranges from 1989 to 2011. The graph is declining in the last 3-4 years, but experts say that there is a possibility that it may rise again.
Prevention Techniques
Some host based mechanisms to prevent Buffer Overflow Attacks are mentioned below:
Detection & Elimination: Kuperman(2005) says detection and elimination of the vulnerable code is necessary before someone takes advantage of that code. In this technique there are ways in which software searches for some specific type of code. This is known as Source Code Auditing. Vernon (2003) in his WhitePaper has mentioned techniques and ways how it is done. Kuperman has also mentioned about a group, OpenBSD Group, a group which audits the source code free of cost for a BSD based Operating System. The time taken for analysis is large and the expertise of the volunteers determine their efficiency.
Complier Modifications: A technique to avoid buffer overflow attack is to modify the way the data is stored in the memory. StackGuard is a type of a complier which can be used to add gaps in the memory in between, these gaps are known as Canaries. It works in the following way: whenever a function gets a return call, it reads the canary on the stack and check for any modification. If it finds the canary is modified it understands it is under attack. (Kuperman, 2005). Another Complier, ProPolice uses pointers to address memory locations. ProPolice is also an enhancement concept of StackGuard. Frantzen & Shuey (2001) in their article have mentioned about StackGhost. StackGhost is a unique technique which was developed by Sun Microsystems. It detects the change in return pointers without actually affecting the program. It effect on the throughput is also negligible. This made attackers much more difficult to do a buffer overflow.
Array Bounds Checking: Cowan et al(2000) have explained each time an operation needs to be performed on an array, we can do the boundary checking. If boundary is reached it won’t allow writing into the array, thus avoiding the buffer overflow. Similarly we can write a code to check the size of each buffer when writing. If the destination buffer is bigger than the other which is to be copied, then its ok or don’t allow it. This technique although might work, but is very costly to implement as it will delay the actual process.
Non-Executable Stack: Fritsch (2009) explains marking of the stack as Non-Executable can help stopping Buffer Overflow. But this in turn also stops genuine programs from executing directly from the stack. Sanders (2009) had also mentioned the same technique. The article mentioned that Microsoft had included a security feature in its new service pack for Windows XP (it was Win XP SP2). This was known as DEP (Data Execution Prevention). DEP is of 2 types: Hardware and Software. In Hardware DEP some parts of the memory were marked as Non-Executable by the processor. But again this was a bit tricky as not all processors supported Hardware DEP. Software DEP on the other hand watches the exception thrown by program and checks whether they actually belong to the program.
Address Space Layout Randomization: Wagle (2003) has mentioned that earlier the attacker used to insert a large number of nop instructions, to work around the memory location. ASLR randomly allocates memory locations to the code and data, thus making it difficult for the attacker to find the instructions.
Proof Carrying Code (PCC): Necula (1997) says PCC is a technique which checks the properties of the program, and the code and also checks its security policy and determines whether it should allow it to execute it or not.
SmashGuard: Kuperman(2005) has explained this technique uses a modification of the normal call & ret instructions. Whenever a call instruction is encountered along with the actual entry of the return address on the stack another entry on the data stack within the processor. Then when it encounters the ret instruction it matches both the return addresses. If it matches it goes ahead with the execution else if a match is not found then it terminates the program. Also no changes are made to the data. This is a technique which works well with Brute Force Attack.
Split Stack: Kuperman (2005) has explained that Split Stack or Secure Address Return Stack (SAS) is a proposed technique to prevent buffer overflow attack. In this technique two software stacks are used, one for control information and another for data information. Hence even if an attacker gains access to the data stack, he cannot affect the control stack. Although it might need to read and write from 2 stacks it is worth the time.
Write Correct Code: Cowan et al (2000) writes, the best way to avoid any kind of attack if to write good and correct code. It is a human’s tendency to write and forget the code, but that same code can be checked by someone else as well.
The above mentioned prevention techniques are only few of them which are available; there are many techniques available for prevention against Buffer Overflow Attacks and various other attacks.
Risks
Fritsch (2009) in another article has explained the way to bypass ASLR protection. He explains there exists a flaw in the random number generation for ASLR. He explains it is not so very difficult to predict the randomization address. Writing a program which will try and brute force the memory location till it finds the correct one breaks the ASLR protection. Symantec Architect Mr. Whitehouse (2007) had mentioned the problem of ASLR in Windows Vista.
Research by Mr. Bojinov (2011) shows pre-linking can help in implementing ASLR on Android phones. He has introduced “retouching” which is similar in design to prelinking. Also crash stack analysis is introduced which uses crash reports on the local device to prevent brute-force attacks.