Security-enhanced version of the CRT function. In this video, we'll look how the function Christoph provided to help make API safer work and how they can help us to make more safer program. We'll take a look at first on Windows and after that the next five example. They are a whole version of example we already see, so it will be quick enough. Each one we'll see how the safe version of the function work and how they can help us to make more secure code. This example is the safer version of that strain example, very similar so determining the variable and constant is the same. But when we get to some function, first one here, we saw that we use this safe version here. When using the safe version in SQL plus, the compiler can know the size of their variables so we don't need to put the size of the variable as a single agreement. If we will use this same function in a C-file, we will need to put the size of the variable as a second argument, just here. It will be also true with the size is not known by the compiler. Example if the L-string will be a pointer and not a local variable, locally we will need to put this size here. Same thing for here and same thing for strncpy. This is the version of the string_0 example that he was safe API. So wherever is similar between depress wars as previously. But here we used the strcpy_s. So that version would avoid any buffer overflow risk. We'll try it. I already combined it. Will switch it a release directory. Try it with the real password, working. Try the trick we get in the last version to cause the buffer or flow and get the gain of the privilege without knowing the real password. But this time we get at by just because the stringcopy_S closed the detect the overflow when they detect the error. This is the version of the scan_0 example that used a safe API. Very few change. First of all, the safe UPI is not limited to function manipulation functions. So even the function to append a file or thing like that is a change to always return a comprehensive error code, and make easier to detect any problem that could result in a security issue. So this is not limited to the string manipulation function. Looking at the process file function. We saw that here, we used fscanf_s to read from the file. Here we need to always provide the information about the size of the variable we passed to this function. What we do here, using this other argument. This will protect the software against buffer overflow. This program will still have other issue just because they don't verify the return value of the call to fscanf-function. I delete. I mean release. So I open the PowerShell, go to the project folder, go to the release folder. But zero would work fine. No problem with it. The one was causing infinite loop just because we did not verify in the code, the return value order of the scan, this problem is not expected to be fixed and it is not fixed. The two that cause a buffer overflow. We said that we did not get the buffer overflow just because the new safe version of the function detect the problem and did not accept to extract data from the input file because of the length of the data. This is the code of this Scan_0 example. But modified to use the Safe api. We saw here that fgets string does not have a safer version, it's already a safe function because we already know the size of the line so it's okay. But when we use the sscan_fs a safer version exist with the underscore s, and this safer version inquest both the size of each variable that receive string. What we do here. I compilate, and we can try it now. Scan_0_a_Safe. Again, I try it with the first input file, it was trying as expected, with the one. The first command is executed, but after that we detect the misformat file. But this is not because of the safe function, it was already like that, and the version Scan_0_a. Now, we saw that the command is not overrated. I didn't [inaudible] buffer overflow because we did not get our buffer overflow. Again, not really because of the Safe api because we already fixed the buffer overflow in the previous version, but it's still working. One of the problem with the Microsoft Safe api for to C is that this function are not available on Linux, so many programmer don't want to use it because of that. If they have to compile the code and on Windows and on Linux. But we can easily enough create a small header file that define some macro and make easy to use the Safe api on Windows, use the same code on the Linux. Even if we don't have all the same security feature in the function. We'll take a look to the four same sample, but under Linux computer this time. We are now on Linux and we'll look at the String_Safe example. First thing we see is the inclusion of the new Intel file from the command directory is the Intel file was looking about. With the file that define, I'll be able to use the Safe api on Windows and on Linux. We'll take a look at this file. This file include some of Intel file that are needed on Linux and not needed on Windows. Also define some constant that we use on Windows and the data file only does not define. Same thing for some datatype. It also define macro that we use to specify the size when we need to specify the size of variable when passing argument two functionalize like string copy, or scanf, or I think like that. On Windows, this macro will be defined to add the argument, but on Linux it would be defined to do absolutely nothing like this would. We also redefine the name of function to use the normal function when we are on Linux. Some function need little bit more processing. When I open, we do what is needed to do to re-implement therefore open underscore S on Linux. Going back to the string safe. We see that the code is the same as on the note, so we use that underscore S version of some function. Down these files that we no longer use check their return value ware just because the underscore S function on their Windows return underscore type T. On the Linux because we still use the string copy or gentle function this one, I return the pointer to the string. We do not use the return value. It's a compromise to do. It's better to use the safer function without checking the return value than to use the not safe function and check the return value or use a return value. We can also look to other sample, string zero sample safe so code is there. Again, we include the new and header file. We use the new version of the safe function. Same thing for scan zero, safe so new income file very minimal change. When we do that process file, we see that we've now use the macro in order to provide the size of the valuable this macro will be replaced by the correct code on Windows and then replaced by absolutely nothing on Linux. If we take a look to the, scan zero are safe. Yes, we again include the header file. When we used the S scan function, we use the size in full macro in order to be able to use the same code on Linux, and on Windows. Conclusion, the Microsoft safe API is not a silver bullet it still can have problem just because the function with simply not do the job or then in some cases, crashed application. If a borrower flow would happen. What is not very great because the anchor event if no longer able to exploit buffer overflow will be able to crash the application what is not the best case. It can help you when the anchor to do with the [inaudible] services attack it would be better to handle the possible overflow. There's a trunk destroying or take some other action. We will see later when we will talk about error handling, how we can do that. Even using the safe API anyway, in how case even it's better to have a crash than have a buffer flow of a fluid echo lead to a real security hacker exploit. We're recommended to use the safe API. It's even recommended to use it even if you compile on Linux using the small header file I showed you or some version of it. You can, even if you want, re-implement the real say version for Linux if it's needed, if you don't do that, it will be safer because it does not really have security TNC on Linux, but it's has the security on Windows, and because the deprecation will crash on Windows later then let the buffer overflow occur. It will help you find this buffer overflow and fix it. On Windows by the same time on Linux, if we shared the same code about platform. This is end of this video. The next video was about C++ stream.
