<\/a>Dependency Analysis<\/h4>\nThe following analysis will be about the spread of issues across projects, while considering the dependency graph.<\/p>\n
This dependency analysis is done based on the dependency information as defined in the visual studio solution by the user. There are other dependencies that are not recorded (such as COM+ dependencies for our COM+ projects, or even P\/Invoked DLLs in C# code). The report still provides sufficient details in order to define some initial plans of action.<\/p>\n
The current results focus on the issues with Critical, High and Medium severities.<\/p>\n
<\/a>Naming Used in the Analysis<\/h4>\nThere are some terms that will be used in the remainder of the documentation:<\/p>\n
\n- \u201cRequires\u201d dependency: relationship between two projects where the subject depends on the object.<\/li>\n
- \u201cUsed By\u201d dependency: relationship between two projects where the object depends on the object.<\/li>\n
- Direct dependency: when the relationship between two projects is direct (as opposed to having an intermediate project that creates the dependency).<\/li>\n
- Recursive dependencies: all direct dependencies of a project and all dependencies of those dependencies (recursively).<\/li>\n<\/ul>\n
<\/a>Overview<\/h4>\nWe have found more than 16000 Critical issues and some specific issues detected are very hard to fix, need some change in architecture, way of working,\u2026 E.g. for the issues present in the DLLs, these projects could be released independently if done carefully:<\/p>\n
\n- We would need to create careful unit testing before doing any changes, to make sure we can regress our fixes.<\/li>\n
- We would have to still do end-to-end testing, although eventually in a lighter or less exhaustive activity.<\/li>\n
- \u201cDeprecrate message\u201d should be inserted in the current DLLs entry point to notify the creation of the new DLL version and to make a progressive transition of usage of these new entries points.<\/li>\n<\/ul>\n
<\/a>Possible Preliminary Actions<\/h4>\nAny decided plan of action should take into account:<\/p>\n
\n- The operational cost involved in fixing bugs (do the actual fixes, do the testing \u2013 unit and e2e): which projects should we proactively fix, which ones should we wait for an IM\/PM (and therefore leave it towards the end) to also fix the issues reported by Fortify.<\/li>\n
- The operational cost of releasing common projects (DLLs in particular) in very early stage vs deferring them for a reasonable period, in case an IM\/PM shows that requires a functional fix (this might optimize testing\/releasing, since we avoid a release for fixing Fortify specifically).<\/li>\n
- The functional impact of releasing each project: which other projects have a dependency in code or in the architecture.<\/li>\n
- The security impact of each project: in terms of what issues represent bigger threats, what applications are more security-sensitive, whether it\u2019s better to fix one project with a big count of issues or many others with small count.<\/li>\n<\/ul>\n
Deferring the Fixing of DLL Issues<\/h4>\n\n- A hard requirement that all DLL dependencies need to be fixed when an application is fixed will probably hinder the team. The reason for this is that such requirement will force to test (E2E) all other applications that also use the same dependency, which is a cost that we might not be able to afford without proper planning and time-boxing.There will be significant amount of unit test development to be done around DLLs, which we\u2019ll also need to plan for.<\/li>\n<\/ul>\n
Fortify scan<\/h3>\n
We use a batch to launch the\u00a0fortify scan for a specific project or for all. Its separated from common build chain because\u00a0its take too much time to make a scan\u00a0every time. A security scan should be\u00a0done at the end of development after the testing and before releasing application.<\/p>\n
Launching Fortify can be done by using a specific menu installed in Visual Studio.<\/p>\n
![\"\"](\"https:\/\/i0.wp.com\/imalogic.com\/blog\/wp-content\/uploads\/2018\/03\/fortify3.png?resize=732%2C266&ssl=1\")
<\/a><\/p>\nOr via a specific command line using several parameters.<\/p>\n
\nsourceanalyzer -b MyBuild -machine-output devenv All-projects.sln \/BUILD debug \/project \"..\\projects\\%$_MyProject%\\%$_MyProject%.vcxproj\" \/ProjectConfig %$_Bits%<\/pre>\n<\/blockquote>\nThe result files from the analyzer is a \u201c.fpr\u201d file type and can be opened using the audit workbench tools.<\/p>\n
![\"\"](\"https:\/\/i0.wp.com\/imalogic.com\/blog\/wp-content\/uploads\/2018\/03\/fortify.png?resize=726%2C407&ssl=1\")
<\/a><\/p>\nWith this audit tools, we can have a look at all security risk.<\/p>\n
For this huge \u201cproject\u201d (composed of many small\/medium projects), we have start with a two pass approach.<\/p>\n
\n- First step called (QuickWins) is used to detect and fix the simple issues.<\/li>\n
- Second step is used to fix more complex issues.<\/li>\n<\/ul>\n
To improve the way of working, we have done a fortify Library composed with fortify functions used to fix issues detected.<\/p>\n
Also, some security issues can be detected only in runtime, means that a specific functions can return some \u201calarm\u201d when secutiry issues are detected\u2026<\/p>\n![\"\"](\"https:\/\/i0.wp.com\/imalogic.com\/blog\/wp-content\/uploads\/2018\/03\/board.png?resize=810%2C464&ssl=1\")
<\/a>A Dashboard sample used during the project development, overview of all projects issues fixed, pending,\u2026<\/figcaption><\/figure>\nSample of Fortify Library Helper<\/h3>\n\nFORTIFY_API\u00a0int fortifyPathManipulation(const char *originalPath, int size);\n\nFORTIFY_API int \u00a0fortifyReverseDnsCheck(struct hostent *resolvedHost);\n\nFORTIFY_API void fortifyEraseAndCleanMemory(void *ptr, int size);<\/pre>\n<\/blockquote>\nTypical Security Issues detected by Fortify Scan<\/h3>\nPotential command injection with Process.Start<\/h4>\n
The dynamic value passed to the command execution should be validated.<\/p>\n
Vulnerable Code<\/h4>\nProcess p = new Process();\n p.StartInfo.FileName = \"exportLegacy.exe\";\n p.StartInfo.Arguments = \" -user \" + input + \" -role user\";\n p.Start();<\/pre>\nRisk<\/h4>\n
If a malicious user is able to controlled either the command FileName or Arguments, he might be able to execute unwanted commands or add unwanted argument. This behavior would not be possible if input parameter are validate against a whitelist of characters.<\/p>\n
Solution<\/h4>\nRegex rgx = new Regex(@\"^[a-zA-Z0-9]+$\");\nif(rgx.IsMatch(input)) {\n Process p = new Process();\n p.StartInfo.FileName = \"exportLegacy.exe\";\n p.StartInfo.Arguments = \" -user \" + input + \" -role user\";\n p.Start();\n}\n<\/pre>\nBuffer Overflow Attacks<\/h3>\n
It gets worse when an attacker comes to know about a buffer over flow in your program and he\/she exploits it.\u00a0Consider this example :<\/p>\n
\n#include <stdio.h> #include <string.h>\n\nint main(void) {\n\nchar buff[15]; \u00a0\u00a0\u00a0 int pass = 0;\n\nprintf(\"\\n Enter the password : \\n\"); \u00a0\u00a0\u00a0 gets(buff);\n\nif (strcmp(buff, \"thegeekstuff\")) \u00a0\u00a0\u00a0 {\n\nprintf (\"\\n Wrong Password \\n\");\n\n} \u00a0\u00a0\u00a0 else \u00a0\u00a0\u00a0 {\n\nprintf (\"\\n Correct Password \\n\"); \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 pass = 1;\n\n}\n\nif (pass) \u00a0\u00a0\u00a0 {\n\n\/* Now Give root or admin rights to user*\/\n\nprintf (\"\\n Root privileges given to the user \\n\");\n\n}\n\nreturn 0;\n\n}\n\n\n<\/pre>\n<\/blockquote>\nThe program above simulates scenario where a program expects a password from user and if the password is correct then it grants root privileges to the user.<\/p>\n
Let\u2019s the run the program with correct password ie \u2018thegeekstuff\u2019 :<\/p>\n
\n$ .\/bfrovrflw\n\nEnter the password : thegeekstuff\n\nCorrect Password\n\nRoot privileges given to the user<\/pre>\n<\/blockquote>\nThis works as expected. The passwords match and root privileges are given.<\/p>\n
But do you know that there is a possibility of buffer overflow in this program. The gets() function does not check the array bounds and can even write string of length greater than the size of the buffer to which the string is written. Now, can you even imagine what can an attacker do with this kind of a loophole?<\/p>\n
Here is an example :<\/p>\n
\n$ .\/bfrovrflw<\/pre>\nEnter the password : hhhhhhhhhhhhhhhhhhhh<\/pre>\nWrong Password<\/pre>\nRoot privileges given to the user.<\/pre>\n<\/blockquote>\nIn the above example, even after entering a wrong password, the program worked as if you gave the correct password.<\/p>\n
There is a logic behind the output above. What attacker did was, he\/she supplied an input of length greater than what buffer can hold and at a particular length of input the buffer overflow so took place that it overwrote the memory of integer \u2018pass\u2019. So despite of a wrong password, the value of \u2018pass\u2019 became non zero and hence root privileges were granted to an attacker.<\/p>\n
There are several other advanced techniques (like code injection and execution) through which buffer over flow attacks can be done but it is always important to first know about the basics of buffer, it\u2019s overflow and why it is harmful.<\/p>\n
<\/h2>\nCommon vulnerabilities guide<\/h1>\n
Most vulnerabilities in C are related to buffer overflows\u00a0and string manipulation. In most cases, this would result in a segmentation fault, but specially crafted malicious input values, adapted to the architecture and environment could yield to arbitrary code execution. You will find below a list of the most common errors and suggested fixes\/solutions.<\/p>\n
gets<\/h2>\n
The stdio gets() function does not check for buffer length and always results in a vulnerability.<\/p>\n
Vulnerable code<\/h5>\n\n#include <stdio.h><\/span>\nint<\/span> main (<\/span>)<\/span> {<\/span>\nchar<\/span> username[<\/span>8]<\/span>;<\/span>\nint<\/span> allow =<\/span> 0<\/span>;<\/span>\nprintf<\/span><\/a> (<\/span>\"Enter your username, please: \"<\/span>)<\/span>;<\/span>\ngets(<\/span>username)<\/span>;<\/span> \/\/ user inputs \"malicious\"<\/span>\nif<\/span> (<\/span>grantAccess(<\/span>username)<\/span>)<\/span> {<\/span>\nallow =<\/span> 1<\/span>;<\/span>\n}<\/span>\nif<\/span> (<\/span>allow !=<\/span> 0<\/span>)<\/span> {<\/span> \/\/ has been overwritten by the overflow of the username.<\/span>\nprivilegedAction(<\/span>)<\/span>;<\/span>\n}<\/span>\nreturn<\/span> 0<\/span>;<\/span>\n}<\/span><\/pre>\n<\/blockquote>\nPrefer using fgets (and dynamically allocated memory!):<\/p>\n
\n#include <stdio.h><\/span>\n#include <stdlib.h><\/span>\n#define LENGTH 8<\/span>\nint<\/span> main (<\/span>)<\/span> {<\/span>\nchar<\/span>*<\/span> username,<\/span> *<\/span>nlptr;<\/span>\nint<\/span> allow =<\/span> 0<\/span>;<\/span>\n\nusername =<\/span> malloc(<\/span>LENGTH *<\/span> sizeof<\/span>(<\/span>*<\/span>username)<\/span>)<\/span>;<\/span>\nif<\/span> (<\/span>!<\/span>username) r<\/span>eturn<\/span> EXIT_FAILURE;<\/span>\nprintf<\/span><\/u> (<\/span>\"Enter your username, please: \"<\/span>)<\/span>;<\/span>\nfgets(<\/span>username,<\/span>LENGTH,<\/span> stdin)<\/span>;<\/span>\n\/\/ fgets stops after LENGTH-1 characters or at a newline character, which ever comes first.<\/span>\n\/\/ but it considers \\n a valid character, so you might want to remove it:<\/span>\nnlptr =<\/span> strchr(<\/span>username,<\/span> '\\n<\/span>'<\/span>)<\/span>;<\/span>\nif<\/span> (<\/span>nlptr)<\/span> *<\/span>nlptr =<\/span> '\\0<\/span>'<\/span>;<\/span>\n\nif<\/span> (<\/span>grantAccess(<\/span>username)<\/span>)<\/span> {<\/span>\nallow =<\/span> 1<\/span>;<\/span>\n}<\/span>\nif<\/span> (<\/span>allow !=<\/span> 0)<\/span> {<\/span>\npriviledgedAction(<\/span>)<\/span>;<\/span>\n}<\/span>\n\nfree(<\/span>username)<\/span>;<\/span>\n\nreturn<\/span> 0<\/span>;<\/span>\n}\n<\/span><\/pre>\n<\/blockquote>\nstrcpy<\/h2>\n
The strcpy built-in function does not check buffer lengths and may very well overwrite memory zone contiguous to the intended destination. In fact, the whole family of functions is similarly vulnerable: strcpy, strcat and strcmp.<\/p>\n
Vulnerable code<\/strong><\/p>\n\nchar<\/span> str1[<\/span>10]<\/span>;<\/span>\nchar<\/span> str2[<\/span>]<\/span>=<\/span>\"abcdefghijklmn\"<\/span>;<\/span>\nstrcpy(<\/span>str1,<\/span>str2)<\/span>;<\/span><\/pre>\n<\/blockquote>\nThe best way to mitigate this issue is to use strlcpy if it is readily available (which is only the case on BSD systems). However, it is very simple to define it yourself, as shown below:<\/p>\n
\n#include <stdio.h><\/span>\n\n#ifndef strlcpy<\/span>\n#define strlcpy(dst,src,sz) snprintf((dst), (sz), \"%s\", (src))<\/span>\n#endif<\/span>\n\nenum<\/span> {<\/span> BUFFER_SIZE =<\/span> 10 }<\/span>;<\/span>\n\nint<\/span> main(<\/span>)<\/span> {<\/span>\nchar<\/span> dst[<\/span>BUFFER_SIZE]<\/span>;<\/span>\nchar<\/span> src[<\/span>]<\/span> =<\/span> \"abcdefghijk\"<\/span>;<\/span>\n\nint<\/span> buffer_length =<\/span> strlcpy(<\/span>dst,<\/span> src,<\/span> BUFFER_SIZE)<\/span>;<\/span>\n\nif<\/span> (<\/span>buffer_length >=<\/span> BUFFER_SIZE)<\/span> {<\/span>\nprintf<\/span> (<\/span>\"String too long: %d (%d expected)\\n<\/span>\"<\/span>,<\/span>\nbuffer_length,<\/span> BUFFER_SIZE-<\/span>1)<\/span>;<\/span>\n}<\/span>\n\nprintf<\/span><\/u> (<\/span>\"String copied: %s
There are some terms that will be used in the remainder of the documentation:<\/p>\n
- \n
- \u201cRequires\u201d dependency: relationship between two projects where the subject depends on the object.<\/li>\n
- \u201cUsed By\u201d dependency: relationship between two projects where the object depends on the object.<\/li>\n
- Direct dependency: when the relationship between two projects is direct (as opposed to having an intermediate project that creates the dependency).<\/li>\n
- Recursive dependencies: all direct dependencies of a project and all dependencies of those dependencies (recursively).<\/li>\n<\/ul>\n
<\/a>Overview<\/h4>\n
We have found more than 16000 Critical issues and some specific issues detected are very hard to fix, need some change in architecture, way of working,\u2026 E.g. for the issues present in the DLLs, these projects could be released independently if done carefully:<\/p>\n
- \n
- We would need to create careful unit testing before doing any changes, to make sure we can regress our fixes.<\/li>\n
- We would have to still do end-to-end testing, although eventually in a lighter or less exhaustive activity.<\/li>\n
- \u201cDeprecrate message\u201d should be inserted in the current DLLs entry point to notify the creation of the new DLL version and to make a progressive transition of usage of these new entries points.<\/li>\n<\/ul>\n
<\/a>Possible Preliminary Actions<\/h4>\n
Any decided plan of action should take into account:<\/p>\n
- \n
- The operational cost involved in fixing bugs (do the actual fixes, do the testing \u2013 unit and e2e): which projects should we proactively fix, which ones should we wait for an IM\/PM (and therefore leave it towards the end) to also fix the issues reported by Fortify.<\/li>\n
- The operational cost of releasing common projects (DLLs in particular) in very early stage vs deferring them for a reasonable period, in case an IM\/PM shows that requires a functional fix (this might optimize testing\/releasing, since we avoid a release for fixing Fortify specifically).<\/li>\n
- The functional impact of releasing each project: which other projects have a dependency in code or in the architecture.<\/li>\n
- The security impact of each project: in terms of what issues represent bigger threats, what applications are more security-sensitive, whether it\u2019s better to fix one project with a big count of issues or many others with small count.<\/li>\n<\/ul>\n
Deferring the Fixing of DLL Issues<\/h4>\n
- \n
- A hard requirement that all DLL dependencies need to be fixed when an application is fixed will probably hinder the team. The reason for this is that such requirement will force to test (E2E) all other applications that also use the same dependency, which is a cost that we might not be able to afford without proper planning and time-boxing.There will be significant amount of unit test development to be done around DLLs, which we\u2019ll also need to plan for.<\/li>\n<\/ul>\n
Fortify scan<\/h3>\n
We use a batch to launch the\u00a0fortify scan for a specific project or for all. Its separated from common build chain because\u00a0its take too much time to make a scan\u00a0every time. A security scan should be\u00a0done at the end of development after the testing and before releasing application.<\/p>\n
Launching Fortify can be done by using a specific menu installed in Visual Studio.<\/p>\n
<\/a><\/p>\nOr via a specific command line using several parameters.<\/p>\n
\n
sourceanalyzer -b MyBuild -machine-output devenv All-projects.sln \/BUILD debug \/project \"..\\projects\\%$_MyProject%\\%$_MyProject%.vcxproj\" \/ProjectConfig %$_Bits%<\/pre>\n<\/blockquote>\n
The result files from the analyzer is a \u201c.fpr\u201d file type and can be opened using the audit workbench tools.<\/p>\n
<\/a><\/p>\nWith this audit tools, we can have a look at all security risk.<\/p>\n
For this huge \u201cproject\u201d (composed of many small\/medium projects), we have start with a two pass approach.<\/p>\n
- \n
- First step called (QuickWins) is used to detect and fix the simple issues.<\/li>\n
- Second step is used to fix more complex issues.<\/li>\n<\/ul>\n
To improve the way of working, we have done a fortify Library composed with fortify functions used to fix issues detected.<\/p>\n
Also, some security issues can be detected only in runtime, means that a specific functions can return some \u201calarm\u201d when secutiry issues are detected\u2026<\/p>\n
<\/a>A Dashboard sample used during the project development, overview of all projects issues fixed, pending,\u2026<\/figcaption><\/figure>\n Sample of Fortify Library Helper<\/h3>\n
\n
FORTIFY_API\u00a0int fortifyPathManipulation(const char *originalPath, int size);\n\nFORTIFY_API int \u00a0fortifyReverseDnsCheck(struct hostent *resolvedHost);\n\nFORTIFY_API void fortifyEraseAndCleanMemory(void *ptr, int size);<\/pre>\n<\/blockquote>\n
Typical Security Issues detected by Fortify Scan<\/h3>\n
Potential command injection with Process.Start<\/h4>\n
The dynamic value passed to the command execution should be validated.<\/p>\n
Vulnerable Code<\/h4>\n
Process p = new Process();\n p.StartInfo.FileName = \"exportLegacy.exe\";\n p.StartInfo.Arguments = \" -user \" + input + \" -role user\";\n p.Start();<\/pre>\n
Risk<\/h4>\n
If a malicious user is able to controlled either the command FileName or Arguments, he might be able to execute unwanted commands or add unwanted argument. This behavior would not be possible if input parameter are validate against a whitelist of characters.<\/p>\n
Solution<\/h4>\n
Regex rgx = new Regex(@\"^[a-zA-Z0-9]+$\");\nif(rgx.IsMatch(input)) {\n Process p = new Process();\n p.StartInfo.FileName = \"exportLegacy.exe\";\n p.StartInfo.Arguments = \" -user \" + input + \" -role user\";\n p.Start();\n}\n<\/pre>\nBuffer Overflow Attacks<\/h3>\n
It gets worse when an attacker comes to know about a buffer over flow in your program and he\/she exploits it.\u00a0Consider this example :<\/p>\n
\n
#include <stdio.h> #include <string.h>\n\nint main(void) {\n\nchar buff[15]; \u00a0\u00a0\u00a0 int pass = 0;\n\nprintf(\"\\n Enter the password : \\n\"); \u00a0\u00a0\u00a0 gets(buff);\n\nif (strcmp(buff, \"thegeekstuff\")) \u00a0\u00a0\u00a0 {\n\nprintf (\"\\n Wrong Password \\n\");\n\n} \u00a0\u00a0\u00a0 else \u00a0\u00a0\u00a0 {\n\nprintf (\"\\n Correct Password \\n\"); \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 pass = 1;\n\n}\n\nif (pass) \u00a0\u00a0\u00a0 {\n\n\/* Now Give root or admin rights to user*\/\n\nprintf (\"\\n Root privileges given to the user \\n\");\n\n}\n\nreturn 0;\n\n}\n\n\n<\/pre>\n<\/blockquote>\nThe program above simulates scenario where a program expects a password from user and if the password is correct then it grants root privileges to the user.<\/p>\n
Let\u2019s the run the program with correct password ie \u2018thegeekstuff\u2019 :<\/p>\n
\n
$ .\/bfrovrflw\n\nEnter the password : thegeekstuff\n\nCorrect Password\n\nRoot privileges given to the user<\/pre>\n<\/blockquote>\n
This works as expected. The passwords match and root privileges are given.<\/p>\n
But do you know that there is a possibility of buffer overflow in this program. The gets() function does not check the array bounds and can even write string of length greater than the size of the buffer to which the string is written. Now, can you even imagine what can an attacker do with this kind of a loophole?<\/p>\n
Here is an example :<\/p>\n
\n
$ .\/bfrovrflw<\/pre>\n
Enter the password : hhhhhhhhhhhhhhhhhhhh<\/pre>\n
Wrong Password<\/pre>\n
Root privileges given to the user.<\/pre>\n<\/blockquote>\n
In the above example, even after entering a wrong password, the program worked as if you gave the correct password.<\/p>\n
There is a logic behind the output above. What attacker did was, he\/she supplied an input of length greater than what buffer can hold and at a particular length of input the buffer overflow so took place that it overwrote the memory of integer \u2018pass\u2019. So despite of a wrong password, the value of \u2018pass\u2019 became non zero and hence root privileges were granted to an attacker.<\/p>\n
There are several other advanced techniques (like code injection and execution) through which buffer over flow attacks can be done but it is always important to first know about the basics of buffer, it\u2019s overflow and why it is harmful.<\/p>\n
<\/h2>\n
Common vulnerabilities guide<\/h1>\n
Most vulnerabilities in C are related to buffer overflows\u00a0and string manipulation. In most cases, this would result in a segmentation fault, but specially crafted malicious input values, adapted to the architecture and environment could yield to arbitrary code execution. You will find below a list of the most common errors and suggested fixes\/solutions.<\/p>\n
gets<\/h2>\n
The stdio gets() function does not check for buffer length and always results in a vulnerability.<\/p>\n
Vulnerable code<\/h5>\n
\n
#include <stdio.h><\/span>\nint<\/span> main (<\/span>)<\/span> {<\/span>\nchar<\/span> username[<\/span>8]<\/span>;<\/span>\nint<\/span> allow =<\/span> 0<\/span>;<\/span>\nprintf<\/span><\/a> (<\/span>\"Enter your username, please: \"<\/span>)<\/span>;<\/span>\ngets(<\/span>username)<\/span>;<\/span> \/\/ user inputs \"malicious\"<\/span>\nif<\/span> (<\/span>grantAccess(<\/span>username)<\/span>)<\/span> {<\/span>\nallow =<\/span> 1<\/span>;<\/span>\n}<\/span>\nif<\/span> (<\/span>allow !=<\/span> 0<\/span>)<\/span> {<\/span> \/\/ has been overwritten by the overflow of the username.<\/span>\nprivilegedAction(<\/span>)<\/span>;<\/span>\n}<\/span>\nreturn<\/span> 0<\/span>;<\/span>\n}<\/span><\/pre>\n<\/blockquote>\nPrefer using fgets (and dynamically allocated memory!):<\/p>\n
\n
#include <stdio.h><\/span>\n#include <stdlib.h><\/span>\n#define LENGTH 8<\/span>\nint<\/span> main (<\/span>)<\/span> {<\/span>\nchar<\/span>*<\/span> username,<\/span> *<\/span>nlptr;<\/span>\nint<\/span> allow =<\/span> 0<\/span>;<\/span>\n\nusername =<\/span> malloc(<\/span>LENGTH *<\/span> sizeof<\/span>(<\/span>*<\/span>username)<\/span>)<\/span>;<\/span>\nif<\/span> (<\/span>!<\/span>username) r<\/span>eturn<\/span> EXIT_FAILURE;<\/span>\nprintf<\/span><\/u> (<\/span>\"Enter your username, please: \"<\/span>)<\/span>;<\/span>\nfgets(<\/span>username,<\/span>LENGTH,<\/span> stdin)<\/span>;<\/span>\n\/\/ fgets stops after LENGTH-1 characters or at a newline character, which ever comes first.<\/span>\n\/\/ but it considers \\n a valid character, so you might want to remove it:<\/span>\nnlptr =<\/span> strchr(<\/span>username,<\/span> '\\n<\/span>'<\/span>)<\/span>;<\/span>\nif<\/span> (<\/span>nlptr)<\/span> *<\/span>nlptr =<\/span> '\\0<\/span>'<\/span>;<\/span>\n\nif<\/span> (<\/span>grantAccess(<\/span>username)<\/span>)<\/span> {<\/span>\nallow =<\/span> 1<\/span>;<\/span>\n}<\/span>\nif<\/span> (<\/span>allow !=<\/span> 0)<\/span> {<\/span>\npriviledgedAction(<\/span>)<\/span>;<\/span>\n}<\/span>\n\nfree(<\/span>username)<\/span>;<\/span>\n\nreturn<\/span> 0<\/span>;<\/span>\n}\n<\/span><\/pre>\n<\/blockquote>\nstrcpy<\/h2>\n
The strcpy built-in function does not check buffer lengths and may very well overwrite memory zone contiguous to the intended destination. In fact, the whole family of functions is similarly vulnerable: strcpy, strcat and strcmp.<\/p>\n
Vulnerable code<\/strong><\/p>\n
\n
char<\/span> str1[<\/span>10]<\/span>;<\/span>\nchar<\/span> str2[<\/span>]<\/span>=<\/span>\"abcdefghijklmn\"<\/span>;<\/span>\nstrcpy(<\/span>str1,<\/span>str2)<\/span>;<\/span><\/pre>\n<\/blockquote>\nThe best way to mitigate this issue is to use strlcpy if it is readily available (which is only the case on BSD systems). However, it is very simple to define it yourself, as shown below:<\/p>\n
\n
#include <stdio.h><\/span>\n\n#ifndef strlcpy<\/span>\n#define strlcpy(dst,src,sz) snprintf((dst), (sz), \"%s\", (src))<\/span>\n#endif<\/span>\n\nenum<\/span> {<\/span> BUFFER_SIZE =<\/span> 10 }<\/span>;<\/span>\n\nint<\/span> main(<\/span>)<\/span> {<\/span>\nchar<\/span> dst[<\/span>BUFFER_SIZE]<\/span>;<\/span>\nchar<\/span> src[<\/span>]<\/span> =<\/span> \"abcdefghijk\"<\/span>;<\/span>\n\nint<\/span> buffer_length =<\/span> strlcpy(<\/span>dst,<\/span> src,<\/span> BUFFER_SIZE)<\/span>;<\/span>\n\nif<\/span> (<\/span>buffer_length >=<\/span> BUFFER_SIZE)<\/span> {<\/span>\nprintf<\/span> (<\/span>\"String too long: %d (%d expected)\\n<\/span>\"<\/span>,<\/span>\nbuffer_length,<\/span> BUFFER_SIZE-<\/span>1)<\/span>;<\/span>\n}<\/span>\n\nprintf<\/span><\/u> (<\/span>\"String copied: %s
- A hard requirement that all DLL dependencies need to be fixed when an application is fixed will probably hinder the team. The reason for this is that such requirement will force to test (E2E) all other applications that also use the same dependency, which is a cost that we might not be able to afford without proper planning and time-boxing.There will be significant amount of unit test development to be done around DLLs, which we\u2019ll also need to plan for.<\/li>\n<\/ul>\n
![\"\"](\"https:\/\/i0.wp.com\/imalogic.com\/blog\/wp-content\/uploads\/2018\/03\/fortify3.png?ssl=1\")
<\/a><\/p>\n