Buffer overflow protection for stackalloc in .Net
From C # link for stackalloc:
using stackalloc automatically enables the common language runtime (CLR) buffer overflow detection functionality. If a buffer overflow is detected, the process is terminated as quickly as possible to minimize the chances of malicious code being executed.
In particular, what security mechanism is implemented for .NET?
And will this also detect buffer overflows? What known attacks are weaker against?
For context, for example for the MS C ++ compiler, information is available here:
Windows ISV software security protection :
Stack buffer overflow detection was introduced to the C / C ++ compiler in Visual Studio .NET 2002 and has been updated in subsequent versions. / GS is a compiler that instructs the compiler to add startup code and an epilog function and prologue to generate and test a random number pushed onto the function stack.
Note that Visual C ++ 2005 (and later) also reorders the data on the stack to make it harder to predict that data. Examples include:
• Moving buffers to higher memory than non-buffers. This step can help protect function pointers that are on the stack.
• Moving pointers and buffer arguments to reduce memory at runtime to reduce various buffer overflow attacks.
source to share
Yes, .NET jitter generates a canary stack check which also exists in native code generated by the Microsoft C / C ++ compiler with the / GS compiler option. The basic scheme is to store a random 32-bit value at the top of the stack, written as the method is entered. When the method exits, it checks to see if the value is left. A change in value is a very high predictor of a stack buffer overflow, the kind that malware uses to control the program.
Some code to reproduce:
class Program {
static void Main(string[] args) {
Kaboom();
}
static unsafe void Kaboom() {
byte* ptr = stackalloc byte[1];
for (int ix = 0; ix < 42; ++ix) ptr[ix] = 0;
}
}
Running this code launches the Windows Error Reporting dialog box even when the debugger is connected. You can see the reason for the failure in the output window:
The program '[3636] ConsoleApplication33.exe: Native' exited with code -1073740791 (0xc0000409).
The exception code is defined in the ntstatus.h SDK header file:
//
// MessageId: STATUS_STACK_BUFFER_OVERRUN
//
// MessageText:
//
// The system detected an overrun of a stack-based buffer in this application. This overrun could
// potentially allow a malicious user to gain control of this application.
//
#define STATUS_STACK_BUFFER_OVERRUN ((NTSTATUS)0xC0000409L) // winnt
You can see the code that does this with Debug + Windows + Disassembly. The main parts of Kaboom:
00000000 push ebp ; setup stack frame
00000001 mov ebp,esp
00000003 sub esp,8 ; stack space for local variables
00000006 xor eax,eax
00000008 mov dword ptr [ebp-8],eax ; zero-initialize local variables
0000000b mov dword ptr [ebp-4],eax
0000000e mov dword ptr [ebp-4],esp
00000011 mov dword ptr [ebp-8],0EDDB7EDFh ; canary stored here
// For loop code omitted
0000002d cmp dword ptr [ebp-8],0EDDB7EDFh ; check canary value
00000034 je 0000003B
00000036 call 727767A8 ; crash program
0000003b lea esp,[ebp] ; normal exit, pop stack frame
0000003e pop ebp
0000003f ret
The current value of the canary changes every time the code is encoded.
source to share