Buffer Overruns/Overflows are typically caused by trusting input data to a function that is external and is unchecked. Most of the times, this is unintentionally invoked by bad sloppy code. However, when done intentionally by a hacker, this can cause havoc. Some of the most common, buffer overrun prone functions include strcpy, memcpy, strcat etc. (bad standard APIs are explained in another post) In unintentional buffer overruns/overflows, this mostly results in writing to memory not owned by your processes address space. In such cases this would end, in an access violation or a core dump, causing the program to be aborted in most cases. However, these buffer overruns can be exploited to run arbitrary code on the machine, even code that is injected in by the attacker. Before going deep into this overruns let us understand the program executable layout, this helps us in better understanding of the overurns.

Memory layout for a executable on linux is described below. The layout is called ELF (Executable and linkable format), windows counterpart format would be little different but it is similar to the ELF.

Text segment is read-only segment and it includes all the program instructions. All initialized variables (but not local variables) are stored in initialized data segment and all uninitialized variables are stored in BSS (block start by symbol). All malloc/new variables in heap segment, all auto/local variables will be in Stack. Lets take an example and see how variables are stored.

Static int a;

Int x = 1;

Int y;

Int main()

{

Int b;

Char c[10];

Int *d = (int *)malloc(sizeof(int));

/*?. ?.*/

}

In the above program x is stored in initialized data segment, y is stored in BSS, b & c are stored in stack, d is stored in heap. The stack frame in C contains args, return address, base pointer. Feeding more data to stack vars than they can hold will cause overwrite return address.

Stack Overruns: These type of buffer overruns occur, when a buffer that is declared on the stack is overwritten by copying more data than the buffer can hold. It so happens, that the variables (buffer in this case) declared on the stack are located next to the return address of the function?s caller (this is what we have discussed above). As I mentioned above, this usually occurs when user input is unchecked, e.g. strcat. And because the return address is next to the buffer on the stack, overwriting the buffer, means overwriting the return address, which is what gets executed with the function returns. An attacker can carefully exploit the overrun in such a way the data that is overwriting the return address, is an address of a function that he wants to execute.

Heap Overruns: Like Stack Overruns, Heap overruns can also cause memory and stack corruption. But unlike contrary developer belief, although heap overruns are harder to exploit, they are definitely exploitable.
Array Indexing Errors (Overruns and Underruns): These type of errors are less exploited compared to static buffer overruns. You can think of an array as a block on memory (buffer) that you can index into and then read/write from that location. Bad array implementation do not check indices well before access the memory locations. Sloppy code like this can be exploited to run arbitrary code and create havoc. (Well, in some cases you may never ever now that your machine is freely accessible and controlled by the attacker ). Again, unlike contrary developer belief, don?t be fooled that only memory past the end of the array can be exploited.
Format Strings Exploits: These type of exploits are not exactly buffer overruns, but they lead to the same class of problems. These errors are usually caused in functions that take in variable number of arguments, because there isn?t a good way for the function to determine the number of arguments passed into these functions. (printf family in the CRT). The %n type field for printf represents the number of characters successfully written so far to the stream or buffer. This value is stored in the integer whose address is given as the argument. So, this can basically be used to write into memory of the processes address space. But how can an attacker inject such code, the answer lies to the way the sloppy programmer writes code ala printf(input), rather than printf(?%s?, input). The latter prevent the user from using his own format, since its already defined, unlike the earlier case, where the input can be manipulated to create the format string.

Here are some buffer overrun examples explained?.

Casting exploitation:

Overflow:

Please post your comments so that we can eloborate more on required areas.

[tags] buffer overruns[/tags]

Popularity: 10%

As the name suggests, a copy constructor is called whenever an object is copied. This happens in the following cases:

When an object is create from another object during initialization (Class a = b)
When an object is created from another object as a parameter to a constructor (Class a(b))
When an object is passed by value as an argument to a function (function(Class a))
When an object is return from a function (Class a; ? return a;)
When an exception is thrown using this object type (Class a; ?. throw a;)
Whenever an object copying scenario like the ones above is encountered, the copy constructor is invoked. A copy constructor can be either user defined or compiler defined. If the user does not define a copy constructor, then the default compiler defined copy constructor will be invoked during object copy scenarios. The default copy constructor is a bit-by-bit (member wise) copy. But often you will encounter situations where this is not desirable since this is just a shallow copy and sometimes you do not want an exact copy or you may want to do some custom resource management.

Class t1;
Class t2=t1; // Copy Constructor is invoked
Class t3;
t3=t1; // Assignment Operator is invoked

In the Code snippet above, the constructor is invoked twice, during the creation of objects t1 and t3. (Creation of t2 invokes the copy constructor). The destructor is invoked 3 times though. In cases like these, if the constructor allocates memory and the destructor frees it, you will see the t2?s destructor will try to delete already deleted memory, if t1 is destroyed before t2 or vice-versa. Meaning, you are hosed. To prevent this, a user defined copy constructor needs to be provided. which doesn?t do a simple bit-by-bit but rather assigns memory specifically for the object and does a deep copy if required.

To define a copy constructor for a class T, a constructor of the following format needs to be defined.

Class T
{
?
T(const T& t)
?
}

You need a reference because if it were T(T t), it would end in a infinite recursion. (Was that an oxymoron?). const because you are not changing the object in the constructor, you are just copying its contents

Some Rules of Thumb:

Don?t write a copy constructor if a bit-by-bit copy works for the class
If you defined your own copy constructor, it probably because you needed a deep copy or some special resource management, in which case, you will need to release these resources at the end, which means you probably need to define a destructor and you may also want to think of overloading the assignment operator (beware of self-assignment)

[tags] copy contructors, constructors, constructors information, c++ constructors[/tags]

Popularity: 6%

Dynamically Extensible Shell can be configured dynamically depending on application need. User/Developer can extend/reduce shell dynamically by adding /removing module or fine tune shell by adding filter modules over existing core module.

Download
v1

Documentation

Snapshots

Release Notes
Core shell
Shared object shell
Login shell are available with this release
No 3rd party shells integrated
Plan for next release
more enhanced version with 3rd party shells (bash, ash etc) integration

install or usability
Standalone application

Reporting Bugs:
Please report bugs to “open dot ponnada at gmail dot com”
(replace dot with ‘.’; at with ‘@’; just protection from spambots)
Licence:
GPL Please obtain a copy of GPL if one is not present with this software, See GPL for terms and conditions.

Developer(s) : Rajulu Ponnada
Contact: open dot ponnada at gmail dot com

Popularity: 8%