How to know what size a char array stores - c

Question

I am writing a dummy example to simulate buffer overflow attack.
Here is the code:
#include<stdio.h>
#include<string.h>
#include<stdlib.h>
void target() {
printf("You overflowed successfully, gg");
exit(0);
}
void vulnerable(char* str1) {
char buf[5];
strcpy(buf, str1);
}
int main() {
printf("%d",sizeof(char));
vulnerable("abcdefghijklmnop");
printf("This only prints in normal control flow");
}
I have checked the size of char which is 1.Here my buffer size is 5 but it is still able to hold 16 values before going to segmentation fault. How is this possible. I know I am missing something in basics. Can anyone explain this?

Answer 1

I cannot stress enough that this is undefined behavior. Compilers are not obligated by the C standard to support this behavior and their implementations will vary.
However, to illuminate the issue you are experiencing and hopefully provide insights into what may be occurring, here is an example.
I compiled your code using https://godbolt.org/, x86-64 gcc 11.1, with the -m32 flag. Here is the notable assembly for the vulnerable function.
vulnerable(char*):
push ebp
mov ebp, esp
sub esp, 24
sub esp, 8
push DWORD PTR [ebp+8]
lea eax, [ebp-13]
push eax
call strcpy
add esp, 16
nop
leave
ret
At a high level, this is what is happening:
The stack frame is adjusted such that the previous ebp is pushed on the stack at the new location of ebp, which is the previous esp. Then 32 bytes are subtracted to extend the new stack frame.
The argument to this function (technically a char*) is stored at ebp+8 by the calling convention used
The memory location of buf is at ebp-13.
strcpy is called with the two parameters that you would expect, buf and the function argument.
So by this implementation, you would have to write 13 bytes into buf before overwriting the value of the previous base pointer at ebp. You would need an additional 4 bytes to overwrite the return address (which would be located at ebp+4). strcpy includes the null-terminator character. So technically calling vulnerable("abcdefghijklmnop") is copying 17 characters into buf. But as I mentioned earlier, buf is at ebp-13 and the return address is at ebp+4, so writing 17 bytes will overflow the return address and almost certainly result in a segfault.
It's worth noting that overwriting the return address will almost always cause a segfault (in the case of exploits, overwriting the return address to something "valid" can result in code execution). It's also worth noting that corrupting the value of the previous ebp will corrupt the stack frame of the previous function, but it may not result in a crash. In this case it likely isn't crashing your program because you simply return to main and then exit.
Exploiting Buffer Overflows
If you are interested in exploiting this vulnerability, you need to use the information I provided above to craft a payload. Let's say you want to call the target function. You first need to identify the address of that function in memory. Assuming features such as Address Space Layout Randomization (ASLR) and Position Independent Code (PIC) are turned off, then your functions will be loaded into consistent memory locations. One way to determine the address of target is by disassembling the binary by attaching a debugger or using a tool such as objdump. Let's say the address of target is 0x0408aab0. Then all you need to do is replace the location of the return address on the stack with that value. Let's put it all together.
The address of target is 0x0408aab0 (hypothetically)
The return address is at ebp+4
The return address is 16 bytes away from your buffer
Thus,
Your payload would look like: 16_byte_padding + 0x0408aab0. Depending on the endianness of your system, you may need to write the address bytes in reverse. Under these assumptions you could generate such a payload with python -c "print 'A'*16 + '\xb0\xaa\x08\x04'"