This is the third video of the Course 3. This video is about environment variable. A program can pass data to another program using environment variable. The user, using some command, can set environment variable in their shell. The shell will then pass or not, depending on the command that the user used to the programming logs. When a program terminate execution, the changes it made to the environment variable are simply lost. A program cannot return information using environmental variable. It's a unidirectional way to communicate with a program. This slide shows some advice about how to use environment variable. If a program set such variable before calling another program, it must clear them before calling another one in order to avoid leaking data. It's very important. When retrieving an environment variable value, the program must be prepared to receive very long volumes, so try to don't overflow your buffer. Use a safe function to access a variable value and be prepared to receive very long value. When using the value of an environment variable, think about who can have set it? If your program run with special privilege, it can be a user that does not have their special privilege that set their variable. They must be aware of that and avoid use variable that could be harmful for the system. The variable path is a very important. If a hacker can change the value, they will be able to trick a program to execute some malicious code. For example, in the program just called [inaudible] file or other very easy like that. If the pattern is changed the hacker will be able to make the program execute this own version of this utility that will be able to do a lot of thing using the privilege of the user. After that start the real version to just do the real job and the program that [inaudible] it's just called will not know about. I've turned this is not a problem because the exact table run with the same privilege that the user will [inaudible], so the user change a part will not be able to do more damage that he can really do. But if the program run with some special privilege, changing the pad will head over the user to run anything you want with the special privilege. Let's play with the sudo command. We'll just go on Linux and just look at how the sudo manage security issue. In the Linux shell I can know the value of the environment variable by entering the command set and it will give me a lot of stuff. Again maybe use a grep just to look at what the value PATH is. There's the value or the variable PATH. We can use the grep tool to search any other variable of interest. If I call another Bash, it receive the same value for the PATH. I have the value for the PATH and it's the same one. Again, get back the Bash. If now I want to use the sudo to run a Bash as root, what they can do here. We'll run the Bash and it will has the Bash to execute the command set and I will use the grep just to see the value of the PATH. Entering your password and we see that the PATH variable does not have the same value so the sudo commands changed a bad value in order to avoid any problem. If the user of that code the sudo changed the Path, this change will not survive. Let's say that it's not sudo that you use, but we use another program that also use the setuid bit to run as root. Well, for that I just create a program that I call super batch. You can see here, and I set the setuid bits on it. Every time it will start SuperBash, will run as superuser. Now if I call the SuperBash, ask him to run the command sip and use the grep again, I said that the path did not change if they're same path. If the user that programmed the SuperBash did not take this in account, it will most probably use a path that can be tricked to the user in order to run some malicious utility. There are more variables that aren't so important. LD_LIBRARY_PATH can be a trick to make an application and load it differently buried at the Library think load. Shell is used to locate the shell interpreter when a program need to launch some shell commands. So yes, it could be used to trigger the application to load malicious shell. So it's important take it into account. On Windows we have the ComSpec that play about the same role as the shell and Linux, PSModulePath that can trick the PowerShell to load malicious module. We also have TEMP and TMP variable that if [inaudible] can change it, it will be able to make an application, save temporary file somewhere else and maybe be able to retrieve some information, the temporary file after the program runs. So it's also a problem. The same thing exists on Linux 2. Our program have to, as I said in the advise, program need to validate the value before using it, but they also need to think about how the application or the script at the launch will use the environment variable. So it must tuition if a program run with different privilege that their user will allow chip, they will need to do some very aggressive cleanup in the environment variable. If we look at sudo, it do a lot of clean up, so just take a moment and we will check on Linux. I'll just set the variable. I can see the variable here, I can export it to pass it to all command I will launch from there. I saw that if I call batch directly, executing the command set, the batch receive the value of the variable total. If I call batch using the sudo, the variable total is not there. If I do the same thing with the SuperBash I created before, it receive the variable. We clearly see here that sudo, just clear hold the environment and it's most probably what every program that run with privilege agar higher than the privilege of the user who launch the application should do. This is done. The next video will be about what we need to consider when we manipulate input file or data file or configuration file.