buffer-overflow | 易学教程

Exploit a buffer overflow

阅读更多关于 Exploit a buffer overflow

问题 For my studies I try to create a payload so that it overflows the buffer and calls a "secret" function called "target" This is the code I use for testing on an i686 #include "stdio.h" #include "string.h" void target() { printf("target\n"); } void vulnerable(char* input) { char buffer[16]; strcpy(buffer, input); } int main(int argc, char** argv) { if(argc == 2) vulnerable(argv[1]); else printf("Need an argument!"); return 0; } Task 1 : Create a payload so that target() is being called. This

Buffer Overflow - SegFaults in regular user

阅读更多关于 Buffer Overflow - SegFaults in regular user

Below is my code, both the vulnerable program (stack.c) and my exploit (exploit.c). This code works on a pre-packaged Ubuntu 9 that the prof sent out for windows users (I had a friend test it on his computer), but on Ubuntu 12 that I run on my iMac, i get segfaults when I try and do this in a normal user. here's stack: //stack.c #include <stdio.h> int bof(char *str) { char buffer[12]; //BO Vulnerability strcpy(buffer,str); return 1; } int main(int argc, char* argv[]) { char str[517]; FILE *badfile; badfile = fopen("badfile","r"); fread(str, sizeof(char),517, badfile); bof(str); printf(

memory allocation in C

阅读更多关于 memory allocation in C

I have a question regarding memory allocation order. In the following code I allocate in a loop 4 strings. But when I print the addresses they don't seem to be allocated one after the other... Am I doing something wrong or is it some sort of defense mechanism implemented by the OS to prevent possible buffer overflows? (I use Windows Vista). Thank you. char **stringArr; int size=4, i; stringArr=(char**)malloc(size*sizeof(char*)); for (i=0; i<size; i++) stringArr[i]=(char*)malloc(10*sizeof(char)); strcpy(stringArr[0], "abcdefgh"); strcpy(stringArr[1], "good-luck"); strcpy(stringArr[2], "mully");

Modify return address on stack

阅读更多关于 Modify return address on stack

I looked at the basics of buffer overflow vulnerabilities and tried to understand how the stack is working. For that I wanted to write a simple program which changes the address of the return address to some value. Can anybody help me with figuring out the size of the base pointer to get the offset from the first argument? void foo(void) { char ret; char *ptr; ptr = &ret; //add some offset value here *ptr = 0x00; } int main(int argc, char **argv) { foo(); return 1; } The generated assembler code looks as follows: .file "test.c" .text .globl foo .type foo, @function foo: .LFB0: .cfi_startproc

performing simple buffer overflow on Mac os 10.6

阅读更多关于 performing simple buffer overflow on Mac os 10.6

问题 I'm trying to learn about stack base overflow and write a simple code to exploit stack. But somehow it doesn't work at all but showing only Abort trap on my machine (mac os leopard) I guess Mac os treats overflow differently, it won't allow me to overwrite memory through c code. for example, strcpy(buffer, input) // lets say char buffer[6] but input is 7 bytes on Linux machine, this code successfully overwrite next stack, but prevented on mac os (Abort trap) Anyone know how to perform a

GCC generate Canary or not?

阅读更多关于 GCC generate Canary or not?

my gcc version is 4.8.2 and operating system is ubuntu 14.04 (64 bit). I found that sometimes gcc auto generate the canary to do buffer overflow protection sometimes not, why? case to generate canary: when SIZE is multiple of four #include<stdio.h> #define SIZE 4 int main() { char s[SIZE]; scanf("%s", s); return 0; } asm after gcc -c -g -Wa,-a,-ad ... 4:a.c **** int main() 5:a.c **** { 13 .loc 1 5 0 14 .cfi_startproc 15 0000 55 pushq %rbp 16 .cfi_def_cfa_offset 16 17 .cfi_offset 6, -16 18 0001 4889E5 movq %rsp, %rbp 19 .cfi_def_cfa_register 6 20 0004 4883EC10 subq $16, %rsp 21 .loc 1 5 0 22

return to libc - problem

阅读更多关于 return to libc - problem

问题 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

Executing shellcode stored in environment variable using buffer overflow

阅读更多关于 Executing shellcode stored in environment variable using buffer overflow

I'm using the code below to try to execute some shellcode stored in an environment variable by overflowing the searchstring variable so that the return address of main contains the address of the anvironment variable. However, I get a segmentation fault before the printf command. #include <stdio.h> #include <string.h> void main(int argc, char *argv[]){ char searchstring[100]; if(argc > 1) strcpy(searchstring, argv[1]); else // otherwise searchstring[0] = 0; printf("Here"); } I compile the code using gcc -m32 -g -o overflow.o overflow.c -fno-stack-protector -z execstack in order to disable the

Attempting a buffer overflow

阅读更多关于 Attempting a buffer overflow

问题 I am attempting to change the result of a function using a buffer overflow to change the results on the stack with the following code: #include <stdio.h> #include <string.h> #include <stdlib.h> int check_auth1(char *password) { char password_buffer[8]; int auth_flag = 0; strcpy(password_buffer, password); if (strcmp(password_buffer, "cup") == 0) { auth_flag = 1; } return auth_flag; } int main(int argc, char **argv) { if (argc < 2) { printf("Usage: %s <password>\n", argv[0]); exit(0); } int

What is the most hardened set of options for GCC compiling C/C++?

阅读更多关于 What is the most hardened set of options for GCC compiling C/C++?

问题 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