This is the second video of the Course 3. This video is about command-line argument. The command-line argument are the first way a user or another program may interact with a program. It's a very simple unidirectional interaction so that the user or the caller can give information to the program, but he cannot get back information by the command-line argument. To know how to validate the input value the program receive on the command-line, the program must understand who will call the program. It's can be the other part of the same system, other system, or the users directly. In some case, it's more important than other to do a very good validation of the command-line argument. For example, if we have a program with superpower, as we saw in the previous course, the command-line argument can be filename that need to be very carefully verified and validated because the user could then again gain access to file you should not have access. When preparing this presentation, I asked myself a question, what is maximum size from a command-line? I do some research, and on Windows the cmd.exe, the shell, the maximum command size of about 8K. Operating system internal on Windows support 32K for a command-line. Yes, the program on Windows must be preferred to receive as much command-line argument. On Linux, it's even worst. It's in some distribution 128K and it can even be more because it's a parameter that we can set when we configure with the kernel before compiling it. So it can be even more. I knew that for some distribution, it's more than that. So yes, that number and the file of the argument is not limited. That like this for a program, you can receive a very high number argument and each argument can be a very long string. I now have the exercise for you, student. I would like you to review the example we saw in the previous course, and check if this example validate the command-line argument as it should. In some case, you will see clearly find problem because the example was created to show some security issue and some of them was a delivery of the command-line arguments so you will find some problem. It's an exercise so what I suggest you is simply to pause this video, and open the Linux VM and look to the code, to the example. You can just search for a count, the name I used for the argument, use for the number of argument passed on command-line. This way, we'll be able to quickly find all the example that use the command-line argument, and so you will be able to look to them and that try to find if yes or no, they validate the command-line argument as they shall do. After this, in the last slide of the video, we'll list there the program that use argument. We will host another part of the video where we will just do the exercise together. We'll try the code of some example and look at if the validation is done correctly. So it's now time to do the pause and do the exercise before looking to the solution. A quick search let me discover how the example that used the command-line argument. We'll just look the one the name is underline because many of them are very similar, so it's not something interesting to look all of them. First example to look BO_Local. So we go. They have one argument, that is the offset. We don't valid the number or argument, but in this case, it's not really a problem. The argument is optional. We did a real validation with your ear at this line where we check, yes if the argument count is valid before using the argument. Always very important to verify the number of an argument before using an argument because we could just cause a buffer overflow and retrieve a pointer that is not valid. Here we used the function 8y to convert the string to an integer. That could be negative or positive. It was needed for the program, but the index is not validated. Again, it was needed to be able to cause a buffer overflow as intended by the goal of the example. But in a real program, it's clear that taking an offset directly from the command argument and use it to index an array is something to never do. You got an example, Exception underscore SE. SE for a structure of the exception. It receives one argument that is the type of the error 1, 2 codes, and in order to exercise the structure exception converter or translator. Here we've verified a number of arguments right at the start. It's very important that when we have to do that, to do it really at the start of the main function or before doing any other operations or has allocating memory or accessing some data. In this part, this is a good thing. Here we use the atoi to convert the value into an integer, and no risk to buffer overflow just because we don't copy the arguments. It's good again. If the value is not one of the supported value, we will clearly detect it and output a clear error message to the user. We can say that this program does a good validation of the argument. Third example, format_0_safe. This example uses two arguments. One argument, that is the file name. Again, we just go verify the number of arguments at the start, very good. After that, we use the argument without any validation. It's clearly a problem at this level. It could be an empty argument, it could be a lot of things. Maybe in some cases, we don't have really to validate the file name. It's important that the program is run by a user, but run as the User 2, the permission will do all the job for us. It's maybe less important to do good validation of filing, but it can be needed anyway. The Fopen is by itself and search some validation because if the file name is not valid, the Fopen will clearly fail. It can be a constant, has a validation too in some case. Here we [inaudible] use the argument as a format for print f. It's clearly not to do. It was this example, was for n to show. Never use a stream received by the user as a format string for one of the function in the print are familiar. Example, Integers_Div_ SE, SE for structure exception. This example was given the chance to experience divide-by-zero error. This example used two arguments. The two numbers needed to do a division. First verified account wasn't really good but after that, we used the value directly without any validation. In the first one, not a big problem, in the second one a very big problem because we divide by a number that the user provide, and we don't validate if the value is zero. In this case it was needed, because we want to divide by zero, but in a real program value like that must be validated. Received by the command line or receive from a data file or from any other way. We need to validate the value before doing the operation. Example, scan_ 0_ 8_safe. This example, take one argument that is a fill 9, where we read the command to execute. And then the number argument is validated at the start, what is very good. But here the name of the file is not validated before the "fopen" even [inaudible] command that say, "We should validate the file name before using it." So what this kind of command are normally used to run some command, using some privilege rather than the privilege a user that submit the command. Have so we absolutely need to validate the file name just to avoid a user submitting a file to execution but a file that is not [inaudible], using this security owl gain access to other user. Examples, string_0_ safe. This example, use two arguments, the first one is the username, the second one is the password. We verified a number, our argument right at the start of the main function, which is very good. And we now use the username without validating it. It's clearly one of the problem. This is not the worse in this example because redshift password will in a real case do a search of the username in the database. So it will validate the username this way. So it's not a real problem. The real problem in this example is clearly here, where we use the password directly from the command line argument and we copy it in the local variable without validating the size of the variable, of the password. So yes, here we use the safe version of the string copy, but it will, on Windows crash the utility, what is not really good. And on the next it will do absolutely nothing more than do the copy and cause a buffer overflow if the vector of the argument is too long, so it's still not a good validation of our argument before using it. This is the last example we will look at UDP_hacker_0. This example use two command line arguments; The first one being the address and the second one being the port number. Good validation of the number of argument are distorted from me. And after that, we directly use the address. The Inet_pton function do sudden validation and in many case, if the program does not have superpower, it's maybe not needed to do more validation than that at this time. We directly use the argument for the port number. We use the string to unsign long function to convert it into a number. Some validation would be needed here just because, for example, the port number here could be larger than the maximum number. The port number could also be a special port number. So it will be very good to do a better validation here. This is the end of this video, the next video is about environment variable.
