Protection Against Buffer Overflow Attack in .NET

• Integer overflow: Occurs when a specific data type of a CPU register that is meant to hold values within a certain range is to be assigned a value outside that range. Integer overflow often leads to buffer overflow for cases in which integer overflow occurs when computing the size of the memory to allocate.
  
  
• Stack Overflows: such overflows occur when data is written past the end of buffers allocated on the stack.
  
  
• Heap Overflow: It occurs when data is written outside the space that was allocated for it on the heap.
  
  
• Format String Attacks: Format String attacks occur when the %n parameter of the format string is used to write data outside the target buffer.

It is important to delve deep into CPU internal infrastructure by examine various registers that play a significant role during memory allocation.

• EIP [Extended Instructor Pointer]: It is only administrated by the CPU and determines the next machine instruction in memory to be executed. They contain the offsets of data and instructions.
  
  
• ESP [Extended Stack Pointer]: It points to the top of the stack for the CPU to do push and pop operations.
  
  
• EBP [Extended Base Pointer]: It is used to as reference memory for indirect addressing.
  
  
• EAX/EBX/ECX/EDX: They are used for arithmetic and data movement.
  
  
• Segments [CS/DS/SS/FS/ES/GS]: They are used as a base location for program data, instructions and the stack.

If a method is called by assembler "call" commands, a new stackframe is created and the boundary is defined by the EBP and ESP. First, the call instruction pushes the EIP onto the stack. The previous ESP becomes the new EBP and then the space for the variables is allocated by subtracting its size from the earlier ESP. Finally, at the end of the function call, the ESP becomes the new EBP.



Now, let's consider one more buffer overflow sample that is developed under VC++ Studio. Here the user name and password is supplied as a command-line argument that is copied into corresponding fixed length array of character variable using a strcpy method. Later, the supplied credentials is validated against a predefined password via the strcmp method as in the following;

The moment the user enters tom as a user name and ajay as a password via command-line argument, this program validates successfully those credentials and allows access as in the following:



Now try to enter some bogus data as credentials. As assumed, the program won't allow us to get access as in the following. At this movement, everything is running fine and under control.



The character variable uN and pass can hold up to only 10 characters and if we input data beyond this fixed length, since we are not doing any bounds checking, we are just directly copying the entered data into the buffer directly via the strcpy method. The program would be confused and can't handle such abundant data. That leads to buffer overflow as in the following:



Since we are testing this program in the Windows environment, the OS throws the exception that eventually causes the application to crash because the program accepts too much data beyond the limit of 10. In case of compiling this program via the Turbo compiler, it notifies the buffer overflow exception in a different manner as in the following;



When executing the aforesaid code, it first pushes the two arguments (user name and password) to the creed() method backwards onto the stack. It then calls the creed() function. The instruction CALL then pushes the instruction pointer (EIP) onto the stack. The creed() function now pushes the stack frame pointer onto the stack. The current stack pointer (ESP) is then copied into the EBP, making it the new frame pointer (SFP) as in the following;



Now, the creed() function instruction's next instruction address 0x00412206 is saved to the stack and execution jumps to the ebp in the creed() instruction code where the user name and password values are copied into the eax that is pushed onto the stack. Finally on behalf of both strcpy offsets the strcmp instruction is executed.



Thereafter, the ret opcode is executed that points to the end of program instructions. If the parameter is entered in the correct form or lesser than the fixed length, the program doesn't show any abnormal behavior. But since we are passing an argument beyond the limit, here the register EBP value 79797979 is examined that become the ESP now as in the following;



As we move ahead, the execution should be jump to 00412209 instead of 0079797979. Hence, Visual Studio throws a run time exception at the 79797979 offset where the program denied reading the address space at 79797979 locations. So, the program crashes because here the execution is halted due to an access violation and a buffer overflow attack occurs as in the following:



Protection Mechanisms

Buffer overrun attacks can be thwarted in the Windows environment by making critical configuration changes. The Visual Studio C++ compiler offers several options to enable certain checks at runtime such as /GS, RTC, Runtime library check and DEP. These options can be enabled using a specific compiler flag. The /GS option shields against vulnerable parameters passed into a function in the form of a pointer, string buffer, or C++ reference. Normally, the incoming method parameters are assigned on the stack and are susceptible to being overwritten, just like the return address. To avoid this situation, the compiler makes a copy of the vulnerable incoming parameters after the storage for the local buffers where they are not in threat of being overwritten. On the other side, the RTC compiler option control specifies that at run-time such things as underflow and overflow are checked and stack verification is done and variable use without initialization is detected. However, these run-time checks introduce a performance overhead that is not acceptable for release builds. We must to enable these compiler checks at least.

Buffer Security check (/GS)
Runtime Library check (Both /RTC1…)
Basic Runtime checks (Enable VC++ Run time Library)
DEP



Visual Studio also provides the Data Execution Prevention (DEP) option during compilation in case of not disabling it at the operating system level.



There is another important feature called Data Execution Prevention (DEP) to protect from buffer overflow attacks. This feature has been available in Windows and assumes that no code is intended to be executed that is not part of the program itself. It uses NX technology to prevent the execution of instructions stored in data segments. This feature requires administrative rights to changes its setting. We can alter this configuration from the command prompt as in the following.

To disable the Data Execution Protection setting:

bcdedit.exe /set {current} nx AlwaysOff

To enable the Data Execution Protection setting:

bcdedit.exe /set {current} nx AlwaysOn

We can enable this setting from My Computer advanced settings under the Performance option. These options are disabled by default. In order to enable them, log-in via Administrative account as in the following:



After finishing with all the necessary configuration or BOF attack thwarting option enabling, run the program and supply some bogus argument beyond the buffer limit, the operating system issues a run time buffer overflow exception as in the following:



Even though the /GS compiler option aborts the program, the overrun should be fixed. Buffer overflow attacks can be avoided at the time of coding by ensuring that input data does not exceed the size of the fixed length buffer that it stores. Here, the fixed length buffer size is 10, so calculate the entered data length and ensure it is lesser than 10 as in the following:
Now the buffer overflow attack can be thwarted even if the other protection, such GS and DEP is not applied in the solution configuration. Here, the program alters and exits if the data is entered beyond the buffer limit as in the following:



As we have stated earlier, C and C++ source is most vulnerable to buffer overrun attacks. I will pinpoint some C library methods that make you vulnerable. Hence, it is recommended to avoid using these methods in your source code.

Functions	Potential Problem
Strcpy(char *str, const char * str2)	Str buffer could be overflow
Gets(char *arr)	arr buffer could be overflow
Getwd(char *arr)	arr buffer could be overflow
Scanf()	Arguments can be overflow
Fscanf()	Arguments can be overflow
Sprint(char * str,const char *str2)	Str buffer could be overflow
Strcat(char * str, const char * str2)	Str buffer could be overflow

Final Note

This article explained how buffer overflows works, the varieties of overflows that can materialize and ways to control the flow of execution to our arbitrary code. We have also covered various forms of prevention mechanisms that can be taken to thwart buffer overrun attacks. Memory management and CPU registers have also been covered giving us the elementary knowledge indispensable to detect and exploit buffer overflow vulnerability. We looked into actual exploits on how they were written and where the control on the flow of execution took place. Understanding all these sections will aid us in the future when it comes to analyses, debugging and exploitiing the buffer overflow vulnerability.