Buffer Overflow??

[xFiLeMaNx]

I've seen alot of this around in different articles and so forth, but I have no idea what it is or means. Could someone please explain buffer overflow to me.?

thanx

[er0k]

This is my understanding, although im probably wrong somewhere, i think i get the idea though: There are things and places on your system that have or are buffers. Now these buffers are there to store and collect data that you feed it. Give it too much data, it shutsdown, and may cause other things to "shut down or not work properly." That is what i think a buffer overflow is. Overflowing the buffer with too much data.

[Unleashed]

A buffer overflow occurs when a program or process tries to store more data in a buffer (temporary data storage area) than it was intended to hold. Since buffers are created to contain a finite amount of data, the extra information - which has to go somewhere - can overflow into adjacent buffers, corrupting or overwriting the valid data held in them. Although it may occur accidentally through programming error, buffer overflow is an increasingly common type of security attack on data integrity. In buffer overflow attacks, the extra data may contain codes designed to trigger specific actions, in effect sending new instructions to the attacked computer that could, for example, damage the user's files, change data, or disclose confidential information. Buffer overflow attacks are said to have arisen because the C programming language supplied the framework, and poor programming practices supplied the vulnerability.

BTW, you might want toknow what buffer is, or you might know but:

A buffer is a data area shared by hardware devices or program processes that operate at different speeds or with different sets of priorities. The buffer allows each device or process to operate without being held up by the other. In order for a buffer to be effective, the size of the buffer and the algorithms for moving data into and out of the buffer need to be considered by the buffer designer. Like a cache, a buffer is a "midpoint holding place" but exists not so much to accelerate the speed of an activity as to support the coordination of separate activities.

This term is used both in programming and in hardware. In programming, buffering sometimes implies the need to screen data from its final intended place so that it can be edited or otherwise processed before being moved to a regular file or database.

[ammo]

A buffer can be as simple as byte array in C (a string buffer)...

Ammo

[droby10]

with regard to buffer overflows you'll find a few different distinctions in the type of overflow. this is really a misconception because the overflow is the same process, it's the effect and locale of the overflow which yields the various overflow namespaces.

stack overflow - typically when more data is copied into a stack frame's allocation for a local frame variable. dangerous because it overwrites the frame pointer and possibly the return instruction pointer; this results in the execution return to an invalid address in memory, as represented by the overwritten return in the stack frame.

heap overflow - same process as above, but overflows dynamically allocated variables which basically results in the corruption of data that is used ie. a variable that holds a filename to a secure file could be changed to a less secure file and vice versa - the overwritting of function pointers which would have the same runtime effect as the stack overflow; a modification to the execution path.

i've linked to one of my older tutorials in the newbie tutorial's section. so far it has gotten pretty negative comments here, but suprisingly, has been widely accepted outside of antionline prior to my entry here - i don't blame them, it seems they're just really angry people for some reason.

anyway the tutorial has several illustrations that may or may not help your comprehension of buffer overflows. if it helps let me know, if not - feel free to chime in with the others.


http://droby10.addr.com/tutorial/bof/

[smirc]

i've linked to one of my older tutorials in the newbie tutorial's section. so far it has gotten pretty negative comments here, but suprisingly, has been widely accepted outside of antionline prior to my entry here - i don't blame them, it seems they're just really angry people for some reason.

It's a shame that your tutorial got such a negative response here. I thought it was a great tutorial and you obviously spent a lot of time on it. Maybe if more programmers read tutorials like this, we'd have less buggy applications floating around.

[draziw]

Originally posted here by Unleashed
A buffer overflow occurs when a program or process tries to store more data in a buffer (temporary data storage area) than it was intended to hold. Since buffers are created to contain a finite amount of data, the extra information - which has to go somewhere - can overflow into adjacent buffers, corrupting or overwriting the valid data held in them. Although it may occur accidentally through programming error, buffer overflow is an increasingly common type of security attack on data integrity. In buffer overflow attacks, the extra data may contain codes designed to trigger specific actions, in effect sending new instructions to the attacked computer that could, for example, damage the user's files, change data, or disclose confidential information. Buffer overflow attacks are said to have arisen because the C programming language supplied the framework, and poor programming practices supplied the vulnerability.

Quoting the source would probably be a good idea here.

BTW, you might want toknow what buffer is, or you might know but:

Well, at least that's your own, but this...

A buffer is a data area shared by hardware devices or program processes that operate at different speeds or with different sets of priorities. The buffer allows each device or process to operate without being held up by the other. In order for a buffer to be effective, the size of the buffer and the algorithms for moving data into and out of the buffer need to be considered by the buffer designer. Like a cache, a buffer is a "midpoint holding place" but exists not so much to accelerate the speed of an activity as to support the coordination of separate activities.

This term is used both in programming and in hardware. In programming, buffering sometimes implies the need to screen data from its final intended place so that it can be edited or otherwise processed before being moved to a regular file or database.

...lives here. (which, strangely enough, is clickable on the word "buffer" from Mr. Kramer's first page (the first reference, above)).

[Phactorial]

In general, you strayed away from the technicalities of the topic and strayed into chitter chat. This includes that second article. If you write up a tutorial, please reference it.

Regarding stack overflows: our target is always to overwrite the instruction pointer when we want arbitrary execution control. If have to do this from play through the base pointer, fine. It does not even have to overwrite the base pointer, you can jump it many ways (corrupting local pointers for example). The last thing an attacker wants to do is overwrite ebp, it simply adds a lot of more difficulty into the matter and in some architectures, even futility.

Regarding heap overflows: overwriting any re-used pointer is a goal here (this includes functions and function pointers, normal variable pointers, etc...) and does not necessarily only involve corruption of data (this is very common). Actually, most successful exploitation of heap overflows here is also, believe it or not, overwriting the instruction pointer (overwrite a pointer with the address of eip for example). You also failed to mention the dreaded malloc() chunk corruption which has a seamless record when it comes to exploitation and a high risk for a programmer (this alone opens a whole bunch of problems a programmer must check for as well, such as valid signal handler code).

[droby10]

overall, some pretty good feedback. although, i do get the impression that you were probably looking at from your own point of view and experience level...rather than the intended audience's; as indicated in both the AO sections of posting and the introduction page for the tutorial itself.

regarding the technical specifics, your points are very valid...and in at least one of the other tutorials i do go into other methods of flow control including overflowing into dtor, but i'll make a point to add a section on malloc chunk corruptions as well. thanks for the tips, there.

there is one statement that i would like some clarification on though.

"This includes that second article."

would this be in reference to heaptut, part 2, something entirely different?


as for literary style...i guess there's no accounting for it, either.

more robust referencing...? sure why not; the more the merrier.

[pyllyukko]

you might wan't to go check www.enseirb.fr/~glaume/bof/ ...there's a good tutorial about the subject!
--pyllyukko