If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Introduction To Buffer Overflows

***___ Intro To Buffer Overflows: My knowledge and research ___***

Hello, and welcome to my newest tutorial that is a relatively short one that I will use to briefly describe in simple (n00bish) terms for those starting out and learning about Buffer Overflows.. Let's jump into action!

What Is A Buffer Overflow?

My goal while explaining this to you is to make this as simple to understand as possible. So, here goes.. A Buffer Overflow can easily be defined as a problem where a specific active process tries to hold more data in a single buffer than the memory inside it will hold, thus causing an overflow. It is generally an attack on the data integrity of a system. However, what is a buffer, you may be asking? A buffer can simply be defined as a temporary data storage area. Simply put, no? Anyways, what ends up happening as a result, is the extra data will end up causing problems and/or corrupting data stored in additional/extra memory locations. Buffer Overflows have been known to and are used to sometimes crash a specific process, usually one vital to a system. Because this is a problem that damages the memory locations in a system that hold data, this has proven to be the "backbone" to many other exploits.. ones that are typically far more advanced (obviously).

Spyder's Fast Fact: Buffer Overflows are typically coded in C/C++ (AFAIK, they are the only ones.. but I'm not 100% on that). To fully grasp the attack however, one should have a good understanding of those two languages AND any advanced programming language for that matter.

Here's a small example of a code snippet that would work:

Code:

int main () {
int buffer[40];
buffer[120] = 40;
}

As you can see, the allocated memory unit for this buffer is 40. This program (when compiled, obviously) would attempt to write past that allocated amount, thus causing some unexpected problems. Not good... Another example:

The problem in this would be obvious -- a string of 89 bytes has been transfered into a buffer with a memory allocation of 32 bytes.. thus, once again.. causing the buffer to overflow with data (ahh, we're getting the meaning behind "Buffer Overflow" now, aren't we? ). Which in turn, corrupts the data, files could be lost, and all hell breaks loose.

Conclusion

Despite it's smooth sounding name and rather lack of public hearsay, the Buffer Overflow attack isn't as complicated as many would have it out to be. Now, understanding Stack Regions and the problems associated with it while corrupting the process stack is a tad complicated.. something I'm still getting down myself and it's something that I'll possibly make a tutorial out of somewhere down the line. But there you have it -- a very simple, begginers explanation of a buffer overflow.

Anyways, hope you enjoyed the little tutorial.. my goal was meant to merely educate those new to the subject, not go in-depth about it. For those who want a more in-depth explanation or for further re-iteration, PM me or post here that you'd like to see this be made into a series.

I don't know. I hate saying this to a supermod... I feel like this is not (yet) qualified as a security tutorial. I mean, if I were the one who posted the same text above, bad things may happen.

Anyway, understanding of Assembly language and how machine code works will definitely help us understand the nature of buffer overflow. And the most important thing after knowing that buffer overflow may "corrupts the data, files could be lost, and all hell breaks loose", is how to spot and prevent them. For example, using strncpy(). Other relevant facts may also be added such as how buffer overflows can be exploited, and the concepts of shellcode.

Peace always,&lt;jdenny&gt;

Always listen to experts. They\'ll tell you what can\'t be done and why. Then go and do it. -- Robert HeinleinI\'m basically a very lazy person who likes to get credit for things other people actually do. -- Linus Torvalds

jdenny: You are partially correct.. it isn't so much a tutorial as it is what the title says, an Introduction into Buffer Overflows. My goal/object wasn't to go into the cemantics of a buffer overflow, but to merely explain what it is and whatnot. You're right, not exactly a security tutorial and more of an explanation, but yeah.. it's an introduction into the subject. I'm further studying the topic and will probably eventually make this into a long series.. not sure yet though.

As far as my knowledge on this topic goes, you can have buffer overflows in most languages - but you will get compilation errors/exceptions during the runtime checking and therefore the faults will be stopped from getting into the final application, especially in the higher level languages (could this be overridden?). However, C, C++ and Assembly are the ones most commonly used to perform buffer overflows, as they do not 'complain' so to speak, and allow more precise manipulation of memory.

You can read quite a lot on buffer overflows on Wikipedia. I think you should make this into a series, as the introduction was good and easy to understand. But, you should stress the ways to prevent them as well - even if it's just a paragraph that says "To prevent buffer overflows, you should always check any data input to make sure it fits within the buffer and is what it is meant to be. That is, if variable X is meant to be an integer, check to make sure it really is one, and check that it is not too large for the buffer. Also make sure you inspect user input thoroughly, as they are the ones who cause the problems if you have a vulnerable application." Or something like that

There where some good points that where made in the posts you deleted spyder - can you delete posts at your pleasure if they are not complementry to your tutorial/intorduction?

Agreed they may not have been worded in the nicest possible way but (and please dont take this personally) if a newbie had wrote a tutorial like you have and posted it in the security tutorials section - he would have got ripped apart.

Dont get me wrong mate, I'm not saying its a bad tutorial/introduction but it does need a bit more added to it to make it useful, IMHO.