DISCLAIMER: I am not experienced in anyway, anything I say might be wrong! If you do not agree with something please leave me a comment, I'd love to learn more.
Hey everyone!
I recently started to get into Hacking: The Art of Exploitation by Jon Erickson. If you're curious about this type of stuff and need a good start I would suggest going and getting a copy of this! The second edition has improved a lot from the first, and the examples really help out. If you're going to get this book used; make sure it has the CD. The CD is a live-CD of Ubuntu that's been tailored for the book. It has all of the examples, and by using their OS you are more likely to get results that follow the results from the book. If you have a x86_64 system you will not be able to follow this book line for line.
Alright, so while I was reading this I found something that I found really interesting and thought I'd give you a little taste of what this book is about. If you haven't guessed already (from the title) it's heap overflows! This will be following an example from 0x340 from the book. A heap over flow can occur if there is an important variable after a vulnerable, exploiting this can cause "the program's control flow to be altered".
"
3.4.1.1. Excerpt from notetaker.c
buffer = (char *) ec_malloc(100);
datafile = (char *) ec_malloc(20);
strcpy(datafile, "/var/notes");
if(argc < 2) // If there aren't command-line arguments,
usage(argv[0], datafile); // display usage message and exit.
strcpy(buffer, argv[1]); // Copy into buffer.
printf("[DEBUG] buffer @ %p: \'%s\'\n", buffer, buffer);
printf("[DEBUG] datafile @ %p: \'%s\'\n", datafile, datafile);
" (Taken from Jon Erickson's book)
Okay, so if you're not familiar with C you probably don't know what's going on. I would suggest you go read up on some C before you continue since this book is C heavy. C is a fun language and I think most programmers who want to get into this type of field should study it.
Alright, so some things I should probably clear up. Whenever you evoke malloc() you are reserving blocks of memory in the heap dynamically. If you're coming from other languages such as C++, this is similar to "new". So here's the basics of why this is snippet of code is vulnerable.
We've declared a buffer and reserved 100 bytes, and right after it we declared datafile which will end up copying the location /var/notes. Nothing wrong with that, the part which makes this a mess is "strcpy(buffer,argv[1]". You might be asking 'Well... why does that mess things up?' Well because, we declared buffer to be 100 bytes yet we didn't make sure that whatever is in argv[1] is less than or equal to 100 bytes. Meaning we could overflow this buffer and cause something to be written into datafile, since we declared it after we declared buffer.
So, in the example they use this vulnerability, to cause this little note taking program to write into /tmp/etc/passwd, which is a symlink to /etc/passwd and they append a new root shell called myroot. They do this by overflowing the buffer with filling up the buffer with the name of the new user, and 0 for u/gids a fixed amount of A's and the path to the shell, the by making sure datafile is /etc/passwd.
In the end the program crashes, but if we check the /etc/passwd we can see that the new user and root shell has been written. You can then test it out by doing su myroot, putting in the password, then once you're in type whoami and you will see that you are now a root user!
So this is a cool way to get a new root shell onto a linux box. The only problem is that this has limited application, since of the requirements needed to apply it effectively.
Hey everyone!
I recently started to get into Hacking: The Art of Exploitation by Jon Erickson. If you're curious about this type of stuff and need a good start I would suggest going and getting a copy of this! The second edition has improved a lot from the first, and the examples really help out. If you're going to get this book used; make sure it has the CD. The CD is a live-CD of Ubuntu that's been tailored for the book. It has all of the examples, and by using their OS you are more likely to get results that follow the results from the book. If you have a x86_64 system you will not be able to follow this book line for line.
Alright, so while I was reading this I found something that I found really interesting and thought I'd give you a little taste of what this book is about. If you haven't guessed already (from the title) it's heap overflows! This will be following an example from 0x340 from the book. A heap over flow can occur if there is an important variable after a vulnerable, exploiting this can cause "the program's control flow to be altered".
"
3.4.1.1. Excerpt from notetaker.c
buffer = (char *) ec_malloc(100);
datafile = (char *) ec_malloc(20);
strcpy(datafile, "/var/notes");
if(argc < 2) // If there aren't command-line arguments,
usage(argv[0], datafile); // display usage message and exit.
strcpy(buffer, argv[1]); // Copy into buffer.
printf("[DEBUG] buffer @ %p: \'%s\'\n", buffer, buffer);
printf("[DEBUG] datafile @ %p: \'%s\'\n", datafile, datafile);
" (Taken from Jon Erickson's book)
Okay, so if you're not familiar with C you probably don't know what's going on. I would suggest you go read up on some C before you continue since this book is C heavy. C is a fun language and I think most programmers who want to get into this type of field should study it.
Alright, so some things I should probably clear up. Whenever you evoke malloc() you are reserving blocks of memory in the heap dynamically. If you're coming from other languages such as C++, this is similar to "new". So here's the basics of why this is snippet of code is vulnerable.
We've declared a buffer and reserved 100 bytes, and right after it we declared datafile which will end up copying the location /var/notes. Nothing wrong with that, the part which makes this a mess is "strcpy(buffer,argv[1]". You might be asking 'Well... why does that mess things up?' Well because, we declared buffer to be 100 bytes yet we didn't make sure that whatever is in argv[1] is less than or equal to 100 bytes. Meaning we could overflow this buffer and cause something to be written into datafile, since we declared it after we declared buffer.
So, in the example they use this vulnerability, to cause this little note taking program to write into /tmp/etc/passwd, which is a symlink to /etc/passwd and they append a new root shell called myroot. They do this by overflowing the buffer with filling up the buffer with the name of the new user, and 0 for u/gids a fixed amount of A's and the path to the shell, the by making sure datafile is /etc/passwd.
In the end the program crashes, but if we check the /etc/passwd we can see that the new user and root shell has been written. You can then test it out by doing su myroot, putting in the password, then once you're in type whoami and you will see that you are now a root user!
So this is a cool way to get a new root shell onto a linux box. The only problem is that this has limited application, since of the requirements needed to apply it effectively.
