buffer-overflow

I'm having problems with return-to-libc exploit. The problem is that nothing happens, but no segmentation fault (and yes I'm actually overflowing the stack). This is my program: int main(int argc, char **argv) { char array[512]; gets(array); } I'm using gets instead of strcopy, because my addresses start with 0x00 and strcpy thinks it's the end of a string, so I can't use it. Here are the addresses that I need: $ gdb main core (gdb) p system $1 = {<text variable, no debug info>} 0x179680 <system> (gdb) p exit $2 = {<text variable, no debug info>} 0x16f6e0 <exit> (gdb) x/s 0xbffffe3f 0xbffffe3f

What set of GCC options provide the best protection against memory corruption vulnerabilities such as Buffer Overflows, and Dangling Pointers? Does GCC provide any type of ROP chain mitigation? Are there performance concerns or other issues that would prevent this GCC option from being on a mission critical application in production? I am looking at the Debian Hardening Guide as well as GCC Mudflap . Here are the following configurations I am considering: -D_FORTIFY_SOURCE=2 -fstack-protector --param ssp-buffer-size=4 -fPIE -pie -Wl,-z,relro,-z,now (ld -z relro and ld -z now) Are there any

I recently finished a university course in C. Therefore I lack experience, of course. Some universities tend to teach their students secure programming, or at least some elements . There's even a video (taken from here ). Being in C, copying strings, requires - as far as I know - strcpy or string.h functions. How do you use it securely in every-day programming? Do you have some functions, which handle allocation to prevent buffer overflows? There's the CERT secure coding standard for C . It's offering examples and compliant solutions: int main(int argc, char *argv[]) { /* ... */ char prog_name

For a homework assignment, I am performing a series of buffer overflow attacks. I was given a program to disassemble, the source code in C for a function that improperly calls gets() , and the source code for several other functions that I am supposed to force the program to call. For one of the tasks, I have to: Inject some code that changes a value, then Return to one of the aforementioned methods The main thing that I don't understand where the program looks in the stack when determining where to return. Where is the return address for a method stored on the stack? The program was compiled

I subclassed a control in order so I can add a few fields that I need, but now when I create it at runtime I get an Access Violation . Unfortunately this Access Violation doesn't happen at the place where I'm creating the control, and even those I'm building with all debug options enabled (including "Build with debug DCU's") the stack trace doesn't help me at all! In my attempt to reproduce the error I tried creating a console application, but apparently this error only shows up in a Forms application, and only if my control is actually shown on a form! Here are the steps to reproduce the

How heap overflow attacks are done? In case of stackoverflow attacks, the attacker replaces the function return address with his address. How this is done in heap overflow attacks? Also, is it possible to run code from heap? Michael Note this varies by platform, and my example is overly simplified. It basically comes down to heap managers having linked lists that could be overrun, and you can use the linked list pointers to overwrite random parts of the process's memory. Imagine I have a naive heap implementation whose control blocks are like this: struct HeapBlockHeader { HeapBlockHeader*

I played around with buffer overflows on Linux (amd64) and tried exploiting a simple program, but it failed. I disabled the security features (address space layout randomization with sysctl -w kernel.randomize_va_space=0 and nx bit in the bios). It jumps to the stack and executes the shellcode, but it doesn't start a shell. The execve syscall succeeds but afterwards it just terminates. Any idea what's wrong? Running the shellcode standalone works just fine. Bonus question: Why do I need to set rax to zero before calling printf? (See comment in the code) Vulnerable file buffer.s : .data .fmtsp: