Web Links Related to Buffer Overflow and Stack Smashing
Web Links Related to Buffer Overflow and Stack Smashing
One of the assignments for CPSC 6126 (Information Assurance) for the Fall 2003 semester was to submit annotated links on buffer overflow and stack smashing. Here is a collection of what the students submitted. The only editing done by the instructor was to place all comments on the link after the link and to fix up a few spelling errors. The rest of the work was done by the students.
There are two sets of links, one for buffer overflow and another for stack smashing – a special case of buffer overflow.
We begin with a definition of buffer overflow, posted by one of the students.
A buffer is a space in memory in which to hold data. The buffer itself is not important to the attacker. Rather, it is the space around the buffer. In many programs, the programmers have defined the amount if memory to be reserved for holding certain types of data. In other words, buffer sizes are often predefined by programmers. The reason to predefine buffer sizes is simple: there are many variables or arrays that have fixed lengths, and because they do, programmers can write more efficient code by limited the amount of memory set aside for those variables or arrays. For example, everyone's birthday can have at most 8 digits if represented in the MM-DD-YYYY format. So, why not limit the amount of space in memory since you know how big the variable will be? Maybe I didn't bother to test my program before distributing it and I never thought someone would try and enter a birthday that had 1000 digits! The buffer set aside to hold those 8 digits becomes full and then the remaining digits begin to overflow and perhaps the program crashes or freezes. Depending on where the computer tries to write that extra data will determine a great deal about what happens. What if instead of benign extra digits, a mischievous person inserted lines of code that could be executed by the CPU? These lines spill over into other areas of memory, and perhaps they spill over into a space of memory dedicated to the system. Now, the attacker has gained access into the space of memory owned by the system. Maybe the attacker tries to hijack the system or gain higher privileges. Perhaps the overflow occurs into the stack and the attacker redirects the pointer to code that he wants executed. Either way, in the age of the Internet, diligence must be taken to insure against buffer overflow attacks
Buffers are limited in the amount of data they can hold. When you fill a buffer with data that exceeds its storage capacity the extra data will flow somewhere else which is usually into another buffer and generally corrupts the data that exist in this buffer. By transferring data that exceeds the capacity of the buffer we force the data to “overflow” into another buffer thus causing “buffer overflow”. Hackers exploit this by intentionally beginning buffer overflow attacks which when overflow occurs the malicious instructions are released into the computer's instructions. The above article thoroughly explains this concept and discusses methods to exploit this bug. They have included “C” code to provide an example of this hack. They not that in theory this is an easy hack but in reality it can be very challenging. I hope you enjoy this article and find it as interesting as I have.
The article I found on Buffer Overflow is entitled, "The Rookery: Buffer Overflow Attacks and Their Countermeasures." Buffer overflow problems are typically associated with security vulnerabilities.
A little research will confirm many security breaches have occurred due to buffer overflows. This article addresses what a buffer overflow is, why is it dangerous, and how is it preventable.
A buffer is contiguous allocated memory with no automatic bounds. Hence, the problem. Someone, wanting too, can load memory past the allocated amount, thus causing a buffer overflow. A program will create many small memory buffers to handle the processes and functions it performs. The last memory address in every buffer should contain the return address. This address will redirect the computer back to the proper place in the program. In the case of a buffer overflow, the return address can be corrupted(not valid) or actually redirect the computer to some destructive/foreign code that has been placed in another memory location.
The article also discusses several ways in preventing buffer overflow problems. It mentions coding and other tools that can be used to prevent or find problem areas in coding. But, basically the program code needs to be written in a way to prevent overflows from occurring.
This link will send you to a description of buffer overflow. As stated in the reference, this is one of the most common attacks on the internet and it does not surprise me that the problem is mostly caused by not properly checking code. At the site you will also find additional links to include exploits and further examples of buffer overflow.
The following link regarding Stack Smashing is to CORE Security Technologies. This link provides information regarding vulnerabilities in some of the technologies used to prevent stack smashing, it also has links to numerous resources including sample code of these vulnerabilities.
Buffers are created to hold a certain amount of data just like a bucket is built to only hold a certain amount of water. Dumping to much data into a predefined area of computer memory is like pouring to much water into a bucket - the result is an overflow. The results are very messy!! When buffer overflow occurs, the data has to go somewhere - just like the water in the bucket ending up on the ground (or carpet!). The data overflows into adjacent buffers which can corrupt or overwrite the existing data. This opens the door for attack. The overflow can allow someone to send extra data that may contain code designed to conduct or trigger certain actions - new instructions that could damage files, change data or worse.
In Jul 2000, a buffer overflow vulnerability was found in Outlook. The attacker could simply send an email message that contained extraneous data in the message header. This caused a buffer overflow and the attacker had the ability to execute any code they wanted on the recipient's workstation.
The above site gives you several explanations of buffer overflows. The article starts off by using a conversation between two employees to give a non-technical explanation of buffer overflows. The explanations continue with each getting more technical until you reach the last explanation which is completely technical and provides a thorough understanding of buffer overflows and how they can be exploited.
This link identifies a buffer overflow problem with one of the most widely used operating system across the world - windows. Specifically the windows remote procedure call. During remote procedure calls, network protocols are used to provide inter-process communications between the two computers attempting to establish a dialog. The buffer overflow is located in the distributed component object model interface handling. The interface handling does not perform a length check while checking a filename parameter. If a huge filename is passed as a parameter, a buffer overflow may occur. After the buffer over flow occurs, the attacker may run arbitrary code and gain system privileges. Privileges ranges from installing application programs to creating new user accounts with full privileges.
http://www.cultdeadcow.com/cDc_files/cDc-351/index.html Now this is scary. Not only because it's like telling us how to create and distribute an overflow buffer exploitation, but also the last page contains a link to the actual exploit.
Whatever you do, DON'T PRESS THE BUTTON at the end of the article. I don't know what it will do, but I am sure the author is just looking for an idiot.
This article is a frank and wonderful explanation of how they do it. It lays an egg by using the buffer overflow technique. It has some, shall we say, colorful metaphors sprinkled throughout the text. It assumes a high level of programming skills and knowledge of the Windows operating system. It makes one think about all the places in any OS where this type of attack can be exploited. In particular it tells how to use the Windows program NetMeeting to launch your attack.
“…we'll make our little egg code download another program off of the internet, a larger, well constructed executable, and execute it. This will enable us to write this little tedious chunk once, and have it execute a piece of higher level code.”
I have chosen a link that deals Linux and buffer overflow hacking techniques because Linux is often cited as being much more secure than Microsoft products. The article is written by a programmer that produced software used by a hacker to get into a system. He gives several examples of techniques used by hackers to take advantage of buffer overflow. He additionally attributes buffer overflow vulnerability to “lazy programmers” (including himself I guess) that do not protect against strings being assigned to string variables that exceed allocated space. These programmers think that a “segmentation fault” is protection enough. It isn't. The author offers ideas on building buffer overflow protection into your software. For those familiar with the C language, he advises using strncpy() instead of strcpy(). Strncpy() allows the programmer to limit the length of the string being copied.
Very informative website that I think has something for everyone interested in this topic.
http://project.honeynet.org/scans/scan25/sol/NCSU/exploit-diagram.htm Most overflow problems area generated by corrupting the program stack. The heap can also be attacked in the same way, although the attack is more difficult.
This is an article on heap-based buffer overflow.
Buffer overflow exploits constitute perhaps the most common form of computer security attack. Such exploits take advantage of programming errors to overflow buffers, thus writing unintended data to the part of memory that immediately follows the targeted buffers.
If the targeted buffer exists on the process stack, then the exploit often attempts to overwrite a return address on the stack, which often results in obtaining root access to that machine. It is called “stack smashing attack”.
The above discusses the definition quite well.
In the book, on the subject of buffer overflows it mentions a well-known security group known as L0pht and an article written by MUDGE discussing buffer overflow exploits and stack smashing.
This site gave a pretty simple definition of Buffer Overflow using every day workplace –like conversation. Even a person that has never programmed before would understand buffer overflow from this article. For starters, it likened Buffer Overflow to that nice worker that has gone to make a conversation (point) to a co-worker. Just after the initial hellos, the co-worker hijacks the conversation and by the time he's finished, not only did the poor guy not make his conversation (point), he now has an unsolicited, and for all intents and purposes, unwanted task to do for the co-worker. His Buffer has just overflowed. It then went in to a more technical detail of how Buffer Overflow works- how the stack can be overwritten so the malicious code will be executed rather than the code that normally would have executed. It also offered suggestions on how to make Buffer Overflow harder to exploit.
A buffer overflow is when you try to stuff to much data into to small a memory space and it overflows into the adjacent memory space.
This article shows how a skilled hacker uses a buffet overflow to change a return pointer to point to his code. “literally hijack the processor's execution path” as described by the author.
Its really amazing to me that someone could figure this sort of thing out. I have always tried to strongly type because it just makes for better code, but I had not idea that MY code could be hacked. I thought it was just a Microsoft problem.
No description of this link as yet.
The article at the link above is about buffer overflows. The article states that in a buffer overflow, the attacker floods a field, typically an address bar, with more characters than it can accommodate. The excess characters in some cases can be run as "executable" code, effectively giving the attacker control of the computer without being constrained by security measures. This article is dated November 23, 1999 which shows that buffer overflows are not a new problem. "Buffer overflows have been the most common form of security vulnerability for the past 10 years," according to a new paper published by the Oregon Graduate Institute of Science & Technology (OGI) and funded in part by the Defense Advanced Research Projects Agency (DARPA). Security analysts agree that the first step in cutting down on buffer overflow bugs is for people to engage in more careful computer programming. The article explains to combat careless coding, programmers have developed debugging tools that search out buffer overflow vulnerabilities.
Stack Smashing is a term that describes what happens when the execution stack is corrupted by writing past an array on purpose. A user can take advantage of a buffer overflow to change the return value of a function which allows the user to change the flow of execution of a program. This is dangerous because a user can put instructions in the buffer that could spawn a shell, which could in turn do just about anything. The only thing left to do is to overwrite the return address of the function so that it points back to the buffer.
Stack smashing is a buffer overflow type attack causes a stack in a computer application to overflow. When you do this you cause the program to become weakened. By understanding that the stack is a pushdown stack meaning the first item in is the last item out follows the form of a buffer which holds the last command or data. Just like buffer over flow we attempt to place more info in the stack than it can hold. This will result in loosing valid system information. Sometime this information is critical to the operation of the system and a hacker can corrupt or change this information by “smashing the stack”. The article I have provided provides a brief description of this concept with links to more detailed information. I found that it explained the strategy well and I followed it easily. I hope you find it as useful as I have.
Here's a link that gives the definition of Stack Smashing.
Another link on stack smashing.
Basically Stack Smashing is another name for overrunning a buffer to corrupt the execution stack by writing past the end of an array declared auto in a routine. This over rights the stack and changes the address where the subroutine returns. One can make it return to any place one likes. Linux is just as vulnerable as Windows. This article explains in moderate detail all about it.
Here is an article published today (9/17/03) that talks about using buffer overflows to exploit a security hole in DCOM.
This link regarding Stack Smashing is to CORE Security Technologies. This link provides information regarding vulnerabilities in some of the technologies used to prevent stack smashing, it also has links to numerous resources including sample code of these vulnerabilities.
For the definition of Stack Smashing I found another site that provide an even easier understanding of Stack Smashing. According to the site, Stack Smashing is simply a popular form of buffer flow exploitation on the memory stack.
The above site gives you an explanation of stack smashing in C programming. The article explains what a stack is, why it is used. The article also includes a shellcode example and programs that exploit the shellcode using stack smashing.
On many C implementations it is possible to corrupt the execution stack by writing past the end of an array declared auto in a routine. Code that does this is said to smash the stack, and can cause return from the routine to jump to a random address.
Buffer overflow and stack smashing are very similar, as a matter of fact, most people use the terms interchangeably. However, buffer overflow is more generic and not necessarily attacking the stack. Stack smashing is a very specific exploit attacking the stack. As you will see below, there are a lot of similarities but also some significant differences. I have provided a link to a buffer overflow exploit that does NOT involve exploiting the stack, but is just as dangerous.
This link also covers Linux's vulnerability to this hacking technique. Stack smashing occurs when someone corrupts the execution stack by writing data past the end of the stack declared “auto” in a routine. For newcomers to C, declaring a variable “auto” in a routine means space for the variable will be allocated at run-time and stored in the run-time stack.
The article goes into a basic discussion of stacks, and how they are used in operating systems to dynamically allocate space. One example is quoted here:
“What we have done above is filled the array large_string with the address of buffer, which is where our code will be. Then we copy our shellcode into the beginning of the large_string string. strcpy() will then copy large_string onto buffer without doing any bounds checking, and will overflow the return address, overwriting it with the address where our code is now located. Once we reach the end of main and it tried to return it jumps to our code, and execs a shell.”
There seem to be many similarities between the buffer overflow and the stack smashing vulnerabilities. As can be seen in the quote cited above, programmer specification of maximum string lengths goes a long way in protecting software from being misused. I suspect that the use of strncpy() instead of strcpy() would solve many of the problems in the example provided.
Stack smashing is causing a stack in a computer application or operating system to overflow which makes it possible to subvert the program or system or cause it to crash.
Here is a link that contains more information regarding stack smashing.
From the title of this one, I doubt if it was written by an academic type.
Next a set of three links with one comment.
These links run are online demos. I found them very useful in achieving a better understanding of stacks and overflows.
The link talks about Stack Smashing as a security attack, and in fact, the most popular form of buffer overflow attack (Attacking buffers on stack). It lists two important goals that must be met before Stack Smashing attack can be successful. The first is that an attack code has to be injected in a running process, and the second is that the execution path of the process must be altered to execute the attack code. It states that the Stack is used for over flow exploits because it allows memory storage when there is not enough registers (Register holds the instruction that is currently being executed). It goes on to talk about how stacks are stacked and popped, and how they can be smashed with the return address and flow of execution modified so that a program that spawns a shell can be executed. Then from the shell, other commands can be issued. The paper also talked about why Stack Smashing still occurs, and how to prevent it. It was rather technical but, captured the essence of Stack Smashing.
Stack Smashing is another name for buffer overflow.
The following is a very nice explanation of how a very skilled hacker can get gain privileges that will allow him to steal your system.
No description yet on this link.
Stack Smashing is another form of buffer overflow. The
differences between the two are the buffer storage is exceeding by
a particular variable length or some define parameter length. In
stack smashing, the operating system's stack – memory
location to control the execution flow of a program or spawned
process is intentionally or unintentionally passed a false value to
gain access and privileges not granted to a user by the
administrator. The article provides a link to a stack smashing
vulnerability found in the SNMP – Simple
Network Mail Protocol.
This is a huge find from the since, most if not all mail systems utilize this protocol to communicate with other mail servers and networks.
The article at the link above is about Stack Smashing. Stack smashing is the process of corrupting the execution stack of a running program by overflowing a buffer inside the program. This usually occurs because the program did not check the length of the data that was read into the buffer. The article states that Stack smashing attacks have been one of the main attacks resulting from buffer overflow vulnerabilities in many programs because of the common ability of running arbitrary code in the stack. Stack smashing is difficult to prevent because of the fact that buffer overflow problems are very hard to find in a program. The article has some stack smashing code that is written in C. The article lists a few ways to prevent or reduce the risk of stack smashing for the Linux operating system: 1. A few libraries have been written that prevents buffer overflows by providing functions that work on arrays that either have bounds checking or have limits on the length of data placed into a buffer. 2. Patches to compilers that add code that detects buffer overflows and prevent them from happening have also been written. 3. The Linux operating system also has kernel patches that attempt to create a non-executable user stack area so that code cannot be executed within the stack. 4. Careful programming with lots of bug-checking can prevent buffer overflow problems within the program being developed.
The article also lists a link on how to write a program that will exploit a buffer overflow. There is a link for “Smashing The Stack For Fun And Profit” and also a link on how to avoid buffer overflows.