Lec. Waleed Bin Shahid

 You might have noticed a lot of issues related to software implementation.  The ultimate requirement of developer(s) is to achieve ◦ A perfect design ◦ Perfect algorithm ◦ Secure coding ◦ Flawless behavior ◦ No runtime errors  Even then there are a lot of implementation vulnerabilities which make a software/program susceptible to attack(s) by hackers.

 What’s your concept/current knowledge about a buffer?  A buffer is a place which stores data temporarily.  There are a lot of ways data can be stored in a computer. Every storage location is not a buffer. char not_a_buf[8] = “PAKISTAN” YES NO

 You might have written a variety of programs (suppose in C/C++). These programs include a lot of data, variables, pointers, functions, function calls, function arguments, return calls etc.  What happens when you open a.txt file in a C/C++ program using object of the fstream class. ◦ Myfile.open(“test.txt”); And don’t close the file accordingly? Myfile.close();  Now you restart your machine, Issue resolved?

 It is a special region of your computer’s memory that stores temporary variables created by each function (including the main() function of a C++ program).  This FILO data structure is managed and optimized by the CPU quite closely.  Every time a function declares a new variable, it is pushed onto the stack. Then every time a function exits, all variables pushed onto the stack by that function, are freed.  Once a stack variable is freed, that region becomes available for other stack variables.

 An important point to understanding stack is that when a function exits, all of its variables are popped off of the stack and hence lost forever  This means that stack variables are local in nature which is related to a concept of variable scope (e.g. local vs. global)  For instance a common issue in C++ programming is attempting to access a variable that was created on the stack inside some function, from a place in your program outside the scope of that function (e.g. after the function has exited).

 Stack grows and shrinks as functions push and pop local variables.  There is no need to manage the memory yourself, variables are allocated and freed automatically  Stack variables only exist while the function that created them, is running

 This is a region of your computer’s memory that is not managed automatically for you and is not tightly managed by the CPU.  Heap comes into use when for example you want to dynamically allocate some memory in a C++ program. You reserve memory in the heap and it is you who frees the heap memory after it has been used  Heap memory is slower to be read from and written to than stack, because one has to use pointers to access heap memory.

StackHeap  Very fast access  Don’t have to explicitly de- allocate variables  Space is managed efficiently by CPU  Memory will not become fragmented  Slower access  No guaranteed efficient use of space  Memory may become fragmented over time as blocks of memory are allocated, then freed  You must manage memory, you’re in charge of allocation and freeing

top of memory Bottom of stack Bottom of memory Top of stack ret c c b b a a Buff_1 Buff_2

 We must remember that memory can only be addressed in multiples of word size. A word is 4 bytes (32 bits).  So our 5 byte buffer is going to take 8 bytes (2 words) of memory.  The 10 byte buffer is going to take 12 bytes (3 words) of memory  So overflow/crash will occur only when the word limit exceeds  Demo (Code-2)

 Segmentation fault or access violation is a fault raised by hardware with memory protection, notifying an operating system (OS) about a memory access violation.  Segmentation faults have various causes, and are a common problem in programs written in the C programming language, where they arise primarily due to errors in use of pointers and lack of bound checking.

 Absence of automatic bounds checking for arrays and pointer access is a major weakness in programming that leads to buffer overflow attacks  A buffer overflow bug is one where the programmer fails to perform adequate bounds check, thus triggering an out-of- bounds memory access that writes beyond the bounds of some memory region  Attackers can use these out-of-bounds memory accesses to corrupt the program’s intended behavior

 Programming languages such as C have vulnerabilities in them.  For instance, the following most widely used built-in C functions are vulnerable ◦ strcat()//Concatenates two strings ◦ strcpy()//copies into a string ◦ sprintf()//Composes a string with the same test as if with printf ◦ gets() ◦ scanf() ◦ vsprintf() ◦ bcopy()

void vulnerable() { char buff [5]; strcpy(buff, “ILovePakistanVery Much”); }  In this example, gets() reads as many bytes of input as are available on standard input, and stores them into buff[]  If the input contains more than 8 bytes of data, then gets() will write past the end of buff, overwriting some other part of memory.  This is a bug. This bug typically causes the program to crash  What might be less obvious is that the consequences can be far worse than that.

 Imagine, elsewhere in the code, there is a login routine that sets the authenticate flag only if the user proves knowledge of the password.  Unfortunately when the buffer overflows, as in the previous example, it sets a value to the authenticate flag to true (or whatever) and the attacker will gain access to the system.  Demo (Code-3)

 printf is a function in C used to print data and values of variables on to the console in a formatted way.

 Use safer languages (Java etc.)  Use of safe libraries  Buffer Overflow protection  Pointer Protection  Executable space protection  ASLR  Check code for bounds checking

 The choice of programming language can have a profound effect on the occurrence of buffer overflows.  A vast body of software having been written in these languages. C and C++ provide no built-in protection against accessing or overwriting data in any part of memory  More specifically, they do not check that data written to a buffer is within the boundaries of that buffer  The Java and.NET Framework environments also require bounds checking on all arrays  Software engineers must carefully consider the tradeoffs of safety versus performance costs when deciding which language and compiler setting to use

 It has also long been recommended to avoid standard library functions which are not bounds checked, such as gets, scanf and strcpy, strcat etc.  Functions like strncpy and strncat provide bounds checking

 Buffer overflow protection is used to detect the most common buffer overflows by checking that the stack has not been altered when a function returns  If it has been altered, the program exits with a segmentation fault.  Stronger stack protection is possible by splitting the stack in two: one for data and one for function returns. This split is present in the Forth language.  Regardless, this is not a complete solution to buffer overflows, as sensitive data other than the return address may still be overwritten

 Buffer overflows work by manipulating pointers (including stored addresses).  PointGuard was proposed as a compiler-extension to prevent attackers from being able to reliably manipulate pointers and addresses  The approach works by having the compiler add code to automatically XOR-encode pointers before and after they are used  Because the attacker (theoretically) does not know what value will be used to encode/decode the pointer, he cannot predict what it will point to if he overwrites it with a new value

 Executable space protection is an approach to buffer overflow protection which prevents execution of code on the stack or the heap  An attacker may use buffer overflows to insert arbitrary code into the memory of a program, but with executable space protection, any attempt to execute that code will cause an exception  Newer variants of Microsoft Windows also support executable space protection, called Data Execution Prevention

 EMET is designed to make it more difficult for an attacker to exploit vulnerabilities of a software and gain access to the system  It supports mitigation techniques that prevent common attack techniques. Primarily related to stack overflows and the techniques used by malware to interact with the OS as it attempts the compromise  It improves resiliency of Windows to the exploitation of buffer overflows  It marks portions of a process’s memory non-executable, making it difficult to exploit memory corruption vulnerabilities

 Address space layout randomization (ASLR) is a computer security technique involved in protection from buffer overflow attacks  In order to prevent an attacker from reliably jumping to a particular exploited function in memory (for example), ASLR involves randomly arranging the positions of key data areas of a program, including the base of the executable and the positions of the stack, heap, and libraries, in a process's address space.  So, the question arises that when variables of a program are stored in stack, why the addresses are always the same? The answer is that it’s only true when ASLR is not enabled (true for old programs). Before ASLR, the OS would try to load programs at the same address. It was quicker to load the program and allows some optimisation.  ASLR was a major security feature in Windows 7. Then why the problem remains the same? The answer is that ASLR is implemented in Win7, but not enabled for all programs. Only programs that are compiled with ASLR enabled flag. Old compilers didn't know about ASLR (it wasn't implemented until after XP), so that flag isn't set in old programs.