Introduction: Buffer Overflow Vulnerabilities
By: Erica R. Thomas

In exploiting the buffer overflow vulnerability, the main objective is to overwrite some control information in order to change the flow of control in the program. The usual way of taking advantage of this is to modify the control information to give authority to code provided by the attacker to take control. According to Shaneck, "The most widespread type of exploit is called 'Smashing the Stack' and involves overwriting the return address stored on the stack to transfer control to code placed either in the buffer, or past the end of the buffer." (Shaneck, 2003) The stack is a section of memory used for temporary storage of information. In a stack-based buffer overflow attack, the attacker adds more data than expected to the stack, overwriting data. Farrow explains this in an example, "Let's say that a program is executing and reaches the stage where it expects to use a postal code or zip code, which it gets from a Web-based form that customers filled out." (Farrow, 2002) The longest postal code is fewer than twelve characters, but on the web form, the attacker typed in the letter "A" 256 times, followed by some other commands. The data overflows the buffer allotted for the zip code and the attacker's commands fall into the stack. After a function is called, the address of the instruction following the function call is pushed onto the stack to be saved so that the function knows where to return control when it is finished. A buffer overflow allows the attacker to change the return address of a function to a point in memory where they have already inserted executable code. Then control can be transferred to the malicious attack code contained with the buffer, called the payload (Peikari and Chuvakin, 2004). The payload is normally a command to allow remote access or some other command that would get the attacker closer to having control of the system. As Holden explains, "a computer is flooded with more information than it can handle, and some of it may contain instructions that could damage files on the computer or disclose information that is normally protected- or give the hacker root access to the system." (Holden, 2004)

The best defense against any of these attacks is to have perfect programs. In ideal circumstances, every input in every program would do bounds checks to allow only a given number of characters. Therefore, the best way to deal with buffer overflow problems is to not allow them to occur in the first place. Unfortunately, not all programs are perfect and some have bugs that permit the attacks discussed in this paper. As described by Farrow, "because programs are not perfect, programmers have come up with schemes to defend against buffer overflow attacks." (Farrow, 2002) One technique entails enforcing the computer to use the stack and the heap for data only and to never to execute any instructions found there. This approach can work for UNIX systems, but it can't be used on Windows systems. Farrow describes another scheme using a canary to protect against buffer overflows, but only the kind that overwrite the stack. (Farrow, 2002) The stack canary protects the stack by being put in sensitive locations in memory like the return address (that tells the computer where to find the next commands to execute after it completes its current function). As described by Farrow, "before return addresses get used, the program checks to see if the canary is okay." (Farrow, 2002) If the canary has been hit, the program then quits because it knows that something has gone wrong. As a user of the programs, the best countermeasure is to make sure your systems are fully patched in order to protect yourself from exploits targeting vulnerabilities.

Read Full Article:
http://www.linuxsecurity.com/content/view/118881/49/

LinuxSecurity.com Feature Extras:

Getting to Know Linux Security: File Permissions - Welcome to the first tutorial in the 'Getting to Know Linux Security' series. The topic explored is Linux file permissions. It offers an easy to follow explanation of how to read permissions, and how to set them using chmod. This guide is intended for users new to Linux security, therefore very simple. If the feedback is good, I'll consider creating more complex guides for advanced users. Please let us know what you think and how these can be improved.

The Tao of Network Security Monitoring: Beyond Intrusion Detection - To be honest, this was one of the best books that I've read on network security. Others books often dive so deeply into technical discussions, they fail to provide any relevance to network engineers/administrators working in a corporate environment. Budgets, deadlines, and flexibility are issues that we must all address. The Tao of Network Security Monitoring is presented in such a way that all of these are still relevant.

Encrypting Shell Scripts - Do you have scripts that contain sensitive information like passwords and you pretty much depend on file permissions to keep it secure? If so, then that type of security is good provided you keep your system secure and some user doesn't have a "ps -ef" loop running in an attempt to capture that sensitive info (though some applications mask passwords in "ps" output).

 

Take advantage of our Linux Security discussion list! This mailing list is for general security-related questions and comments. To subscribe send an e-mail to security-discuss-request@linuxsecurity.com with "subscribe" as the subject.

Thank you for reading the LinuxSecurity.com weekly security newsletter. The purpose of this document is to provide our readers with a quick summary of each week's most relevant Linux security headline.

Only registered users can write comments.
Please login or register.

Powered by AkoComment!