buffer-overflow

问题 I am trying to compile this using the terminal on ubuntu 12: #include <stdio.h> #include <stdlib.h> main() { /*declare argument array*/ char *args[2]; args[0] = “/bin/bash”; args[1] = NULL; execve(args[0], args, NULL); exit(0); } I found this example on http://www.securitytube.net/video/235 which also happened to be the one Aleph One used in 'Smashing the Stack for Fun and Profit'. I am aware that much has changed since then. In more simple examples I have used: gcc -ggdb -mpreferred-stack

问题 I am learning buffer overflow exploits in Linux x86 binaries. I am doing a classic stack smashing to spawn a root shell in a Ubuntu 12.04 VM by disabling ASLR and compiling the binary by disabling NX bit and stack canaries. During my execution the return address is getting overwritten and the shellcode is getting executed, but I am not getting root shell, instead it results in a bash shell. To mitigate bash protection, I am using zsh shell and I have removed sh->bash symbolic link and created

问题 I've started reading about buffer overflow and how hackers use it to execute custom code instead of the regular compiled one and now I'm trying to reproduce some basic situations, with a vurnerable function that copy data into a char array with the unsafe strcpy. The point is that when I change the return address with one of an assembly instrution of a function defined in the program it works fine, while when I inject code directly in bytes it returned SEGMENTATION FAULT. I'm using the Kali

问题 Consider The following minimal C program: Case Number 1 : #include <stdio.h> #include <string.h> void foo(char* s) { char buffer[10]; strcpy(buffer,s); } int main(void) { foo("01234567890134567"); } This doesn't cause a crash dump If add just one character, so the new main is: Case Number 2 : void main() { foo("012345678901345678"); ^ } The program crashes with a Segmentation fault. Looks like additionally to the 10 characters reserved in the stack there's an additional room for 8 additional

问题 I am getting an exception System.IO.Internal.BufferOverflowException when I am trying to monitor a folder on network path(DFS - Distributed File System): To many changes at once . It works fine when FileSystemWatcher is monitoring local/network path that don't use this filesystem. I am able to get an event from 1000 + files on local path and I am not getting BufferOverflow exception, however when I am copying file to folder that is on DFS I am not even able to get an event from one(To clarify

问题 I am converting double values to string like this: std::string conv(double x) { char buf[30]; sprintf(buf, "%.20g", x); return buf; } I have hardcoded the buffer size to 30, but am not sure if this is large enough for all cases. How can I find out the maximum buffer size I need? Does the precision get higher (and therefore buffer needs to increase) when switching from 32bit to 64? PS: I cannot use ostringstream or boost::lexical_cast for performance reason (see this) 回答1: I have hardcoded the

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

问题 During a call to function B() from function A(), B() allocates a 100-char array and fills it several times, including once with a 101-character string and once with a 110 character string. This is an obvious mistake. Later, function A() tries to access completely unrelated int variable i, and a segmentation fault occurs. I understand why the buffer overrun occurs, but why do I get a segmentation fault when I access this integer? Why is it that I don't simply get garbage data? 回答1: When A()

问题 Usually we all see the basic buffer overflow format which has :- NOPs + shellcode + return_address Why dont we use, NOPs + return_address + shellcode? where we make the return address point to the start of the shellcode? Im guessing that this is because we might be trying to write data outside the stack segment if the vulnerability is in the main(). Am I right? If I am, is that the only reason? Oh, and yes I am not referring to other kinds of attacks which use return-to-libc, ptrace etc. ; I

问题 #include <stdio.h> main() { char buf[8]; sprintf(buf,"AAAA%3s","XXssssssssXXXsssssXXX"); printf("%s\n",buf); } I expected valgrind to detect a buffer overflow with the above code. But it does not report any errors or warnings. Do I need to enable any special flags for that? 回答1: From Valgrind Tutorial What valgrind is NOT Although valgrind is an extremely useful program, it will not miraculously tell you about every memory bug in your program. There are several limitations that you should