It was discussed one of the starting lectures that when using main method with command line arguments (int argc, string argv[]) then argv can be used to access memory location which is not intended to be used.

Above is understandable but I couldn't understand how a bad guy can take advantage of it. If the code written is not to access out of bounds memory location using something like argv then how a bad guy can exploit it?

2 Answers 2


The problem is not with the argv only but with every input from the user, that is not checked. For example say you define a string that will hold 10 characters (let's call it buffer). Then you ask the user to give you a string, but instead of giving you a string with 9 characters at most (plus the '\0') he gives you a string that is 100 characters long. Your program will try to write each character in consecutive places in memory, but when the allocated memory for the string runs out, it will continue to write the string to the adjacent places, that haven't be assigned to it, and may contain other information. Now say that you have a program for a bank, which contains a function giveMeMoney(). You start the program and ask for the user's username and password using a function called login(). If the user is a capable enough exploiter, he can give as a username a sequence of characters, that will exceed the preallocated space. You should also bear in mind that when a function is called, it's placed on the stack, so when it finishes, the program knows to return to the function that called this function, which is right below it in the stack. Now if the user can make the string to overwrite this function call from the stack, he can make your function login() when it finishes, instead of returning the control to the main() function, to return the control to the giveMeMoney() function, with result to get as much money as he/she wants. This is only just a hypothetical way that someone can exploit your program, even though you haven't done something malicious with your code. You can find more information (and much more detailed and well documented) here: https://en.wikipedia.org/wiki/Buffer_overflow

  • Thanks, I really wanted to understand "buffer over read", but it was helpful. Do you have small code snippet for "buffer over read" and "buffer over write". For part of write example, if I specify string or char* as my buffer then there is really no limitation (on cases), and if array is specified char[] then I cannot put value out of bounds, then how buffer over write happens? If we say that in case of string or char*, then this is what expected because there is no bound on it, right? Please correct me if I am wrong. Jul 17, 2015 at 12:34
  • Also, I didn't understand how the buffer overflow can override the return address on the stack. My understanding is that it happens for heap memory and not stack memory, no? Jul 17, 2015 at 12:35
  • 1
    I'm not so advanced as to be able to exploit such weaknesses. Other than that the stack and the heap memory are the two sides of the same memory, so technically you could overwrite stuff in stack by assigning stuff in heap. I think there was a detailed video in a lecture about the two memories. Keep in mind that all variables declared in your program are saved in stack memory, so when the function ends, the variables are discarded. To use the heap you have to specifically allocate memory, using a memory allocation function as malloc or calloc and then use it through pointers.
    – ChrisG
    Jul 17, 2015 at 12:42
  • Nether do I but I wanted to understand that because it is being discussed a lot. I figured out one real life example which is very famous security bug called as HeartBleed which happened because of C's buffer over read issue. "you could overwrite stuff in stack by assigning stuff in heap" I really doubt that it is possible because although they are part of one chunk of memory but they are logically separated, heap will always grow down and stack will grow up. If either of them is going out of bound of their specified limits then there is be error thrown but they will never go into eac other. Jul 18, 2015 at 23:29
  • Refer below one example I have found and some good explanation on how bad code can make computer vulnerable. Jul 25, 2015 at 13:14

Look at below example on how a bad code can make computer vulnerable.

main takes an argument, passing it to f , which has a char array called c of size 12 , and uses this new function strncpy. With this simple line of code, entire computer becomes vulnerable, since someone can run it with certain arguments that represent executable code, that can do things like delete files, get a command-line prompt for more access to your computer, and more.

#include <string.h>
void f(char* bar)
char c[12];
strncpy(c, bar, strlen(bar));
int main(int argc, char* argv[])
  • Did you try it? On a virtual machine for example? I would love to see a demonstration. For example how do you pass the command? In bash for example?
    – ChrisG
    Jul 25, 2015 at 13:26
  • @ChrisGantidis Arguments can be passed as normal like running as - ./TestBadCode agr1 arg2. Now, what a bad guy can do is probably running as ./TestBadCode "rm -rf /*" which would delete all the file from root. Now, how this will get executed, I am not sure, but there was a vulnerability called "Shellshock" or "Bashbackdoor" which took advantage of similar thing. Jul 25, 2015 at 13:57
  • Yes I know about those vulnerabilities. The thing is, even if you pass a command like that, the command is passed as a string, it's not executed. As I understand it you have to overwrite things in the stack until a perfect spot so that the return of the function will execute the command. Or something like that.
    – ChrisG
    Jul 25, 2015 at 13:59
  • Yes, it would be passed as String but if it is passed as an executable code for example, probably as .\TestBadCode "(){rm -rf /*}" then something can happen. However I am not sure but key thing is still we don't know how (I opened this question for the same reason), but it is possible because buffer override can allocate huge amount of memory for malicious arguments which is nothing but an big or small executable code. Jul 25, 2015 at 14:09
  • Another way how it can happen is - return address, which is the address where to return once the function finished, lives on stack, and if the bad guy has overriden this address, then he can very well call his own address which would be having the bad code. Jul 25, 2015 at 19:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .