Buffer overflows occur when a program writes more data to a buffer than it is configured to hold. This can overwrite adjacent memory and compromise the program. Common types of buffer overflows include stack overflows, heap overflows, and format string vulnerabilities. Buffer overflows have been exploited by major computer worms to spread, including the Morris worm in 1988 and the SQL Slammer worm in 2003. Techniques like canaries can help detect buffer overflows by placing check values between buffers and control data. Programming best practices like bounds checking and safe string functions can prevent buffer overflows.

2.  Pushing data more than the capacity of a
buffer
 buffer overflow, or buffer overrun, is an
anomaly where a program, while writing data
to a buffer, overruns the buffer's boundary
and overwrites adjacent memory.
 For example:
- strcpy(target_buffer, large_string)
- printf(str_ptr)

3.  Stack overflow
 Heap overflow
 Of By One overflow
 Function pointers
 Integer overflow
 Format string overflow
 Unicode overflow

4.  WebApplications written in PHP, C#,VB,
VB.NET,ASP.NET, Ruby-on-rails, server-side
javascript and JSP are managed applications,
and are not succeptable to memory corruption
vulnerabilities such as stack buffer overflows or
heap buffer overflows caused by bad web-
application code
 Buffer overflows tend to be the preserve of
C/C++ applications, although other less common
native languages such as Dephi and Fortran are
also susceptible(unmanaged code)

5.  For example, the following program declares a
buffer that is 256 bytes long. However, the
program attempts to fill it with 512 bytes of the
letter “A” (0x41).
int i;
void function(void)
{
char buffer[256]; // create a buffer
for(i=0;i<512;i++) // iterate 512 times
buffer[i]=‘A’; // copy the letterA
}

6.  Here is a sample program with a heap overflow.The program
dynamically allocates memory for two buffers. One buffer is filled with
“A”s.The other one is taken in from the command line. If one types too
many characters on the command line, an overflow will occur.
#include <stdio.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
void main(int argc, char **argv)
{
char *buffer = (char *) malloc(16);
char *input = (char *) malloc(16);
strcpy(buffer,"AAAAAAAAAAAAAAA");
// Use a non-bounds checked function
strcpy(input,argv[1]);
printf(“%s”,buffer);
}

7.  The C language starts array indices at zero, which is not always intuitive
for beginning programmers
 This often leads to off-by-one errors in code that fills a buffer
#include <stdio.h>
int i;
void vuln(char *foobar)
{
char buffer [512];
for (i=0;i<=512;i++)
buffer[i]=foobar[i];
}
void main(int argc, char *argv[])
{
if (argc==2)
vuln(argv[1]);
}
How much damage could a one-byte exploit cause?

8. Another second generation overflow involves function pointers.A function pointer
occurs mainly when callbacks occur. If, in memory, a function pointer follows a buffer,
there is the possibility to overwrite the function pointer if the buffer is unchecked.
Here is a simple example of such code:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int CallBack(const char *szTemp)
{
printf(“CallBack(%s)n”, szTemp);
Return 0;
}
void main(int argc, char **argv)
{
static char buffer[16];
static int (*funcptr)(const char *szTemp);
funcptr = (int (*)(const char *szTemp))CallBack;
strcpy(buffer, argv[1]); // unchecked buffer
(int)(*funcptr)(argv[2]);
}

9.  Format string vulnerabilities occur due to sloppy coding by
software engineers. A variety of C language functions allow
printing the characters to files, buffers, and the screen.These
functions not only place values on the screen, but can format them
as well.
 Many C library functions produce formatted output using format
strings (e.g. printf, fprintf, wprintf, sprintf, etc.)
 These functions permit strings that have no format control to be
printed (unfortunately):
char buffer[13] = “Hello, world!”;
printf(buffer); /* Bad programmer! */
printf(“%s”, buffer); /* Correct coding style */
 The non-standard approach creates the possibility that an attacker
will pass a format string rather than a string to print, which can be
used to write to memory

10. void vuln(char buffer[256]) {
printf(buffer); /* Bad; good:
printf(“%s”,buffer) */
}
int main(int argc, char *argv[]) {
char buffer[256] = “”; /* allocate buffer */
if (2 == argc)
strncpy(buffer, argv[1], 255);
/* copy command line */
vuln(buffer);
return 0;
}
 If the user passes %X on the command line, then printf() will receive a
pointer to a string with “%X” in it on the stack
 Printf() will see the %X and assume there is another parameter above it
on the stack
 Whatever is above it on the stack will be printed in hexadecimal

11.  Use only the good form of printf(); never use
printf(buffer) for any function in the printf family
 Review loop bounds for off-by-one errors
 Avoid unsafe C functions (e.g. strcpy(), strcat(),
sprintf(), gets(), scanf()) and learn how to use
alternatives (e.g. strncpy(), strncat(), snprintf())
 Insert bounds checking code
 Avoid unsafe programming languages (C, C++)
and use more modern, safe languages wherever
possible (Java, Ada, C# in managed mode)

12. Canaries or canary words are known values that are placed between a
buffer and control data on the stack to monitor buffer overflows.
When the buffer overflows, the first data to be corrupted will be the
canary, and a failed verification of the canary data is therefore an alert
of an overflow, which can then be handled, for example, by
invalidating the corrupted data
 Terminator canaries-Terminator Canaries use the observation that
most buffer overflow attacks are based on certain string
operations which end at terminators.The reaction to this
observation is that the canaries are built of NULL terminators, CR,
LF, and -1.The undesirable result is that the canary is known. Even
with the protection, an attacker could potentially overwrite the
canary with its known value, and control information with
mismatched values, thus passing the canary check code, this latter
being executed soon before the specific processor return-from-call
instruction.

13.  Random canaries are randomly generated, usually from an entropy-gathering daemon, in order to
prevent an attacker from knowing their value. Usually, it is not logically possible or plausible to read the
canary for exploiting; the canary is a secure value known only by those who need to know it—the buffer
overflow protection code in this case. Normally, a random canary is generated at program initialization,
and stored in a global variable.This variable is usually padded by unmapped pages, so that attempting to
read it using any kinds of tricks that exploit bugs to read off RAM cause a segmentation fault,
terminating the program. It may still be possible to read the canary, if the attacker knows where it is, or
can get the program to read from the stack.
 RandomXOR canaries-Random XOR Canaries are Random Canaries that are XOR scrambled using all or
part of the control data. In this way, once the canary or the control data is clobbered, the canary value is
wrong. Random XOR Canaries have the same vulnerabilities as Random Canaries, except that the 'read
from stack' method of getting the canary is a bit more complicated.The attacker must get the canary,
the algorithm, and the control data to generate the original canary for re-encoding into the canary he
needs to use to spoof the protection. In addition, Random XOR Canaries can protect against a certain
type of attack involving overflowing a buffer in a structure into a pointer to change the pointer to point
at a piece of control data. Because of the XOR encoding, the canary will be wrong if the control data or
return value is changed. Because of the pointer, the control data or return value can be changed without
overflowing over the canary.

14. 1. The Ping of death(изпращане на прекалено голям ping пакет, който
довеждаше до buffer overflow). Позволява да се сринат различни
операционни системи, чрез изпращане на деформиран „пинг“ пакет от
всяко място в интернет.
2. The Morris (Internet worm of November 2, 1988) worm spread in part by
exploiting a stack buffer overflow in the Unix finger server. [6]
3. TheWitty worm (2004) spread by exploiting a stack buffer overflow in the
Internet Security Systems BlackICE Desktop Agent.The Witty worm is a
computer worm that attacks the firewall and other computer security products
written by a particular company, Internet Security Systems (ISS) now IBM
Internet Security Systems.[7]
4. The Slammer worm (January 25, 2003) spread by exploiting a stack buffer
overflow in Microsoft's SQL server. [8]
5. The Blaster worm spread by exploiting a stack buffer overflow in Microsoft
DCOM service.The BlasterWorm (also known as Lovsan, Lovesan or MSBlast)
was a computer worm that spread on computers running the Microsoft
operating systemsWindows XP and Windows 2000, duringAugust 2003. [9]
6. TheTwilight hack was made for theWii by giving a lengthy character name for
the horse ('Epona') inThe Legend of Zelda:Twilight Princess.This caused a stack
buffer overflow, allowing arbitrary code to be run on an unmodified system.[10]

15. 1. http://en.wikipedia.org/wiki/Buffer_overflow
2. http://en.wikipedia.org/wiki/Stack_buffer_overflow
3. http://en.wikipedia.org/wiki/Heap_overflow
4. http://en.wikipedia.org/wiki/Buffer_overflow_protect
ion
5. Blended Attacks Exploits,Vulnerabilities and
Buffer-OverflowTechniques in ComputerViruses-
By Eric Chien and Péter Ször
6. http://en.wikipedia.org/wiki/Morris_worm
7. http://en.wikipedia.org/wiki/Witty_worm
8. http://en.wikipedia.org/wiki/SQL_Slammer
9. http://en.wikipedia.org/wiki/Blaster_worm
10. http://en.wikipedia.org/wiki/Twilight_hack