Buffer overflow attack on Windows leads to access violation

Question

I was just starting to learn how buffer overflows work, and I tried to simulate an attack on Windows 7 using Visual C 2010. The buffer overflow attack is very far-fetched, it just overwrites the return address with the address of the local variable "buffer". The buffer contains a shellcode string.

Whether I am running the program in Visual Studio 2010 Debug or not, the program will go to the shell code and almost begin to execute it, but I get an access violation error and the program will not continue to execute the shell code.

Why am I getting this error? Is this some kind of buffer overflow protection in Windows?

How can you make a program execute shellcode in a buffer?

edit:

Hans (answer) is correct. This is discussed in the Security chapter of Windows Internals 5th, and the cause of the error is Microsoft's implementation of Executable Space Protection .

If this question helped anyone, any ratings would be appreciated.

void execute_my_shellcode() { char buffer[24]; memcpy(buffer, "\x6A\x21\xFF\x15\x40\x62\x40\x00\x83\xC4\x04\x6A\x0A\xFF\x15\x40\x62\x40\x00\x83\xC4\x04\xC3", 24); printf("current return address: %p\n", *(int*)((char*)&buffer + 24 + 4)); *(int*)((char*)&buffer + 24 + 4) = (int)&buffer; printf("return address is now : %p\n\n", (int*)*(int*)((char*)&buffer + 24 + 4) ); } 

Answer 1

That could work 10 years ago. These obvious security holes have been fixed, the no-execute bit that the processors currently support is one of the countermeasures.

Answer 2

There are other safeguards against buffer overflow attacks that may make this impossible, for example, Page pages at each beginning and end of the stack frame. There is randomization of the layout of the address space and others. There is an article about it here.

The fact is that your shell code may contain null or other types of invalid char, which, when converted, do not turn into an instruction or a valid address ... You need to find out.

note I do not give this last advice to abuse. You are responsible for legally and correctly using this advice.

Answer 3

First of all, your shellcode has zeros in it. Go back through your shellcode and find instructions that do not generate null operation codes (0x00) so that your shellcode is not treated as a string.

Secondly, violation of access rights does not necessarily mean the reason for any protection scheme. It may be (out of a whim) that your return address or shellcode is trying to make the EIP register jump to a place that cannot be executed in memory.

You will have to expire more. Each compiler and computer will be different. There are ways to get around almost everything. You might want to explore this topic more generally, but the first thing I would suggest is to create a duplicate return address pointing to the NOP wipes in the buffer in front of the shellcode so that your shellcode is executed more efficiently and most likely will be more accurate .

The protection of the executable space is correct, as you stated, but my answers above are informal and necessary in most cases. Happy hack :)

Answer 4

Where exactly does the program break? Have you tried using OllyDbg to follow the build instructions to make sure that you at least start executing the buffer or not before? If you do not even execute the first command in the buffer, then the probability that the page of the stack (or the data section in this case, since you provide it as a string literal) was marked as not executable, and you will have to use a different technique, a way to tell Windows to make a stack executable (or data section in this case) for testing / training purposes (I know that ELF binaries have an executable stack flag, and Linux provides the execstack utility to edit the flag).

If it is interrupted after several instructions from your buffer, then this is probably because the instructions in your buffer try to (indirectly) call the absolute address ( 0xff 0x15 0x40 0x62 0x40 x00 => call dword ptr ds:[406240] ) and in W7 , address space location randomization (ASLR) can be enabled (I'm not sure that the VS2010 linker sets the IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE bit in the default PE header).

Edit

Based on the additional information added to the question, it seems that the unexecutable stack issue mentioned in my first paragraph is the culprit. However, even if you get by, the second problem can still be a problem, because you don't know what will happen in 0x00406240 if ASLR is enabled.