C Overflows Vulnerabilities Exploit Taxonomy And Evaluation on Static Analysis Tools - Mock Viva for Msc Studies

Editor's Notes

• #6: Software vulnerabilities exist since the beginning of IT Become IT (software security) focus with the first recorded finding – Morris Worm (first ever-recorded unintended exploitation) From late 90s onwards, it become the primary focus of software security. However, it does not stop the evolution and trend of vulnerabilities and exploitation. First sophisticated malware exploit Windows vulnerable reported – Code name W32.Stuxnet – attack SCADA systems and it evolved with second version released in 2012 50% - words, spreadsheet, pdf, etc (only 49% contributed by web-based vulnerabilities such as SQLi, XSS, etc). http://www.symantec.com/threatreport/topic.jsp?id=vulnerability_trends&aid=total_number_of_vulnerabilities
• #7: Software vulnerabilities exist since the beginning of IT Become IT (software security) focus with the first recorded finding – Morris Worm (first ever-recorded unintended exploitation) From late 90s onwards, it become the primary focus of software security. However, it does not stop the evolution and trend of vulnerabilities and exploitation. First sophisticated malware exploit Windows vulnerable reported – Code name W32.Stuxnet – attack SCADA systems and it evolved with second version released in 2012 50% - words, spreadsheet, pdf, etc (only 49% contributed by web-based vulnerabilities such as SQLi, XSS, etc). http://www.symantec.com/threatreport/topic.jsp?id=vulnerability_trends&aid=total_number_of_vulnerabilities
• #8: Software vulnerabilities exist since the beginning of IT Become IT (software security) focus with the first recorded finding – Morris Worm (first ever-recorded unintended exploitation) From late 90s onwards, it become the primary focus of software security. However, it does not stop the evolution and trend of vulnerabilities and exploitation. First sophisticated malware exploit Windows vulnerable reported – Code name W32.Stuxnet – attack SCADA systems and it evolved with second version released in 2012 50% - words, spreadsheet, pdf, etc (only 49% contributed by web-based vulnerabilities such as SQLi, XSS, etc). http://www.symantec.com/threatreport/topic.jsp?id=vulnerability_trends&aid=total_number_of_vulnerabilities
• #9: Software vulnerabilities exist since the beginning of IT Become IT (software security) focus with the first recorded finding – Morris Worm (first ever-recorded unintended exploitation) From late 90s onwards, it become the primary focus of software security. However, it does not stop the evolution and trend of vulnerabilities and exploitation. First sophisticated malware exploit Windows vulnerable reported – Code name W32.Stuxnet – attack SCADA systems and it evolved with second version released in 2012 50% - words, spreadsheet, pdf, etc (only 49% contributed by web-based vulnerabilities such as SQLi, XSS, etc). http://www.symantec.com/threatreport/topic.jsp?id=vulnerability_trends&aid=total_number_of_vulnerabilities
• #10: Software vulnerabilities exist since the beginning of IT Become IT (software security) focus with the first recorded finding – Morris Worm (first ever-recorded unintended exploitation) From late 90s onwards, it become the primary focus of software security. However, it does not stop the evolution and trend of vulnerabilities and exploitation. First sophisticated malware exploit Windows vulnerable reported – Code name W32.Stuxnet – attack SCADA systems and it evolved with second version released in 2012 50% - words, spreadsheet, pdf, etc (only 49% contributed by web-based vulnerabilities such as SQLi, XSS, etc). http://www.symantec.com/threatreport/topic.jsp?id=vulnerability_trends&aid=total_number_of_vulnerabilities
• #11: Software vulnerabilities exist since the beginning of IT Become IT (software security) focus with the first recorded finding – Morris Worm (first ever-recorded unintended exploitation) From late 90s onwards, it become the primary focus of software security. However, it does not stop the evolution and trend of vulnerabilities and exploitation. First sophisticated malware exploit Windows vulnerable reported – Code name W32.Stuxnet – attack SCADA systems and it evolved with second version released in 2012 50% - words, spreadsheet, pdf, etc (only 49% contributed by web-based vulnerabilities such as SQLi, XSS, etc). http://www.symantec.com/threatreport/topic.jsp?id=vulnerability_trends&aid=total_number_of_vulnerabilities
• #12: Software vulnerabilities exist since the beginning of IT Become IT (software security) focus with the first recorded finding – Morris Worm (first ever-recorded unintended exploitation) From late 90s onwards, it become the primary focus of software security. However, it does not stop the evolution and trend of vulnerabilities and exploitation. First sophisticated malware exploit Windows vulnerable reported – Code name W32.Stuxnet – attack SCADA systems and it evolved with second version released in 2012 50% - words, spreadsheet, pdf, etc (only 49% contributed by web-based vulnerabilities such as SQLi, XSS, etc). http://www.symantec.com/threatreport/topic.jsp?id=vulnerability_trends&aid=total_number_of_vulnerabilities
• #13: Software vulnerabilities exist since the beginning of IT Become IT (software security) focus with the first recorded finding – Morris Worm (first ever-recorded unintended exploitation) From late 90s onwards, it become the primary focus of software security. However, it does not stop the evolution and trend of vulnerabilities and exploitation. First sophisticated malware exploit Windows vulnerable reported – Code name W32.Stuxnet – attack SCADA systems and it evolved with second version released in 2012 50% - words, spreadsheet, pdf, etc (only 49% contributed by web-based vulnerabilities such as SQLi, XSS, etc). http://www.symantec.com/threatreport/topic.jsp?id=vulnerability_trends&aid=total_number_of_vulnerabilities
• #14: Software vulnerabilities exist since the beginning of IT Become IT (software security) focus with the first recorded finding – Morris Worm (first ever-recorded unintended exploitation) From late 90s onwards, it become the primary focus of software security. However, it does not stop the evolution and trend of vulnerabilities and exploitation. First sophisticated malware exploit Windows vulnerable reported – Code name W32.Stuxnet – attack SCADA systems and it evolved with second version released in 2012 50% - words, spreadsheet, pdf, etc (only 49% contributed by web-based vulnerabilities such as SQLi, XSS, etc). http://www.symantec.com/threatreport/topic.jsp?id=vulnerability_trends&aid=total_number_of_vulnerabilities
• #15: Software vulnerabilities exist since the beginning of IT Become IT (software security) focus with the first recorded finding – Morris Worm (first ever-recorded unintended exploitation) From late 90s onwards, it become the primary focus of software security. However, it does not stop the evolution and trend of vulnerabilities and exploitation. First sophisticated malware exploit Windows vulnerable reported – Code name W32.Stuxnet – attack SCADA systems and it evolved with second version released in 2012 50% - words, spreadsheet, pdf, etc (only 49% contributed by web-based vulnerabilities such as SQLi, XSS, etc). http://www.symantec.com/threatreport/topic.jsp?id=vulnerability_trends&aid=total_number_of_vulnerabilities
• #16: And so does the exploitation. As shown in previous slide – the numbers of release consistently around 4000 per year. It only requires just a single vulnerability to cause catastrophic in computer systems such what happen to 600,000 apple computer due to known vulnerability in apple OS (reported by Symantec Corporation, 2010) It does not requires up-to-date vulnerabilities to exploit. Kaspersky Lab and Symantec Corporation report shows that there are successful exploit based on old vulnerabilities. The statistics shown on the screen justified this. Howard, LeBlanc and Viega listed 19 in 2005 and later increase to 25. MITRE Corporation and SANS Institute release the same number of programming errors in 2011. Few known cases are attack on SCADA system, Train disaster at London, and Toyota break failure. Many ways to inject overflow – exploit unsafe functions, force flaw arithmetic operation, insert crafted message with no termination, etc. There are many languages having overflow vulnerabilities issues. However, the scope of the thesis is on C language (will describe in LR) To this date, there are 11 methods and more than 40 analysis tools (static and dynamic) and more than 10 classifications or taxonomy
• #17: And so does the exploitation. As shown in previous slide – the numbers of release consistently around 4000 per year. It only requires just a single vulnerability to cause catastrophic in computer systems such what happen to 600,000 apple computer due to known vulnerability in apple OS (reported by Symantec Corporation, 2010) It does not requires up-to-date vulnerabilities to exploit. Kaspersky Lab and Symantec Corporation report shows that there are successful exploit based on old vulnerabilities. The statistics shown on the screen justified this. Howard, LeBlanc and Viega listed 19 in 2005 and later increase to 25. MITRE Corporation and SANS Institute release the same number of programming errors in 2011. Few known cases are attack on SCADA system, Train disaster at London, and Toyota break failure. Many ways to inject overflow – exploit unsafe functions, force flaw arithmetic operation, insert crafted message with no termination, etc. There are many languages having overflow vulnerabilities issues. However, the scope of the thesis is on C language (will describe in LR) To this date, there are 11 methods and more than 40 analysis tools (static and dynamic) and more than 10 classifications or taxonomy
• #18: And so does the exploitation. As shown in previous slide – the numbers of release consistently around 4000 per year. It only requires just a single vulnerability to cause catastrophic in computer systems such what happen to 600,000 apple computer due to known vulnerability in apple OS (reported by Symantec Corporation, 2010) It does not requires up-to-date vulnerabilities to exploit. Kaspersky Lab and Symantec Corporation report shows that there are successful exploit based on old vulnerabilities. The statistics shown on the screen justified this. Howard, LeBlanc and Viega listed 19 in 2005 and later increase to 25. MITRE Corporation and SANS Institute release the same number of programming errors in 2011. Few known cases are attack on SCADA system, Train disaster at London, and Toyota break failure. Many ways to inject overflow – exploit unsafe functions, force flaw arithmetic operation, insert crafted message with no termination, etc. There are many languages having overflow vulnerabilities issues. However, the scope of the thesis is on C language (will describe in LR) To this date, there are 11 methods and more than 40 analysis tools (static and dynamic) and more than 10 classifications or taxonomy
• #19: And so does the exploitation. As shown in previous slide – the numbers of release consistently around 4000 per year. It only requires just a single vulnerability to cause catastrophic in computer systems such what happen to 600,000 apple computer due to known vulnerability in apple OS (reported by Symantec Corporation, 2010) It does not requires up-to-date vulnerabilities to exploit. Kaspersky Lab and Symantec Corporation report shows that there are successful exploit based on old vulnerabilities. The statistics shown on the screen justified this. Howard, LeBlanc and Viega listed 19 in 2005 and later increase to 25. MITRE Corporation and SANS Institute release the same number of programming errors in 2011. Few known cases are attack on SCADA system, Train disaster at London, and Toyota break failure. Many ways to inject overflow – exploit unsafe functions, force flaw arithmetic operation, insert crafted message with no termination, etc. There are many languages having overflow vulnerabilities issues. However, the scope of the thesis is on C language (will describe in LR) To this date, there are 11 methods and more than 40 analysis tools (static and dynamic) and more than 10 classifications or taxonomy
• #20: Summarize the previous statement – share about the current landscapes and our critical finding. Significant: C overflow vulnerabilities is still relevant, thus by identifying and classifying all types of C overflow vulnerabilities; it will improve understanding of overflow vulnerabilities thus helping in securing software from development to deployment stage. C language is widely used in various mission-critical applications, OS, and drivers (embedded), hence, the result of this research is valuable towards providing protection at early stage of development. By classifying it in a structured way and focusing on the root cause from source code perspective, it will ease the understanding of software developers to write codes, which is free from C overflow vulnerabilities. It is also useful for program analysis tool as guidelines in analysing the software; that is the analysis methods or the tool itself. By experiment and evaluation on feasibility of C overflow vulnerabilities type, we will be able to focus security research initiatives on most critical and relevant types of C overflow vulnerabilities. By evaluating static analysis tools using our constructed classifications and using major open-source programs, we will determine the identified static analysis tools capability, strength and weaknesses. Using the same result, we will determine criticality and persistency of all C overflow vulnerabilities types.
• #21: Summarize the previous statement – share about the current landscapes and our critical finding. Significant: C overflow vulnerabilities is still relevant, thus by identifying and classifying all types of C overflow vulnerabilities; it will improve understanding of overflow vulnerabilities thus helping in securing software from development to deployment stage. C language is widely used in various mission-critical applications, OS, and drivers (embedded), hence, the result of this research is valuable towards providing protection at early stage of development. By classifying it in a structured way and focusing on the root cause from source code perspective, it will ease the understanding of software developers to write codes, which is free from C overflow vulnerabilities. It is also useful for program analysis tool as guidelines in analysing the software; that is the analysis methods or the tool itself. By experiment and evaluation on feasibility of C overflow vulnerabilities type, we will be able to focus security research initiatives on most critical and relevant types of C overflow vulnerabilities. By evaluating static analysis tools using our constructed classifications and using major open-source programs, we will determine the identified static analysis tools capability, strength and weaknesses. Using the same result, we will determine criticality and persistency of all C overflow vulnerabilities types.
• #22: Summarize the previous statement – share about the current landscapes and our critical finding. Significant: C overflow vulnerabilities is still relevant, thus by identifying and classifying all types of C overflow vulnerabilities; it will improve understanding of overflow vulnerabilities thus helping in securing software from development to deployment stage. C language is widely used in various mission-critical applications, OS, and drivers (embedded), hence, the result of this research is valuable towards providing protection at early stage of development. By classifying it in a structured way and focusing on the root cause from source code perspective, it will ease the understanding of software developers to write codes, which is free from C overflow vulnerabilities. It is also useful for program analysis tool as guidelines in analysing the software; that is the analysis methods or the tool itself. By experiment and evaluation on feasibility of C overflow vulnerabilities type, we will be able to focus security research initiatives on most critical and relevant types of C overflow vulnerabilities. By evaluating static analysis tools using our constructed classifications and using major open-source programs, we will determine the identified static analysis tools capability, strength and weaknesses. Using the same result, we will determine criticality and persistency of all C overflow vulnerabilities types.
• #23: Summarize the previous statement – share about the current landscapes and our critical finding. Significant: C overflow vulnerabilities is still relevant, thus by identifying and classifying all types of C overflow vulnerabilities; it will improve understanding of overflow vulnerabilities thus helping in securing software from development to deployment stage. C language is widely used in various mission-critical applications, OS, and drivers (embedded), hence, the result of this research is valuable towards providing protection at early stage of development. By classifying it in a structured way and focusing on the root cause from source code perspective, it will ease the understanding of software developers to write codes, which is free from C overflow vulnerabilities. It is also useful for program analysis tool as guidelines in analysing the software; that is the analysis methods or the tool itself. By experiment and evaluation on feasibility of C overflow vulnerabilities type, we will be able to focus security research initiatives on most critical and relevant types of C overflow vulnerabilities. By evaluating static analysis tools using our constructed classifications and using major open-source programs, we will determine the identified static analysis tools capability, strength and weaknesses. Using the same result, we will determine criticality and persistency of all C overflow vulnerabilities types.
• #25: Summarize the previous statement – share about the current landscapes and our critical finding. Biezer (1990) present software vuln in 9 classes based on SDLC phases. Piessens share the same views and come out with taxonomy. Vipindeep and Jalote in 2005 classified 8 soft vuln based on insecure coding technique. From many soft vuln mentioned, the most mentioned due to high significant and impact is programming errors. It is also listed in various database Many types of programming errors - lack of input validation, incorrect value type, insufficient exception handling, and incorrect memory assignment or use The result of programming errors - It can affect the confidentiality, integrity, and availability of information system which resulted in losses in profit, life, and infrastructure’s or mechanical breakdown. Many exploitation technique to exploit programming errors. Among those top programming error vulnerabilities exploitation techniques are Cross-Site Scripting (XSS) Injection, SQL Injection, Operating System (OS) Command Injection, Path Traversal, and memory violation or known as overflow vulnerabilities (Martin B. , Brown, Parker, & Kirby, 2011), (Siddharth & Doshi, 2010), (Shariar & Zulkernine, 2011), (IMPERVA, 2011) However, this programming error is more synonym with C and Java languages (Cenzic Inc, 2009), (MITRE Corporation, 2012) and (Mandalia, 2011) because both are dominant languages at OS, server, database, and application level (TIOBE Software, 2012), (Tiwebb Ltd., 2007), (DedaSys LLC, 2011) and (Krill, 2011). Even though overflow does occurred in other languages such as PHP (SecurityFocus, 2009) and (Esser, 2006), Python (Python Software Foundation, 2010), (SecurityFocus, 2010) and (SPI, 2010), Perl (Gentoo Foundation, 2007), (Secunia, 2008), and .NET (SecurityFocus, 2009) and (IBM, 2009), it is not the dominant vulnerability for the programming languages Between Java and C, which is critical? Critical applications such as Windows OS (Microsoft, 2006) and (Microsoft, 2009) and Android OS (Android Developer, 2012), Linux OS (Stack Exchange Inc, 2012), databases (Oracle Corporation, 2012) and (Oracle FAQ, 2012), and web servers (The Apache Software Foundation, 2011). Even the IT giant, Apple Inc., is still relying on C to develop their Apple iOS and Mac OS X (Apple Inc, 2012). Single C overflow vulnerability occurs in this mission critical can causes havoc as published by Symantec whereby 600,000 computers running Apple iOS were affected by one vulnerability found in the OS (Symantec Corporation, 2013). In addition, there are successful attacks that exploited old C overflow vulnerability (Kaspersky Lab, 2013)
• #26: Summarize the previous statement – share about the current landscapes and our critical finding. Biezer (1990) present software vuln in 9 classes based on SDLC phases. Piessens share the same views and come out with taxonomy. Vipindeep and Jalote in 2005 classified 8 soft vuln based on insecure coding technique. From many soft vuln mentioned, the most mentioned due to high significant and impact is programming errors. It is also listed in various database Many types of programming errors - lack of input validation, incorrect value type, insufficient exception handling, and incorrect memory assignment or use The result of programming errors - It can affect the confidentiality, integrity, and availability of information system which resulted in losses in profit, life, and infrastructure’s or mechanical breakdown. Many exploitation technique to exploit programming errors. Among those top programming error vulnerabilities exploitation techniques are Cross-Site Scripting (XSS) Injection, SQL Injection, Operating System (OS) Command Injection, Path Traversal, and memory violation or known as overflow vulnerabilities (Martin B. , Brown, Parker, & Kirby, 2011), (Siddharth & Doshi, 2010), (Shariar & Zulkernine, 2011), (IMPERVA, 2011) However, this programming error is more synonym with C and Java languages (Cenzic Inc, 2009), (MITRE Corporation, 2012) and (Mandalia, 2011) because both are dominant languages at OS, server, database, and application level (TIOBE Software, 2012), (Tiwebb Ltd., 2007), (DedaSys LLC, 2011) and (Krill, 2011). Even though overflow does occurred in other languages such as PHP (SecurityFocus, 2009) and (Esser, 2006), Python (Python Software Foundation, 2010), (SecurityFocus, 2010) and (SPI, 2010), Perl (Gentoo Foundation, 2007), (Secunia, 2008), and .NET (SecurityFocus, 2009) and (IBM, 2009), it is not the dominant vulnerability for the programming languages Between Java and C, which is critical? Critical applications such as Windows OS (Microsoft, 2006) and (Microsoft, 2009) and Android OS (Android Developer, 2012), Linux OS (Stack Exchange Inc, 2012), databases (Oracle Corporation, 2012) and (Oracle FAQ, 2012), and web servers (The Apache Software Foundation, 2011). Even the IT giant, Apple Inc., is still relying on C to develop their Apple iOS and Mac OS X (Apple Inc, 2012). Single C overflow vulnerability occurs in this mission critical can causes havoc as published by Symantec whereby 600,000 computers running Apple iOS were affected by one vulnerability found in the OS (Symantec Corporation, 2013). In addition, there are successful attacks that exploited old C overflow vulnerability (Kaspersky Lab, 2013)
• #27: Also known as buffer overflow/overrun. Unsafe function is more general in definition compared to buffer overflow, buffer overrun or format string attack as it can be unsafe by nature such as printf and scanf and exploiting unsafe function may not involve buffer and it can happen to non-related string formation like strlen. Therefore, the term ‘Unsafe function’ covers wide range of C overflows vulnerabilities as listed by Microsoft. Furthermore, the term is closely related to coding, thus understandable to software developers rather than the other earlier used terms. Therefore, as it was identified by Wagner in 2000 (Wagner D. A., 2000), unsafe functions is identified as the first C overflows vulnerabilities class The hype of the research started from the year 2000 Although we listed 9 classes, the actual classes identified is 6. Others mentioned the behaviour but not the class name. Among these nine classes, the most critical and of high occurrences are the unsafe functions and array out-of-bound. However, despite being ignored by some experts and number of occurrences is not as many compared to the two classes, the other seven classes are significantly important because of their impact and severity are ranked at least medium in many vulnerabilities database website. Beside those identified nine classes of C overflow vulnerabilities, there is one more class that was left out by many security experts or researchers although NIST identified it in the year 2007 (Black, Kass, & Koo, Source Code Security Analysis Tool Functional Specification Version 1.0, 2007). It is restated again by Seacord in the year 2008 (Seacord R. C., The CERT C Secure Coding Standard, 2008). NIST listed again the same vulnerability in their report in the year of 2011 (Black, Kass, Koo, & Fong, Source Code Security Analysis Tool Functional Specification Version 1.1 , 2011). It is also identified and listed by Computer Emergency Response Team (CERT) of Carnegie Mellon University (Seacord R. C., CERT C Secure Coding Standard, 2011), (Pincar & Haas, 2011), (Seacord & Haas, EXP41-C. Do not add or subtract a scaled integer to a pointer, 2011), OWASP (OWASP Organization, 2009) and NIST (NIST, 2012). The vulnerability is known as pointer scaling or mixing whereby it is a vulnerability that trigger by incorrect or invalid use of pointer in an arithmetic operation. It might be because it can be easily confuse between function pointer and pointer scaling in terms of the name and use of pointer. However, the behaviour, syntax and way of exploiting is very different from source code perspective for the two pointer related vulnerabilities. As published by NIST (NIST, 2012), pointer scaling is ranked between medium to critical severity, low complexity, and complete impact on confidentiality, integrity and availability. Hence, it shall not be ignored and should be included in any discussion on C overflows vulnerabilities too. Summarized the discussion
• #28: Also known as buffer overflow/overrun. Unsafe function is more general in definition compared to buffer overflow, buffer overrun or format string attack as it can be unsafe by nature such as printf and scanf and exploiting unsafe function may not involve buffer and it can happen to non-related string formation like strlen. Therefore, the term ‘Unsafe function’ covers wide range of C overflows vulnerabilities as listed by Microsoft. Furthermore, the term is closely related to coding, thus understandable to software developers rather than the other earlier used terms. Therefore, as it was identified by Wagner in 2000 (Wagner D. A., 2000), unsafe functions is identified as the first C overflows vulnerabilities class The hype of the research started from the year 2000 Although we listed 9 classes, the actual classes identified is 6. Others mentioned the behaviour but not the class name. Among these nine classes, the most critical and of high occurrences are the unsafe functions and array out-of-bound. However, despite being ignored by some experts and number of occurrences is not as many compared to the two classes, the other seven classes are significantly important because of their impact and severity are ranked at least medium in many vulnerabilities database website. Beside those identified nine classes of C overflow vulnerabilities, there is one more class that was left out by many security experts or researchers although NIST identified it in the year 2007 (Black, Kass, & Koo, Source Code Security Analysis Tool Functional Specification Version 1.0, 2007). It is restated again by Seacord in the year 2008 (Seacord R. C., The CERT C Secure Coding Standard, 2008). NIST listed again the same vulnerability in their report in the year of 2011 (Black, Kass, Koo, & Fong, Source Code Security Analysis Tool Functional Specification Version 1.1 , 2011). It is also identified and listed by Computer Emergency Response Team (CERT) of Carnegie Mellon University (Seacord R. C., CERT C Secure Coding Standard, 2011), (Pincar & Haas, 2011), (Seacord & Haas, EXP41-C. Do not add or subtract a scaled integer to a pointer, 2011), OWASP (OWASP Organization, 2009) and NIST (NIST, 2012). The vulnerability is known as pointer scaling or mixing whereby it is a vulnerability that trigger by incorrect or invalid use of pointer in an arithmetic operation. It might be because it can be easily confuse between function pointer and pointer scaling in terms of the name and use of pointer. However, the behaviour, syntax and way of exploiting is very different from source code perspective for the two pointer related vulnerabilities. As published by NIST (NIST, 2012), pointer scaling is ranked between medium to critical severity, low complexity, and complete impact on confidentiality, integrity and availability. Hence, it shall not be ignored and should be included in any discussion on C overflows vulnerabilities too. Summarized the discussion
• #29: Also known as buffer overflow/overrun. Unsafe function is more general in definition compared to buffer overflow, buffer overrun or format string attack as it can be unsafe by nature such as printf and scanf and exploiting unsafe function may not involve buffer and it can happen to non-related string formation like strlen. Therefore, the term ‘Unsafe function’ covers wide range of C overflows vulnerabilities as listed by Microsoft. Furthermore, the term is closely related to coding, thus understandable to software developers rather than the other earlier used terms. Therefore, as it was identified by Wagner in 2000 (Wagner D. A., 2000), unsafe functions is identified as the first C overflows vulnerabilities class The hype of the research started from the year 2000 Although we listed 9 classes, the actual classes identified is 6. Others mentioned the behaviour but not the class name. Among these nine classes, the most critical and of high occurrences are the unsafe functions and array out-of-bound. However, despite being ignored by some experts and number of occurrences is not as many compared to the two classes, the other seven classes are significantly important because of their impact and severity are ranked at least medium in many vulnerabilities database website. Beside those identified nine classes of C overflow vulnerabilities, there is one more class that was left out by many security experts or researchers although NIST identified it in the year 2007 (Black, Kass, & Koo, Source Code Security Analysis Tool Functional Specification Version 1.0, 2007). It is restated again by Seacord in the year 2008 (Seacord R. C., The CERT C Secure Coding Standard, 2008). NIST listed again the same vulnerability in their report in the year of 2011 (Black, Kass, Koo, & Fong, Source Code Security Analysis Tool Functional Specification Version 1.1 , 2011). It is also identified and listed by Computer Emergency Response Team (CERT) of Carnegie Mellon University (Seacord R. C., CERT C Secure Coding Standard, 2011), (Pincar & Haas, 2011), (Seacord & Haas, EXP41-C. Do not add or subtract a scaled integer to a pointer, 2011), OWASP (OWASP Organization, 2009) and NIST (NIST, 2012). The vulnerability is known as pointer scaling or mixing whereby it is a vulnerability that trigger by incorrect or invalid use of pointer in an arithmetic operation. It might be because it can be easily confuse between function pointer and pointer scaling in terms of the name and use of pointer. However, the behaviour, syntax and way of exploiting is very different from source code perspective for the two pointer related vulnerabilities. As published by NIST (NIST, 2012), pointer scaling is ranked between medium to critical severity, low complexity, and complete impact on confidentiality, integrity and availability. Hence, it shall not be ignored and should be included in any discussion on C overflows vulnerabilities too. Summarized the discussion
• #30: Also known as buffer overflow/overrun. Unsafe function is more general in definition compared to buffer overflow, buffer overrun or format string attack as it can be unsafe by nature such as printf and scanf and exploiting unsafe function may not involve buffer and it can happen to non-related string formation like strlen. Therefore, the term ‘Unsafe function’ covers wide range of C overflows vulnerabilities as listed by Microsoft. Furthermore, the term is closely related to coding, thus understandable to software developers rather than the other earlier used terms. Therefore, as it was identified by Wagner in 2000 (Wagner D. A., 2000), unsafe functions is identified as the first C overflows vulnerabilities class The hype of the research started from the year 2000 Although we listed 9 classes, the actual classes identified is 6. Others mentioned the behaviour but not the class name. Among these nine classes, the most critical and of high occurrences are the unsafe functions and array out-of-bound. However, despite being ignored by some experts and number of occurrences is not as many compared to the two classes, the other seven classes are significantly important because of their impact and severity are ranked at least medium in many vulnerabilities database website. Beside those identified nine classes of C overflow vulnerabilities, there is one more class that was left out by many security experts or researchers although NIST identified it in the year 2007 (Black, Kass, & Koo, Source Code Security Analysis Tool Functional Specification Version 1.0, 2007). It is restated again by Seacord in the year 2008 (Seacord R. C., The CERT C Secure Coding Standard, 2008). NIST listed again the same vulnerability in their report in the year of 2011 (Black, Kass, Koo, & Fong, Source Code Security Analysis Tool Functional Specification Version 1.1 , 2011). It is also identified and listed by Computer Emergency Response Team (CERT) of Carnegie Mellon University (Seacord R. C., CERT C Secure Coding Standard, 2011), (Pincar & Haas, 2011), (Seacord & Haas, EXP41-C. Do not add or subtract a scaled integer to a pointer, 2011), OWASP (OWASP Organization, 2009) and NIST (NIST, 2012). The vulnerability is known as pointer scaling or mixing whereby it is a vulnerability that trigger by incorrect or invalid use of pointer in an arithmetic operation. It might be because it can be easily confuse between function pointer and pointer scaling in terms of the name and use of pointer. However, the behaviour, syntax and way of exploiting is very different from source code perspective for the two pointer related vulnerabilities. As published by NIST (NIST, 2012), pointer scaling is ranked between medium to critical severity, low complexity, and complete impact on confidentiality, integrity and availability. Hence, it shall not be ignored and should be included in any discussion on C overflows vulnerabilities too. Summarized the discussion
• #31: Also known as buffer overflow/overrun. Unsafe function is more general in definition compared to buffer overflow, buffer overrun or format string attack as it can be unsafe by nature such as printf and scanf and exploiting unsafe function may not involve buffer and it can happen to non-related string formation like strlen. Therefore, the term ‘Unsafe function’ covers wide range of C overflows vulnerabilities as listed by Microsoft. Furthermore, the term is closely related to coding, thus understandable to software developers rather than the other earlier used terms. Therefore, as it was identified by Wagner in 2000 (Wagner D. A., 2000), unsafe functions is identified as the first C overflows vulnerabilities class The hype of the research started from the year 2000 Although we listed 9 classes, the actual classes identified is 6. Others mentioned the behaviour but not the class name. Among these nine classes, the most critical and of high occurrences are the unsafe functions and array out-of-bound. However, despite being ignored by some experts and number of occurrences is not as many compared to the two classes, the other seven classes are significantly important because of their impact and severity are ranked at least medium in many vulnerabilities database website. Beside those identified nine classes of C overflow vulnerabilities, there is one more class that was left out by many security experts or researchers although NIST identified it in the year 2007 (Black, Kass, & Koo, Source Code Security Analysis Tool Functional Specification Version 1.0, 2007). It is restated again by Seacord in the year 2008 (Seacord R. C., The CERT C Secure Coding Standard, 2008). NIST listed again the same vulnerability in their report in the year of 2011 (Black, Kass, Koo, & Fong, Source Code Security Analysis Tool Functional Specification Version 1.1 , 2011). It is also identified and listed by Computer Emergency Response Team (CERT) of Carnegie Mellon University (Seacord R. C., CERT C Secure Coding Standard, 2011), (Pincar & Haas, 2011), (Seacord & Haas, EXP41-C. Do not add or subtract a scaled integer to a pointer, 2011), OWASP (OWASP Organization, 2009) and NIST (NIST, 2012). The vulnerability is known as pointer scaling or mixing whereby it is a vulnerability that trigger by incorrect or invalid use of pointer in an arithmetic operation. It might be because it can be easily confuse between function pointer and pointer scaling in terms of the name and use of pointer. However, the behaviour, syntax and way of exploiting is very different from source code perspective for the two pointer related vulnerabilities. As published by NIST (NIST, 2012), pointer scaling is ranked between medium to critical severity, low complexity, and complete impact on confidentiality, integrity and availability. Hence, it shall not be ignored and should be included in any discussion on C overflows vulnerabilities too. Summarized the discussion
• #32: Program analysis started by Kings in 1970 Static analysis is a method to analyse program without executing the program. It either analyses the actual source code or binary form of the program (Ireland, 2009) and extract the information within for debugging, comprehension or validation process (Binkley, 2007)
• #33: Program analysis started by Kings in 1970 Static analysis is a method to analyse program without executing the program. It either analyses the actual source code or binary form of the program (Ireland, 2009) and extract the information within for debugging, comprehension or validation process (Binkley, 2007)
• #34: In summary works starts as early as 1977 but focus on security starts in 2000 Through out till now, there are about 11 methods and approximate of 40 tools but still C overflow vulnerabilities persist. Although, (Secunia, 2011), (MITRE Corporation, 2012), (Cenzic Inc., 2010), (HewlettPackard, 2011) shows reduction in numbers of C overflow vulnerabilities and SANS ranked it from no 1 to no 3, it is still considered as highly critical and shall not be ignored (Howard, LeBlanc & Viega, 2010) and (Sadeghi, 2011) and the numbers of advisories release are still significantly high (Rusnacko, 2014), (Secunia, 2013), (Trustwave, 2013), (Paul, 2013), (Qualys, 2013) and (Department of Homeland Security, 2013) Took another step in the research to review the methods and tools limitation
• #35: In summary works starts as early as 1977 but focus on security starts in 2000 Through out till now, there are about 11 methods and approximate of 40 tools but still C overflow vulnerabilities persist. Although, (Secunia, 2011), (MITRE Corporation, 2012), (Cenzic Inc., 2010), (HewlettPackard, 2011) shows reduction in numbers of C overflow vulnerabilities and SANS ranked it from no 1 to no 3, it is still considered as highly critical and shall not be ignored (Howard, LeBlanc & Viega, 2010) and (Sadeghi, 2011) and the numbers of advisories release are still significantly high (Rusnacko, 2014), (Secunia, 2013), (Trustwave, 2013), (Paul, 2013), (Qualys, 2013) and (Department of Homeland Security, 2013) Took another step in the research to review the methods and tools limitation
• #36: In summary works starts as early as 1977 but focus on security starts in 2000 Through out till now, there are about 11 methods and approximate of 40 tools but still C overflow vulnerabilities persist. Although, (Secunia, 2011), (MITRE Corporation, 2012), (Cenzic Inc., 2010), (HewlettPackard, 2011) shows reduction in numbers of C overflow vulnerabilities and SANS ranked it from no 1 to no 3, it is still considered as highly critical and shall not be ignored (Howard, LeBlanc & Viega, 2010) and (Sadeghi, 2011) and the numbers of advisories release are still significantly high (Rusnacko, 2014), (Secunia, 2013), (Trustwave, 2013), (Paul, 2013), (Qualys, 2013) and (Department of Homeland Security, 2013) Took another step in the research to review the methods and tools limitation
• #37: In summary works starts as early as 1977 but focus on security starts in 2000 Through out till now, there are about 11 methods and approximate of 40 tools but still C overflow vulnerabilities persist. Although, (Secunia, 2011), (MITRE Corporation, 2012), (Cenzic Inc., 2010), (HewlettPackard, 2011) shows reduction in numbers of C overflow vulnerabilities and SANS ranked it from no 1 to no 3, it is still considered as highly critical and shall not be ignored (Howard, LeBlanc & Viega, 2010) and (Sadeghi, 2011) and the numbers of advisories release are still significantly high (Rusnacko, 2014), (Secunia, 2013), (Trustwave, 2013), (Paul, 2013), (Qualys, 2013) and (Department of Homeland Security, 2013) Took another step in the research to review the methods and tools limitation
• #38: Lexical analysis is the oldest method implemented in compiler (Aho, Lam, Sethi, & Ullman, 1986) and (Kunst, 1988), and grep utility (Viega J. , Bloch, Kohno, & McGraw, 2000), (Deursen & Kuipers, 1999) and (Chess & McGraw, 2004) This method is favored due to its simple straightforward analysis approach. It read stream of token or character and matches with the rules or pattern defined in the program or listed in a database (Sotirov, 2005), (Li & Cui, 2010), (Deursen & Kuipers, 1999), (Viega J. , Bloch, Kohno, & McGraw, 2000), (Zafar & Ali, 2007), (Kolmonen, 2007) and (Chess & McGraw, 2004). Does not require any transformation of code and complex mathematical processes, hence produces faster result (Zafar & Ali, 2007) This simplicity principle is also its greatest weakness. The method ignores semantics and relies on defined pattern or rules (Larochelle & Evans, 2001). Thus, the analysis is limited to the pattern or rules defined and the result is within the boundary of a function (Sotirov, 2005), (Li & Cui, 2010), (Deursen & Kuipers, 1999) and (Zafar & Ali, 2007) Inter-procedural and intra-procedural analysis are two common analysis methods, implemented as its own or combined with other methods to enhance the effectiveness (Qadeer & Rehof, 2005), (Viega J. , Bloch, Kohno, & McGraw, 2002), (Andersen, 1994) and (Pozza & Sisto, 2008). Inter-procedural analysis consider relationship and impact of reference’s variable between functions, therefore, it is slower but more accurate result as compared to intra-procedural analysis (Andersen, 1994). Intra-procedural analysis, although faster, is unreliable due to ignorance on the semantics of the analysed programs (Andersen, 1994) and (Pozza & Sisto, 2008). However, both have common weakness, which both are dependent on other methods to have a sound and complete analysis (Andersen, 1994) and (Pozza & Sisto, 2008). Abstract interpretation in the early implementation by the Cousot’s is for program understanding and debugging purposes (Cousot & Cousot, 1977). The method started implemented in software security area after it was implemented in a static analysis tool named ASTREE (Cousot P. , et al., 2005). The method considered the semantics of a program in its analysis (Erkkinen & Hote, 2006), (Jhala & Majumdar, Software Model Checking, 2009). Hence, no matter how complex the source code is, it will be able to analyse it. However, for that to happen, it requires complex formal method, which involves the abstraction process and mathematical algorithm (D’Silva, Kroening, & Weissenbacher, 2008), (Ferrara, 2010), (Gopan & Reps, 2007), (Ferrara, 2009) and (Logozzo, 2004). Due to this, abstract interpretation suffers scalability issues (Ferrara, Logozzo, & Fanhdrich, 2008) and (Venet, 2005). To overcome the scalability issue, many abstract interpretation implementations ignores some properties in its analysis processes resulted in reducinc analysis scope and accuracy (Ivančić, et al., 2005), (Zaks, et al., 2006), (Balakrishnan, Sankaranarayanan, Ivančić, & Gupta, 2009) and (Burgstaller, Scholz, & Blieberger, 2006). On top of scalability issue, the method also produce non-reliable result due to use of approximation (Burgstaller, Scholz, & Blieberger, 2006). Data flow analysis (DFA) is a semantic-light analysis method. The differences between the method and abstract interpretation is that the latter looks into relationship of each attributes in flow graph whereas the earlier analyse each attributes by following the path of identified attributes. DFA is able to perform precise analysis and locate the exact path of vulnerabilities flow (Kolmonen, 2007) and (Parasoft Corporation, 2009). However, implementation of DFA took longer times for analysis (Pozza & Sisto, 2008). Therefore, to reduce analysis time, the scope of analysis is reduced (Soffa, 2008). This resulted in equivalent issue as abstract interpretation. Symbolic analysis is a method derived to analyze program parallel programming architecture (Bae, 2003) such as kernel-level driver and embedded program. The method semantically converts the program into closest execution form and symbolically represents the form before analysis (Haghighat & Polychronopoulos, 1993), (Ball, et al., 2006), (Bae, 2003), (Lim, Lal, & Reps, 2009) and (Burgstaller, Scholz, & Blieberger, 2006), hence reduce the flow path to be analyse and the time taken is lesser compared to DFA and AI. In addition, the method counter-checks the errors found to reduce false alarm (Ball, et al., 2006) and (Lim, Lal, & Reps, 2009). The problem with this method is, it depends on input data or constructed model in its analysis (Ball, et al., 2006) and (Lim, Lal, & Reps, 2009). Incorrect data prediction or model will result in false alarm (Ball, et al., 2006). Moreover, refinement process may slow down the analysis or causing overhead at implementation. On top of that, the complexity of the algorithm may cause issues during implementation or scope reduction as faces by DFA and AI method. Integer range analysis method is simple mathematical-based method that ignores program relationship Has the ability to analyse complex algorithm (Venet, 2005) An excellent method in detecting string manipulation vulnerabilities such as unsafe functions and array out-of-bound (Dor, Rodeh, & Sagiv, 2001) and (Wagner, Foster, Brewer, & Aiken, 2000). Despite the strength, the technique suffers scalability issues (Venet, 2005) and it failed to analyse program with references, pointer aliasing, or complex inter-procedural functions. The method also failed to determine the array structure correctly (Venet, 2005). Due to ignores program semantics the method suffers many false alarms (Dor, Rodeh, & Sagiv, 2001) and (Wagner, Foster, Brewer, & Aiken, 2000). Annotation based is another simple and light but powerful method (no complex algo) The strength of the method lies in the annotation wrote by developers in the source code (Larochelle & Evans, 2001) which enforce the output based on the annotated rules (Tevis & Hamilton, 2004) and (Pozza & Sisto, 2008). The method is highly dependent on correct syntax of the annotation (Larochelle & Evans, 2001), (Evans, Guttag, Horning, & Tan, 1994) and (Evans & Larochelle, 2002). Incorrect or misinterpretation = false alarms The reluctant of developer to annotate their code as required (Pozza & Sisto, 2008) and (Rinard, Cadar, Dumitran, Roy, & Leu, 2004) contributes to failure too. Type matching is another analysis similar to AI but focuses on certain attributes in a program, which is the variable types. (Ferrara, 2010) and (Wang, Guo, & Chen, 2009) The method understands the variable types, verified and ensures that type of input can be accepted or correctly parses into the recipient variable. For the method to analyze correctly, abstraction of source code must be defined correctly (Ferrara, 2010) and (Wang, Guo, & Chen, 2009). Incorrect abstraction or source code information will result in imprecise analysis. Another problem of the method is limited to type analysis (Sotirov, 2005), which from C overflow vulnerabilities perspective; it is only able to detect variable type conversion and function pointer vulnerabilities. Software model checking and bounded model checking are two analysis methods utilize the model or properties defined for a program. Both share the same strengths. The first strength is the ability to analyse all reachable code based on defined model for variable properties verification (Li & Cui, 2010), (Wenkai, 2002) and (Biere, Cimatti, Clarke, & Strichman, 2003). The second strength is both understand semantically the structure of the source code by abstracting the source code based on defined model into the closest form on runtime execution (Li & Cui, 2010), (Wenkai, 2002), (Biere, Cimatti, Clarke, & Strichman, 2003) and (Jhala & Majumdar, 2009). The third strength of these two methods is the unique counterexample algorithm implemented to reduce false alarm (Clarke E. M., 2006), (Ku, Hart, Chechik, & Lie, 2007) and (Bakera, et al., 2009). Nevertheless, both still has limitation. SMC suffer state explosion issues due to exhaustively traverse every possible path resulted in possibility of infinite traversal especially in loop functions (Wenkai, 2002) and (Clarke, Biere, Raimi, & Zhu, 2001). In order to avoid state explosion, BMC method implements algorithm that reduces the possibility of state explosion (Wenkai, 2002). However, Wenkai only manage to reduce but not eliminate. This also resulting on implementations complication and less sound compared to SMC (Clarke E. M., 2006), (Clarke, Biere, Raimi, & Zhu, 2001) and (Biere, Cimatti, Clarke, & Strichman, 2003). Another weaknesses shared is the implementation of the methods requires understanding of formal method and automaton theory. Due to complications, the methods only focuses on certain C overflow vulnerabilities, hence limits its effectiveness (Holzmann G. J., 2002), (Clarke, Biere, Raimi, & Zhu, 2001) and (Qadeer & Rehof, 2005) There are few more issues related to these 11 methods. These weakness has also impact on the tools that implements the methods.
• #39: Lexical analysis is the oldest method implemented in compiler (Aho, Lam, Sethi, & Ullman, 1986) and (Kunst, 1988), and grep utility (Viega J. , Bloch, Kohno, & McGraw, 2000), (Deursen & Kuipers, 1999) and (Chess & McGraw, 2004) This method is favored due to its simple straightforward analysis approach. It read stream of token or character and matches with the rules or pattern defined in the program or listed in a database (Sotirov, 2005), (Li & Cui, 2010), (Deursen & Kuipers, 1999), (Viega J. , Bloch, Kohno, & McGraw, 2000), (Zafar & Ali, 2007), (Kolmonen, 2007) and (Chess & McGraw, 2004). Does not require any transformation of code and complex mathematical processes, hence produces faster result (Zafar & Ali, 2007) This simplicity principle is also its greatest weakness. The method ignores semantics and relies on defined pattern or rules (Larochelle & Evans, 2001). Thus, the analysis is limited to the pattern or rules defined and the result is within the boundary of a function (Sotirov, 2005), (Li & Cui, 2010), (Deursen & Kuipers, 1999) and (Zafar & Ali, 2007) Inter-procedural and intra-procedural analysis are two common analysis methods, implemented as its own or combined with other methods to enhance the effectiveness (Qadeer & Rehof, 2005), (Viega J. , Bloch, Kohno, & McGraw, 2002), (Andersen, 1994) and (Pozza & Sisto, 2008). Inter-procedural analysis consider relationship and impact of reference’s variable between functions, therefore, it is slower but more accurate result as compared to intra-procedural analysis (Andersen, 1994). Intra-procedural analysis, although faster, is unreliable due to ignorance on the semantics of the analysed programs (Andersen, 1994) and (Pozza & Sisto, 2008). However, both have common weakness, which both are dependent on other methods to have a sound and complete analysis (Andersen, 1994) and (Pozza & Sisto, 2008). Abstract interpretation in the early implementation by the Cousot’s is for program understanding and debugging purposes (Cousot & Cousot, 1977). The method started implemented in software security area after it was implemented in a static analysis tool named ASTREE (Cousot P. , et al., 2005). The method considered the semantics of a program in its analysis (Erkkinen & Hote, 2006), (Jhala & Majumdar, Software Model Checking, 2009). Hence, no matter how complex the source code is, it will be able to analyse it. However, for that to happen, it requires complex formal method, which involves the abstraction process and mathematical algorithm (D’Silva, Kroening, & Weissenbacher, 2008), (Ferrara, 2010), (Gopan & Reps, 2007), (Ferrara, 2009) and (Logozzo, 2004). Due to this, abstract interpretation suffers scalability issues (Ferrara, Logozzo, & Fanhdrich, 2008) and (Venet, 2005). To overcome the scalability issue, many abstract interpretation implementations ignores some properties in its analysis processes resulted in reducinc analysis scope and accuracy (Ivančić, et al., 2005), (Zaks, et al., 2006), (Balakrishnan, Sankaranarayanan, Ivančić, & Gupta, 2009) and (Burgstaller, Scholz, & Blieberger, 2006). On top of scalability issue, the method also produce non-reliable result due to use of approximation (Burgstaller, Scholz, & Blieberger, 2006). Data flow analysis (DFA) is a semantic-light analysis method. The differences between the method and abstract interpretation is that the latter looks into relationship of each attributes in flow graph whereas the earlier analyse each attributes by following the path of identified attributes. DFA is able to perform precise analysis and locate the exact path of vulnerabilities flow (Kolmonen, 2007) and (Parasoft Corporation, 2009). However, implementation of DFA took longer times for analysis (Pozza & Sisto, 2008). Therefore, to reduce analysis time, the scope of analysis is reduced (Soffa, 2008). This resulted in equivalent issue as abstract interpretation. Symbolic analysis is a method derived to analyze program parallel programming architecture (Bae, 2003) such as kernel-level driver and embedded program. The method semantically converts the program into closest execution form and symbolically represents the form before analysis (Haghighat & Polychronopoulos, 1993), (Ball, et al., 2006), (Bae, 2003), (Lim, Lal, & Reps, 2009) and (Burgstaller, Scholz, & Blieberger, 2006), hence reduce the flow path to be analyse and the time taken is lesser compared to DFA and AI. In addition, the method counter-checks the errors found to reduce false alarm (Ball, et al., 2006) and (Lim, Lal, & Reps, 2009). The problem with this method is, it depends on input data or constructed model in its analysis (Ball, et al., 2006) and (Lim, Lal, & Reps, 2009). Incorrect data prediction or model will result in false alarm (Ball, et al., 2006). Moreover, refinement process may slow down the analysis or causing overhead at implementation. On top of that, the complexity of the algorithm may cause issues during implementation or scope reduction as faces by DFA and AI method. Integer range analysis method is simple mathematical-based method that ignores program relationship Has the ability to analyse complex algorithm (Venet, 2005) An excellent method in detecting string manipulation vulnerabilities such as unsafe functions and array out-of-bound (Dor, Rodeh, & Sagiv, 2001) and (Wagner, Foster, Brewer, & Aiken, 2000). Despite the strength, the technique suffers scalability issues (Venet, 2005) and it failed to analyse program with references, pointer aliasing, or complex inter-procedural functions. The method also failed to determine the array structure correctly (Venet, 2005). Due to ignores program semantics the method suffers many false alarms (Dor, Rodeh, & Sagiv, 2001) and (Wagner, Foster, Brewer, & Aiken, 2000). Annotation based is another simple and light but powerful method (no complex algo) The strength of the method lies in the annotation wrote by developers in the source code (Larochelle & Evans, 2001) which enforce the output based on the annotated rules (Tevis & Hamilton, 2004) and (Pozza & Sisto, 2008). The method is highly dependent on correct syntax of the annotation (Larochelle & Evans, 2001), (Evans, Guttag, Horning, & Tan, 1994) and (Evans & Larochelle, 2002). Incorrect or misinterpretation = false alarms The reluctant of developer to annotate their code as required (Pozza & Sisto, 2008) and (Rinard, Cadar, Dumitran, Roy, & Leu, 2004) contributes to failure too. Type matching is another analysis similar to AI but focuses on certain attributes in a program, which is the variable types. (Ferrara, 2010) and (Wang, Guo, & Chen, 2009) The method understands the variable types, verified and ensures that type of input can be accepted or correctly parses into the recipient variable. For the method to analyze correctly, abstraction of source code must be defined correctly (Ferrara, 2010) and (Wang, Guo, & Chen, 2009). Incorrect abstraction or source code information will result in imprecise analysis. Another problem of the method is limited to type analysis (Sotirov, 2005), which from C overflow vulnerabilities perspective; it is only able to detect variable type conversion and function pointer vulnerabilities. Software model checking and bounded model checking are two analysis methods utilize the model or properties defined for a program. Both share the same strengths. The first strength is the ability to analyse all reachable code based on defined model for variable properties verification (Li & Cui, 2010), (Wenkai, 2002) and (Biere, Cimatti, Clarke, & Strichman, 2003). The second strength is both understand semantically the structure of the source code by abstracting the source code based on defined model into the closest form on runtime execution (Li & Cui, 2010), (Wenkai, 2002), (Biere, Cimatti, Clarke, & Strichman, 2003) and (Jhala & Majumdar, 2009). The third strength of these two methods is the unique counterexample algorithm implemented to reduce false alarm (Clarke E. M., 2006), (Ku, Hart, Chechik, & Lie, 2007) and (Bakera, et al., 2009). Nevertheless, both still has limitation. SMC suffer state explosion issues due to exhaustively traverse every possible path resulted in possibility of infinite traversal especially in loop functions (Wenkai, 2002) and (Clarke, Biere, Raimi, & Zhu, 2001). In order to avoid state explosion, BMC method implements algorithm that reduces the possibility of state explosion (Wenkai, 2002). However, Wenkai only manage to reduce but not eliminate. This also resulting on implementations complication and less sound compared to SMC (Clarke E. M., 2006), (Clarke, Biere, Raimi, & Zhu, 2001) and (Biere, Cimatti, Clarke, & Strichman, 2003). Another weaknesses shared is the implementation of the methods requires understanding of formal method and automaton theory. Due to complications, the methods only focuses on certain C overflow vulnerabilities, hence limits its effectiveness (Holzmann G. J., 2002), (Clarke, Biere, Raimi, & Zhu, 2001) and (Qadeer & Rehof, 2005) There are few more issues related to these 11 methods. These weakness has also impact on the tools that implements the methods.
• #40: FlawFinder and RATS is two examples of lexical analysis tools and is continuously improved with latest version released in the year of 2007 (FlawFinder) and 2011 (RATS). FlawFinder produces analysis with high false alarms and limited to unsafe functions vulnerabilities (Sotirov, 2005). However, to compliment the limitation, FlawFinder highlight risk level of identified vulnerabilities, which determine the significant and reduce the time to evaluate the severity of the identified vulnerabilities but the limitation still remains (Wheeler, 2007) RATS is another lexical analysis based tool (Zafar & Ali, 2007) that inherit the same limitation as other tools implementing the method (Kolmonen, 2007) and (Tevis & Hamilton, 2004). The tools differentiate the overflow locations; heap or stack (Viega J. , Bloch, Kohno, & McGraw, 2002). Database of RATS is more extensive (HP Fortify, 2011) and (Viega J. , Bloch, Kohno, & McGraw, 2002) compared to others lexical analysis tool. Nevertheless, HP notified that the weaknesses (high false alarms and limited vulnerabilities) remains (HP Fortify, 2011). BOON uses IRA and effective and efficient in detecting vulnerabilities that has possibility to overflow due to manipulation of lower or upper bound (Chess & McGraw, 2004) and (Kolmonen, 2007). BOON does not dependent on list or database, hence does not limit to unsafe function (Tevis & Hamilton, 2004) However, due to IRA method, the tool still generate false alarms and limited to C overflow vulnerabilities, of which bounds can be measured (Zitser, Lippmann, & Leek, 2004), (Xie, Chou, & Engler, 2003) and (Sotirov, 2005). ARCHER is claim by its inventor (Cousots) as one of promising tools. The tool in general, uses symbolic analysis method and understands the structures of a program, thus is able to precisely detect vulnerabilities (Lim, Lal, & Reps, 2011) and (Pozza & Sisto, 2008) and able to analyse large source code (Xie, Chou, & Engler, 2003). The problem with the tool is it need to completely and accurately convert programs into symbolic model and this is still unresolved issue causing less effectiveness in detecting vulnerabilities (Lim, Lal, & Reps, 2011), (Kolmonen, 2007), (Zitser, Lippmann, & Leek, 2004). Moreover, the tool only published vulnerabilities that are proven to be vulnerable. Therefore, there is possibility to trigger false positive for vulnerabilities that cannot be proven by the tool (Zitser, Lippmann, & Leek, 2004) and (Xie, Chou, & Engler, 2003). MOPS is another tool claimed to be a promising tool in detecting vulnerabilities (Chess & McGraw, 2004), (Tevis & Hamilton, 2004) and (Kolmonen, 2007). MOPS does not focuses on any specific C overflow vulnerabilities; instead it can be used to find any types of vulnerabilities and programming errors depending on model created (Chess & McGraw, 2004), (Tevis & Hamilton, 2004), (Kolmonen, 2007) and (Sotirov, 2005) A difficulty in modelling the exact execution path and complexity in building the model especially for a complex source code has causes the tool to be less effective and efficient (Engler & Musuvathi, 2004). The time taken to build the model has also contributed to the reluctant of security analyst in using the tool (Engler & Musuvathi, 2004). Additionally, incorrect modelling due to source code complexity has the possibility of producing false alarm (Engler & Musuvathi, 2004). There are many more tools and to go each tools in detail will be time consume. As shown on the slide, we have review many tools by critically review many previous works as shown on the list of references. The conclusion here is that, until today, there are no tools that can successfully detect all available C overflow vulnerabilities classes.
• #41: FlawFinder and RATS is two examples of lexical analysis tools and is continuously improved with latest version released in the year of 2007 (FlawFinder) and 2011 (RATS). FlawFinder produces analysis with high false alarms and limited to unsafe functions vulnerabilities (Sotirov, 2005). However, to compliment the limitation, FlawFinder highlight risk level of identified vulnerabilities, which determine the significant and reduce the time to evaluate the severity of the identified vulnerabilities but the limitation still remains (Wheeler, 2007) RATS is another lexical analysis based tool (Zafar & Ali, 2007) that inherit the same limitation as other tools implementing the method (Kolmonen, 2007) and (Tevis & Hamilton, 2004). The tools differentiate the overflow locations; heap or stack (Viega J. , Bloch, Kohno, & McGraw, 2002). Database of RATS is more extensive (HP Fortify, 2011) and (Viega J. , Bloch, Kohno, & McGraw, 2002) compared to others lexical analysis tool. Nevertheless, HP notified that the weaknesses (high false alarms and limited vulnerabilities) remains (HP Fortify, 2011). BOON uses IRA and effective and efficient in detecting vulnerabilities that has possibility to overflow due to manipulation of lower or upper bound (Chess & McGraw, 2004) and (Kolmonen, 2007). BOON does not dependent on list or database, hence does not limit to unsafe function (Tevis & Hamilton, 2004) However, due to IRA method, the tool still generate false alarms and limited to C overflow vulnerabilities, of which bounds can be measured (Zitser, Lippmann, & Leek, 2004), (Xie, Chou, & Engler, 2003) and (Sotirov, 2005). ARCHER is claim by its inventor (Cousots) as one of promising tools. The tool in general, uses symbolic analysis method and understands the structures of a program, thus is able to precisely detect vulnerabilities (Lim, Lal, & Reps, 2011) and (Pozza & Sisto, 2008) and able to analyse large source code (Xie, Chou, & Engler, 2003). The problem with the tool is it need to completely and accurately convert programs into symbolic model and this is still unresolved issue causing less effectiveness in detecting vulnerabilities (Lim, Lal, & Reps, 2011), (Kolmonen, 2007), (Zitser, Lippmann, & Leek, 2004). Moreover, the tool only published vulnerabilities that are proven to be vulnerable. Therefore, there is possibility to trigger false positive for vulnerabilities that cannot be proven by the tool (Zitser, Lippmann, & Leek, 2004) and (Xie, Chou, & Engler, 2003). MOPS is another tool claimed to be a promising tool in detecting vulnerabilities (Chess & McGraw, 2004), (Tevis & Hamilton, 2004) and (Kolmonen, 2007). MOPS does not focuses on any specific C overflow vulnerabilities; instead it can be used to find any types of vulnerabilities and programming errors depending on model created (Chess & McGraw, 2004), (Tevis & Hamilton, 2004), (Kolmonen, 2007) and (Sotirov, 2005) A difficulty in modelling the exact execution path and complexity in building the model especially for a complex source code has causes the tool to be less effective and efficient (Engler & Musuvathi, 2004). The time taken to build the model has also contributed to the reluctant of security analyst in using the tool (Engler & Musuvathi, 2004). Additionally, incorrect modelling due to source code complexity has the possibility of producing false alarm (Engler & Musuvathi, 2004). There are many more tools and to go each tools in detail will be time consume. As shown on the slide, we have review many tools by critically review many previous works as shown on the list of references. The conclusion here is that, until today, there are no tools that can successfully detect all available C overflow vulnerabilities classes.
• #43: Dynamic analysis has gain popularity due to ineffectiveness and inefficiencies of static analysis tools. However, despite lots of promising, dynamic analysis is yet to prevail. Since the methods used is also the same method as static analysis, the review done here focuses on tools effectiveness. This unique problem of dynamic analysis has highly influencing the performance of analysed program as it decreased the analysed program processing speed and hence not suitable for large-scale program such as web server or database server. This happens when dynamic analysis tools continue to terminate and or restart affected process after an overflow is detected.
• #44: Dynamic analysis has gain popularity due to ineffectiveness and inefficiencies of static analysis tools. However, despite lots of promising, dynamic analysis is yet to prevail. Since the methods used is also the same method as static analysis, the review done here focuses on tools effectiveness. This unique problem of dynamic analysis has highly influencing the performance of analysed program as it decreased the analysed program processing speed and hence not suitable for large-scale program such as web server or database server. This happens when dynamic analysis tools continue to terminate and or restart affected process after an overflow is detected.
• #45: Consequently, changing codes at development stage is easier and less hassle compare to after the complete system is ready, and the code becomes complicated. The cost of changing code after deployment is more than 100 times higher compare to code modification at development stage (Shapiro, 2008) and (Graham, Leroux, & Landry, 2008). This is due to more times needed to find the root cause of the overflows, redesign and restructure the codes and finally to redo the necessary test for the fixed code (Parasoft Corporation, 2009). Furthermore, it required involvement of many persons such as software architecture, project manager, software developers and tester. Static analysis, in contrast, can be done at developer’s machine and only required developers to change the code if found vulnerable without the need of troubleshooting, redesign of software architectures and other hassle process. Microsoft preferred to use static analysis rather than dynamic analysis as their proactive measurements whereby they include static analysis as part of development process and introduce Security Development Lifecycle (SDL). There are three ways that requires extensive works as there are still gaps in them.
• #46: From the studies done and described in previous few sections, one consistent gap shared across static and dynamic analysis is the coverage of C overflow vulnerabilities classes. All analysis methods are found to focus on certain classes of C overflow vulnerabilities. This is either due to the knowledge on the variety of C overflow vulnerabilities is limited, ignorance of software developer to understand or write secure coding, or rely too much on tool. Therefore, there is a need to further understand and improve the knowledge on C overflow vulnerabilities. Vulnerabilities understanding is the process of educating and building the knowledge on vulnerabilities that helps security community to understand vulnerabilities and hence be able to utilize the information to further improve analysis methods and tools, and/or security implementation (Krsul, 1998). One of the way is using taxonomy or classifications. To study taxonomy and classifications, we cannot simply ignore the criteria behind a well-defined taxonomy, hence, it is also reviewed in this
• #47: Although their criteria has gaps, they continue to construct taxonomy or classifications using the criteria as the guidelines. Our next review will provide evidences that they did not construct well-defined taxonomy or classifications that meet their own criteria.
• #48: Although their criteria has gaps, they continue to construct taxonomy or classifications using the criteria as the guidelines. Our next review will provide evidences that they did not construct well-defined taxonomy or classifications that meet their own criteria.
• #49: 1. Our review covers software vulnerabilities taxonomy and it is divided into general software vulnerabilities taxonomy and specifics to C overflow vulnerabilities taxonomy. The first table shown here focus on general software vulnerabilities taxonomy.
• #50: 1. Our review covers software vulnerabilities taxonomy and it is divided into general software vulnerabilities taxonomy and specifics to C overflow vulnerabilities taxonomy. The first table shown here focus on general software vulnerabilities taxonomy.
• #52: Between many software vulnerabilities, C overflow vulnerabilities is regarded as the most critical with the highest probability of being exploited due to its persistency and CSSV scores from various well-known organizations and well-established online vulnerability database websites. For that reason, having a well-defined taxonomy is significant towards having a good solutions to resolve issue concerning C overflow vulnerabilities
• #53: Between many software vulnerabilities, C overflow vulnerabilities is regarded as the most critical with the highest probability of being exploited due to its persistency and CSSV scores from various well-known organizations and well-established online vulnerability database websites. For that reason, having a well-defined taxonomy is significant towards having a good solutions to resolve issue concerning C overflow vulnerabilities
• #54: Between many software vulnerabilities, C overflow vulnerabilities is regarded as the most critical with the highest probability of being exploited due to its persistency and CSSV scores from various well-known organizations and well-established online vulnerability database websites. For that reason, having a well-defined taxonomy is significant towards having a good solutions to resolve issue concerning C overflow vulnerabilities
• #56: The first phase starts with detailed literature review done on the three identified key areas resulted from pre-analysis of vulnerabilities as defined by Kaspersky (Kaspersky Lab ZAO, 2013) and MITRE (OWASP Organization, 2011), various exploitation cases such as in Poland (Baker & Graeme, 2008) and Iran (Chen T. M., 2010) and the Toyota break failure case (Carty, 2010). The second phase starts with comprehensive review on various taxonomy criteria discussed by many experts such as Killourhy et. al (Killourhy, Maxion, & Tan, 2004), Hansmann (Hansmann & Hunt, 2005), Krsul (Krsul, 1998), and Howard and Longstaff (Howard & Longstaff, 1998). In line with this significant review, the criteria for well-defined taxonomy is identified and formulated. On top of the publications, various reports/advisories from Microsoft (Microsoft Corporation, 2011), MITRE (MITRE Corporation, 2012), Dept of Homeland Security (Dept of Homeland Security, 2011), Kaspersky (Kaspersky Lab ZAO, 2013), IBM (IBM X-Force, 2011) and HP (HewlettPackard, 2011) is used. Finally, the last phase evaluate the taxonomy and implements the taxonomy to evaluate static analysis tools.
• #57: The first phase starts with detailed literature review done on the three identified key areas resulted from pre-analysis of vulnerabilities as defined by Kaspersky (Kaspersky Lab ZAO, 2013) and MITRE (OWASP Organization, 2011), various exploitation cases such as in Poland (Baker & Graeme, 2008) and Iran (Chen T. M., 2010) and the Toyota break failure case (Carty, 2010). The second phase starts with comprehensive review on various taxonomy criteria discussed by many experts such as Killourhy et. al (Killourhy, Maxion, & Tan, 2004), Hansmann (Hansmann & Hunt, 2005), Krsul (Krsul, 1998), and Howard and Longstaff (Howard & Longstaff, 1998). In line with this significant review, the criteria for well-defined taxonomy is identified and formulated. On top of the publications, various reports/advisories from Microsoft (Microsoft Corporation, 2011), MITRE (MITRE Corporation, 2012), Dept of Homeland Security (Dept of Homeland Security, 2011), Kaspersky (Kaspersky Lab ZAO, 2013), IBM (IBM X-Force, 2011) and HP (HewlettPackard, 2011) is used. Finally, the last phase evaluate the taxonomy and implements the taxonomy to evaluate static analysis tools.
• #58: The first phase starts with detailed literature review done on the three identified key areas resulted from pre-analysis of vulnerabilities as defined by Kaspersky (Kaspersky Lab ZAO, 2013) and MITRE (OWASP Organization, 2011), various exploitation cases such as in Poland (Baker & Graeme, 2008) and Iran (Chen T. M., 2010) and the Toyota break failure case (Carty, 2010). The second phase starts with comprehensive review on various taxonomy criteria discussed by many experts such as Killourhy et. al (Killourhy, Maxion, & Tan, 2004), Hansmann (Hansmann & Hunt, 2005), Krsul (Krsul, 1998), and Howard and Longstaff (Howard & Longstaff, 1998). In line with this significant review, the criteria for well-defined taxonomy is identified and formulated. On top of the publications, various reports/advisories from Microsoft (Microsoft Corporation, 2011), MITRE (MITRE Corporation, 2012), Dept of Homeland Security (Dept of Homeland Security, 2011), Kaspersky (Kaspersky Lab ZAO, 2013), IBM (IBM X-Force, 2011) and HP (HewlettPackard, 2011) is used. Finally, the last phase evaluate the taxonomy and implements the taxonomy to evaluate static analysis tools.
• #59: Theoretical studies Review on vulnerabilities in general and starts by referring reports from well-known organization The following criteria are used to determine the organization credibility. Well-known to information security community and referred by many experts. Number of evidence collected or frequent release of reports or advisories. Vulnerability listing is up-to-date. Use the criteria -> the are few organizations identified -> Symantec, IBM, HP, Microsoft, NIST, MITRE, Homeland Security, Secunia, Oracle, SANS Institute, Cenzic, CSM and Kaspersky. From each organization -> at least 1 reports between the year 1990 to 2010 is reviewed (priority is latest) Books and publications from expert is reviewed too -> Bisbey et. al. (Bisbey & Hollingworth, 1978), Binkley (Binkley, 2007), Chess et. al. (Chess & McGraw, 2004), (Howard, LeBlanc, & Viega, 24 Deadly Sins of Software Security - Programming Flaws and How to Fix Them, 2010), and Viega et. al. (Viega & McGraw, Building Secure Software: How to Avoid Security Problems the Right Way, 2002). Continues with software vulnerabilities after identified it earlier Using various keywords such as buffer overrun, heap overflow, etc Focus on reports between 2000 – 2010 Further separated to language categories, identified the relevancies and significances by measuring the CVSS Upon identified C overflow vulnerabilities, review in-depth Carefully selected the online vulnerabilities database -> OWASP, NIST, OSVDB, Secunia, Microsoft Review an average of 5 reports per year from 2010 to five years before Each reports -> identified the root cause, class of overflow, year, criticality, exploitation how to and impact Further review on the defensive and preventive mechanism -> static analysis tools and method The review continues with in-depth studies on vulnerabilities taxonomy as we agreed with Krsul and Tsipenyuk (and others) that understanding on vulnerabilities is crucial for further defending and protecting from exploitation on the vulnerabilities. Taxonomy Construction Two critical activities in this phase -> identified and develop/formulae the criteria for well-defined taxonomy and construction of C overflow vulnerabilities exploit taxonomy Criteria for well-defined taxonomy Focus on related reports and publications especially papers published by well-known publisher (IEEE & Springer) -> covers papers that specifies, criticize or compliments criterions Shortlisted criterions is then reviewed -> focus on characteristics and meaning of the criterions. The final list is then published for expert review Construction of the taxonomy The idea -> construct from source-code perspective and focus on exploits methods Studies the previously collected evidences (reports, papers, etc) -> focus on vulnerability behaviour, characteristics on exploit, severity and impact. The identify vulnerabilities are then classified together based on common shared characteristics/behaviour using name are known to community The taxonomy is also published for feedback and comments
• #60: Theoretical studies Review on vulnerabilities in general and starts by referring reports from well-known organization The following criteria are used to determine the organization credibility. Well-known to information security community and referred by many experts. Number of evidence collected or frequent release of reports or advisories. Vulnerability listing is up-to-date. Use the criteria -> the are few organizations identified -> Symantec, IBM, HP, Microsoft, NIST, MITRE, Homeland Security, Secunia, Oracle, SANS Institute, Cenzic, CSM and Kaspersky. From each organization -> at least 1 reports between the year 1990 to 2010 is reviewed (priority is latest) Books and publications from expert is reviewed too -> Bisbey et. al. (Bisbey & Hollingworth, 1978), Binkley (Binkley, 2007), Chess et. al. (Chess & McGraw, 2004), (Howard, LeBlanc, & Viega, 24 Deadly Sins of Software Security - Programming Flaws and How to Fix Them, 2010), and Viega et. al. (Viega & McGraw, Building Secure Software: How to Avoid Security Problems the Right Way, 2002). Continues with software vulnerabilities after identified it earlier Using various keywords such as buffer overrun, heap overflow, etc Focus on reports between 2000 – 2010 Further separated to language categories, identified the relevancies and significances by measuring the CVSS Upon identified C overflow vulnerabilities, review in-depth Carefully selected the online vulnerabilities database -> OWASP, NIST, OSVDB, Secunia, Microsoft Review an average of 5 reports per year from 2010 to five years before Each reports -> identified the root cause, class of overflow, year, criticality, exploitation how to and impact Further review on the defensive and preventive mechanism -> static analysis tools and method The review continues with in-depth studies on vulnerabilities taxonomy as we agreed with Krsul and Tsipenyuk (and others) that understanding on vulnerabilities is crucial for further defending and protecting from exploitation on the vulnerabilities. Taxonomy Construction Two critical activities in this phase -> identified and develop/formulae the criteria for well-defined taxonomy and construction of C overflow vulnerabilities exploit taxonomy Criteria for well-defined taxonomy Focus on related reports and publications especially papers published by well-known publisher (IEEE & Springer) -> covers papers that specifies, criticize or compliments criterions Shortlisted criterions is then reviewed -> focus on characteristics and meaning of the criterions. The final list is then published for expert review Construction of the taxonomy The idea -> construct from source-code perspective and focus on exploits methods Studies the previously collected evidences (reports, papers, etc) -> focus on vulnerability behaviour, characteristics on exploit, severity and impact. The identify vulnerabilities are then classified together based on common shared characteristics/behaviour using name are known to community The taxonomy is also published for feedback and comments
• #61: Theoretical studies Review on vulnerabilities in general and starts by referring reports from well-known organization The following criteria are used to determine the organization credibility. Well-known to information security community and referred by many experts. Number of evidence collected or frequent release of reports or advisories. Vulnerability listing is up-to-date. Use the criteria -> the are few organizations identified -> Symantec, IBM, HP, Microsoft, NIST, MITRE, Homeland Security, Secunia, Oracle, SANS Institute, Cenzic, CSM and Kaspersky. From each organization -> at least 1 reports between the year 1990 to 2010 is reviewed (priority is latest) Books and publications from expert is reviewed too -> Bisbey et. al. (Bisbey & Hollingworth, 1978), Binkley (Binkley, 2007), Chess et. al. (Chess & McGraw, 2004), (Howard, LeBlanc, & Viega, 24 Deadly Sins of Software Security - Programming Flaws and How to Fix Them, 2010), and Viega et. al. (Viega & McGraw, Building Secure Software: How to Avoid Security Problems the Right Way, 2002). Continues with software vulnerabilities after identified it earlier Using various keywords such as buffer overrun, heap overflow, etc Focus on reports between 2000 – 2010 Further separated to language categories, identified the relevancies and significances by measuring the CVSS Upon identified C overflow vulnerabilities, review in-depth Carefully selected the online vulnerabilities database -> OWASP, NIST, OSVDB, Secunia, Microsoft Review an average of 5 reports per year from 2010 to five years before Each reports -> identified the root cause, class of overflow, year, criticality, exploitation how to and impact Further review on the defensive and preventive mechanism -> static analysis tools and method The review continues with in-depth studies on vulnerabilities taxonomy as we agreed with Krsul and Tsipenyuk (and others) that understanding on vulnerabilities is crucial for further defending and protecting from exploitation on the vulnerabilities. Taxonomy Construction Two critical activities in this phase -> identified and develop/formulae the criteria for well-defined taxonomy and construction of C overflow vulnerabilities exploit taxonomy Criteria for well-defined taxonomy Focus on related reports and publications especially papers published by well-known publisher (IEEE & Springer) -> covers papers that specifies, criticize or compliments criterions Shortlisted criterions is then reviewed -> focus on characteristics and meaning of the criterions. The final list is then published for expert review Construction of the taxonomy The idea -> construct from source-code perspective and focus on exploits methods Studies the previously collected evidences (reports, papers, etc) -> focus on vulnerability behaviour, characteristics on exploit, severity and impact. The identify vulnerabilities are then classified together based on common shared characteristics/behaviour using name are known to community The taxonomy is also published for feedback and comments
• #62: The objective of the evaluation: To measure the effectiveness and completeness of the taxonomy To measure severity, persistency and relevancies of each classes. Indirectly measure completeness and knowledge compliant of the taxonomy and shows how useful the taxonomy is by measuring To measure the effectiveness and efficiencies of static analysis tools Uniqueness of the evaluation is that there is no methods or approaches to evaluate a taxonomy especially against well-defined criteria done before. The first evaluation is evaluation on taxonomy against the well-defined criteria Measurement on Effectiveness and Completeness The criteria used to select tester are: Good understanding and knowledge in information security and familiar with exploitation and vulnerabilities terms. At least two years experiences in the area of information security. Know and experiences C programming language Taxonomy Evaluation with Selected Well-known Online Vulnerability Database and Organization Using the same set of sites and organization but limit to 7 most relevant The keyword used is the class name or its synonym If a report or advisory found, critical review is done to validate the class name, behaviour and characteristics Evaluation on the Significances and Relevancies of Classes Defined in the Taxonomy of C Overflow Vulnerabilities Exploit To measure on the significances and relevancies of each class defined in the taxonomy to current and future computer system security based on its current severity, impact and persistency. Indirectly indicates the correctness of position the class hierarchy and applicability in the taxonomy Used NIST, OWASP and OSVDB + Microsoft, Symantec, Secunia and Dept of Homeland Security. Numbers of advisories or reports reviewed from each sites are set to 50 maximum. Keyword + synonyms used -> unsafe function, integer range, integer overflow, memory overflow, heap overflow, buffer overflow, buffer overrun, memory overrun, pointer mixing, pointer scaling, out-of-bound, array out-of-bound, null termination, uninitialized variable and heap overrun Evaluation on Significant and Relevancies of C Overflow Vulnerabilities Classes and Impact to OS Criticality To ensure that the classes is relevant and significance to security community Steps 1 – evaluate probability to appear in the OS: Identify the OS based on market shares site (Awio Web Services LLC, 2014), (StatCounter, 2014) and (Net Applications.com, 2014) XP 32 bits, 7 32 and 64 bits and Linux 32 bits (Centos 5.5) Installed on Computers – Intel Pentium Core 2 Duo 2.2Ghz, 4GB RAM, 1TB harddisk, Gigabyte Motherboard Develop simple programs – at least 2 programs for each classes – Inter and Intra-procedural Run 3 times daily and reboot for each OS Steps 2 – Based on collected reports/advisories The CVSS - focus on severity and impact value The mean/average of the severity and impact is calculated for each class. Evaluate the static analysis tools effectiveness in detecting the identified classes Using the same develop programs and limited to windows 7 64-bits Select tools based on availability, full features available (not trial), be able to run on Windows OS Limit to 5 - SPLINT, RATS, ITS4, BOON, and BLAST Measure the time taken, number of detection, false alarm and true alarm. Evaluate the Static Analysis Tools Efficiencies in Analysing Open-source Code for Comparison with Previous Works Selected open source applications -> criteria: application and source code available and used by community. Identify – Apache HTTPD, Chrome, MySQL CE, Open VM Tool, TPM Emulator Measure the time, number of detection and false alarm are collected
• #63: The objective of the evaluation: To measure the effectiveness and completeness of the taxonomy To measure severity, persistency and relevancies of each classes. Indirectly measure completeness and knowledge compliant of the taxonomy and shows how useful the taxonomy is by measuring To measure the effectiveness and efficiencies of static analysis tools Uniqueness of the evaluation is that there is no methods or approaches to evaluate a taxonomy especially against well-defined criteria done before. The first evaluation is evaluation on taxonomy against the well-defined criteria Measurement on Effectiveness and Completeness The criteria used to select tester are: Good understanding and knowledge in information security and familiar with exploitation and vulnerabilities terms. At least two years experiences in the area of information security. Know and experiences C programming language Taxonomy Evaluation with Selected Well-known Online Vulnerability Database and Organization Using the same set of sites and organization but limit to 7 most relevant The keyword used is the class name or its synonym If a report or advisory found, critical review is done to validate the class name, behaviour and characteristics Evaluation on the Significances and Relevancies of Classes Defined in the Taxonomy of C Overflow Vulnerabilities Exploit To measure on the significances and relevancies of each class defined in the taxonomy to current and future computer system security based on its current severity, impact and persistency. Indirectly indicates the correctness of position the class hierarchy and applicability in the taxonomy Used NIST, OWASP and OSVDB + Microsoft, Symantec, Secunia and Dept of Homeland Security. Numbers of advisories or reports reviewed from each sites are set to 50 maximum. Keyword + synonyms used -> unsafe function, integer range, integer overflow, memory overflow, heap overflow, buffer overflow, buffer overrun, memory overrun, pointer mixing, pointer scaling, out-of-bound, array out-of-bound, null termination, uninitialized variable and heap overrun Evaluation on Significant and Relevancies of C Overflow Vulnerabilities Classes and Impact to OS Criticality To ensure that the classes is relevant and significance to security community Steps 1 – evaluate probability to appear in the OS: Identify the OS based on market shares site (Awio Web Services LLC, 2014), (StatCounter, 2014) and (Net Applications.com, 2014) XP 32 bits, 7 32 and 64 bits and Linux 32 bits (Centos 5.5) Installed on Computers – Intel Pentium Core 2 Duo 2.2Ghz, 4GB RAM, 1TB harddisk, Gigabyte Motherboard Develop simple programs – at least 2 programs for each classes – Inter and Intra-procedural Run 3 times daily and reboot for each OS Steps 2 – Based on collected reports/advisories The CVSS - focus on severity and impact value The mean/average of the severity and impact is calculated for each class. Evaluate the static analysis tools effectiveness in detecting the identified classes Using the same develop programs and limited to windows 7 64-bits Select tools based on availability, full features available (not trial), be able to run on Windows OS Limit to 5 - SPLINT, RATS, ITS4, BOON, and BLAST Measure the time taken, number of detection, false alarm and true alarm. Evaluate the Static Analysis Tools Efficiencies in Analysing Open-source Code for Comparison with Previous Works Selected open source applications -> criteria: application and source code available and used by community. Identify – Apache HTTPD, Chrome, MySQL CE, Open VM Tool, TPM Emulator Measure the time, number of detection and false alarm are collected
• #64: Theoretical studies Review on vulnerabilities in general and starts by referring reports from well-known organization The following criteria are used to determine the organization credibility. Well-known to information security community and referred by many experts. Number of evidence collected or frequent release of reports or advisories. Vulnerability listing is up-to-date. Use the criteria -> the are few organizations identified -> Symantec, IBM, HP, Microsoft, NIST, MITRE, Homeland Security, Secunia, Oracle, SANS Institute, Cenzic, CSM and Kaspersky. From each organization -> at least 1 reports between the year 1990 to 2010 is reviewed (priority is latest) Books and publications from expert is reviewed too -> Bisbey et. al. (Bisbey & Hollingworth, 1978), Binkley (Binkley, 2007), Chess et. al. (Chess & McGraw, 2004), (Howard, LeBlanc, & Viega, 24 Deadly Sins of Software Security - Programming Flaws and How to Fix Them, 2010), and Viega et. al. (Viega & McGraw, Building Secure Software: How to Avoid Security Problems the Right Way, 2002). Continues with software vulnerabilities after identified it earlier Using various keywords such as buffer overrun, heap overflow, etc Focus on reports between 2000 – 2010 Further separated to language categories, identified the relevancies and significances by measuring the CVSS Upon identified C overflow vulnerabilities, review in-depth Carefully selected the online vulnerabilities database -> OWASP, NIST, OSVDB, Secunia, Microsoft Review an average of 5 reports per year from 2010 to five years before Each reports -> identified the root cause, class of overflow, year, criticality, exploitation how to and impact Further review on the defensive and preventive mechanism -> static analysis tools and method The review continues with in-depth studies on vulnerabilities taxonomy as we agreed with Krsul and Tsipenyuk (and others) that understanding on vulnerabilities is crucial for further defending and protecting from exploitation on the vulnerabilities. Taxonomy Construction Two critical activities in this phase -> identified and develop/formulae the criteria for well-defined taxonomy and construction of C overflow vulnerabilities exploit taxonomy Criteria for well-defined taxonomy Focus on related reports and publications especially papers published by well-known publisher (IEEE & Springer) -> covers papers that specifies, criticize or compliments criterions Shortlisted criterions is then reviewed -> focus on characteristics and meaning of the criterions. The final list is then published for expert review Construction of the taxonomy The idea -> construct from source-code perspective and focus on exploits methods Studies the previously collected evidences (reports, papers, etc) -> focus on vulnerability behaviour, characteristics on exploit, severity and impact. The identify vulnerabilities are then classified together based on common shared characteristics/behaviour using name are known to community The taxonomy is also published for feedback and comments
• #65: The objective of the evaluation: To measure the effectiveness and completeness of the taxonomy To measure severity, persistency and relevancies of each classes. Indirectly measure completeness and knowledge compliant of the taxonomy and shows how useful the taxonomy is by measuring To measure the effectiveness and efficiencies of static analysis tools Uniqueness of the evaluation is that there is no methods or approaches to evaluate a taxonomy especially against well-defined criteria done before. The first evaluation is evaluation on taxonomy against the well-defined criteria Measurement on Effectiveness and Completeness The criteria used to select tester are: Good understanding and knowledge in information security and familiar with exploitation and vulnerabilities terms. At least two years experiences in the area of information security. Know and experiences C programming language Taxonomy Evaluation with Selected Well-known Online Vulnerability Database and Organization Using the same set of sites and organization but limit to 7 most relevant The keyword used is the class name or its synonym If a report or advisory found, critical review is done to validate the class name, behaviour and characteristics Evaluation on the Significances and Relevancies of Classes Defined in the Taxonomy of C Overflow Vulnerabilities Exploit To measure on the significances and relevancies of each class defined in the taxonomy to current and future computer system security based on its current severity, impact and persistency. Indirectly indicates the correctness of position the class hierarchy and applicability in the taxonomy Used NIST, OWASP and OSVDB + Microsoft, Symantec, Secunia and Dept of Homeland Security. Numbers of advisories or reports reviewed from each sites are set to 50 maximum. Keyword + synonyms used -> unsafe function, integer range, integer overflow, memory overflow, heap overflow, buffer overflow, buffer overrun, memory overrun, pointer mixing, pointer scaling, out-of-bound, array out-of-bound, null termination, uninitialized variable and heap overrun Evaluation on Significant and Relevancies of C Overflow Vulnerabilities Classes and Impact to OS Criticality To ensure that the classes is relevant and significance to security community Steps 1 – evaluate probability to appear in the OS: Identify the OS based on market shares site (Awio Web Services LLC, 2014), (StatCounter, 2014) and (Net Applications.com, 2014) XP 32 bits, 7 32 and 64 bits and Linux 32 bits (Centos 5.5) Installed on Computers – Intel Pentium Core 2 Duo 2.2Ghz, 4GB RAM, 1TB harddisk, Gigabyte Motherboard Develop simple programs – at least 2 programs for each classes – Inter and Intra-procedural Run 3 times daily and reboot for each OS Steps 2 – Based on collected reports/advisories The CVSS - focus on severity and impact value The mean/average of the severity and impact is calculated for each class. Evaluate the static analysis tools effectiveness in detecting the identified classes Using the same develop programs and limited to windows 7 64-bits Select tools based on availability, full features available (not trial), be able to run on Windows OS Limit to 5 - SPLINT, RATS, ITS4, BOON, and BLAST Measure the time taken, number of detection, false alarm and true alarm. Evaluate the Static Analysis Tools Efficiencies in Analysing Open-source Code for Comparison with Previous Works Selected open source applications -> criteria: application and source code available and used by community. Identify – Apache HTTPD, Chrome, MySQL CE, Open VM Tool, TPM Emulator Measure the time, number of detection and false alarm are collected
• #66: The objective of the evaluation: To measure the effectiveness and completeness of the taxonomy To measure severity, persistency and relevancies of each classes. Indirectly measure completeness and knowledge compliant of the taxonomy and shows how useful the taxonomy is by measuring To measure the effectiveness and efficiencies of static analysis tools Uniqueness of the evaluation is that there is no methods or approaches to evaluate a taxonomy especially against well-defined criteria done before. The first evaluation is evaluation on taxonomy against the well-defined criteria Measurement on Effectiveness and Completeness The criteria used to select tester are: Good understanding and knowledge in information security and familiar with exploitation and vulnerabilities terms. At least two years experiences in the area of information security. Know and experiences C programming language Taxonomy Evaluation with Selected Well-known Online Vulnerability Database and Organization Using the same set of sites and organization but limit to 7 most relevant The keyword used is the class name or its synonym If a report or advisory found, critical review is done to validate the class name, behaviour and characteristics Evaluation on the Significances and Relevancies of Classes Defined in the Taxonomy of C Overflow Vulnerabilities Exploit To measure on the significances and relevancies of each class defined in the taxonomy to current and future computer system security based on its current severity, impact and persistency. Indirectly indicates the correctness of position the class hierarchy and applicability in the taxonomy Used NIST, OWASP and OSVDB + Microsoft, Symantec, Secunia and Dept of Homeland Security. Numbers of advisories or reports reviewed from each sites are set to 50 maximum. Keyword + synonyms used -> unsafe function, integer range, integer overflow, memory overflow, heap overflow, buffer overflow, buffer overrun, memory overrun, pointer mixing, pointer scaling, out-of-bound, array out-of-bound, null termination, uninitialized variable and heap overrun Evaluation on Significant and Relevancies of C Overflow Vulnerabilities Classes and Impact to OS Criticality To ensure that the classes is relevant and significance to security community Steps 1 – evaluate probability to appear in the OS: Identify the OS based on market shares site (Awio Web Services LLC, 2014), (StatCounter, 2014) and (Net Applications.com, 2014) XP 32 bits, 7 32 and 64 bits and Linux 32 bits (Centos 5.5) Installed on Computers – Intel Pentium Core 2 Duo 2.2Ghz, 4GB RAM, 1TB harddisk, Gigabyte Motherboard Develop simple programs – at least 2 programs for each classes – Inter and Intra-procedural Run 3 times daily and reboot for each OS Steps 2 – Based on collected reports/advisories The CVSS - focus on severity and impact value The mean/average of the severity and impact is calculated for each class. Evaluate the static analysis tools effectiveness in detecting the identified classes Using the same develop programs and limited to windows 7 64-bits Select tools based on availability, full features available (not trial), be able to run on Windows OS Limit to 5 - SPLINT, RATS, ITS4, BOON, and BLAST Measure the time taken, number of detection, false alarm and true alarm. Evaluate the Static Analysis Tools Efficiencies in Analysing Open-source Code for Comparison with Previous Works Selected open source applications -> criteria: application and source code available and used by community. Identify – Apache HTTPD, Chrome, MySQL CE, Open VM Tool, TPM Emulator Measure the time, number of detection and false alarm are collected
• #67: The objective of the evaluation: To measure the effectiveness and completeness of the taxonomy To measure severity, persistency and relevancies of each classes. Indirectly measure completeness and knowledge compliant of the taxonomy and shows how useful the taxonomy is by measuring To measure the effectiveness and efficiencies of static analysis tools Uniqueness of the evaluation is that there is no methods or approaches to evaluate a taxonomy especially against well-defined criteria done before. The first evaluation is evaluation on taxonomy against the well-defined criteria Measurement on Effectiveness and Completeness The criteria used to select tester are: Good understanding and knowledge in information security and familiar with exploitation and vulnerabilities terms. At least two years experiences in the area of information security. Know and experiences C programming language Taxonomy Evaluation with Selected Well-known Online Vulnerability Database and Organization Using the same set of sites and organization but limit to 7 most relevant The keyword used is the class name or its synonym If a report or advisory found, critical review is done to validate the class name, behaviour and characteristics Evaluation on the Significances and Relevancies of Classes Defined in the Taxonomy of C Overflow Vulnerabilities Exploit To measure on the significances and relevancies of each class defined in the taxonomy to current and future computer system security based on its current severity, impact and persistency. Indirectly indicates the correctness of position the class hierarchy and applicability in the taxonomy Used NIST, OWASP and OSVDB + Microsoft, Symantec, Secunia and Dept of Homeland Security. Numbers of advisories or reports reviewed from each sites are set to 50 maximum. Keyword + synonyms used -> unsafe function, integer range, integer overflow, memory overflow, heap overflow, buffer overflow, buffer overrun, memory overrun, pointer mixing, pointer scaling, out-of-bound, array out-of-bound, null termination, uninitialized variable and heap overrun Evaluation on Significant and Relevancies of C Overflow Vulnerabilities Classes and Impact to OS Criticality To ensure that the classes is relevant and significance to security community Steps 1 – evaluate probability to appear in the OS: Identify the OS based on market shares site (Awio Web Services LLC, 2014), (StatCounter, 2014) and (Net Applications.com, 2014) XP 32 bits, 7 32 and 64 bits and Linux 32 bits (Centos 5.5) Installed on Computers – Intel Pentium Core 2 Duo 2.2Ghz, 4GB RAM, 1TB harddisk, Gigabyte Motherboard Develop simple programs – at least 2 programs for each classes – Inter and Intra-procedural Run 3 times daily and reboot for each OS Steps 2 – Based on collected reports/advisories The CVSS - focus on severity and impact value The mean/average of the severity and impact is calculated for each class. Evaluate the static analysis tools effectiveness in detecting the identified classes Using the same develop programs and limited to windows 7 64-bits Select tools based on availability, full features available (not trial), be able to run on Windows OS Limit to 5 - SPLINT, RATS, ITS4, BOON, and BLAST Measure the time taken, number of detection, false alarm and true alarm. Evaluate the Static Analysis Tools Efficiencies in Analysing Open-source Code for Comparison with Previous Works Selected open source applications -> criteria: application and source code available and used by community. Identify – Apache HTTPD, Chrome, MySQL CE, Open VM Tool, TPM Emulator Measure the time, number of detection and false alarm are collected
• #68: The objective of the evaluation: To measure the effectiveness and completeness of the taxonomy To measure severity, persistency and relevancies of each classes. Indirectly measure completeness and knowledge compliant of the taxonomy and shows how useful the taxonomy is by measuring To measure the effectiveness and efficiencies of static analysis tools Uniqueness of the evaluation is that there is no methods or approaches to evaluate a taxonomy especially against well-defined criteria done before. The first evaluation is evaluation on taxonomy against the well-defined criteria Measurement on Effectiveness and Completeness The criteria used to select tester are: Good understanding and knowledge in information security and familiar with exploitation and vulnerabilities terms. At least two years experiences in the area of information security. Know and experiences C programming language Taxonomy Evaluation with Selected Well-known Online Vulnerability Database and Organization Using the same set of sites and organization but limit to 7 most relevant The keyword used is the class name or its synonym If a report or advisory found, critical review is done to validate the class name, behaviour and characteristics Evaluation on the Significances and Relevancies of Classes Defined in the Taxonomy of C Overflow Vulnerabilities Exploit To measure on the significances and relevancies of each class defined in the taxonomy to current and future computer system security based on its current severity, impact and persistency. Indirectly indicates the correctness of position the class hierarchy and applicability in the taxonomy Used NIST, OWASP and OSVDB + Microsoft, Symantec, Secunia and Dept of Homeland Security. Numbers of advisories or reports reviewed from each sites are set to 50 maximum. Keyword + synonyms used -> unsafe function, integer range, integer overflow, memory overflow, heap overflow, buffer overflow, buffer overrun, memory overrun, pointer mixing, pointer scaling, out-of-bound, array out-of-bound, null termination, uninitialized variable and heap overrun Evaluation on Significant and Relevancies of C Overflow Vulnerabilities Classes and Impact to OS Criticality To ensure that the classes is relevant and significance to security community Steps 1 – evaluate probability to appear in the OS: Identify the OS based on market shares site (Awio Web Services LLC, 2014), (StatCounter, 2014) and (Net Applications.com, 2014) XP 32 bits, 7 32 and 64 bits and Linux 32 bits (Centos 5.5) Installed on Computers – Intel Pentium Core 2 Duo 2.2Ghz, 4GB RAM, 1TB harddisk, Gigabyte Motherboard Develop simple programs – at least 2 programs for each classes – Inter and Intra-procedural Run 3 times daily and reboot for each OS Steps 2 – Based on collected reports/advisories The CVSS - focus on severity and impact value The mean/average of the severity and impact is calculated for each class. Evaluate the static analysis tools effectiveness in detecting the identified classes Using the same develop programs and limited to windows 7 64-bits Select tools based on availability, full features available (not trial), be able to run on Windows OS Limit to 5 - SPLINT, RATS, ITS4, BOON, and BLAST Measure the time taken, number of detection, false alarm and true alarm. Evaluate the Static Analysis Tools Efficiencies in Analysing Open-source Code for Comparison with Previous Works Selected open source applications -> criteria: application and source code available and used by community. Identify – Apache HTTPD, Chrome, MySQL CE, Open VM Tool, TPM Emulator Measure the time, number of detection and false alarm are collected
• #71: There are many criteria listed by previous experts ranging from 3(Killourhy, Maxion, & Tan, 2004) to at most 18 by Lough (Lough, 2001). After a series of careful review on the meaning and relationship of each criterion, it is then finalized to eight most relevant and significant criteria, which later became the criteria for well-defined taxonomy The first criterion is Simplicity whereby it shows the complexity of knowledge in a simplified readable and understandable structures (or collections) of an object being studied. Identified by Tsipenyuk et. al. (Tsipenyuk, Chess, & McGraw, 2005) in their studies on taxonomy. This criterion ease the understanding of a structured body of knowledge presented in taxonomy form. Failure to meet this criterion will result in difficulties for a user to understand the subject or object under study. For example, taxonomy by Hansmann (Hansmann & Hunt, A Taxonomy of Network and Computer Attacks, 2005), despite it is structured, the taxonomy failed to meet this criterion. The second criterion for well-defined taxonomy is Organized Structures. Identified by many experts such as by Lough (Lough, 2001) and Vijayagharavan (Vijayaraghavan & Kaner, 2003) as an important criterion for a well-defined taxonomy. Indicates that a particular taxonomy is well-defined when a proper and readable structures or form of group or class of subject is well established. It is agreeable as without proper structures, although it satisfy many other criterions for well-defined taxonomy, it will not ease user to understand the classified subject or object. The third criterion for well-defined taxonomy is Obvious. Also known as Objectivity (Krsul, 1998), Determinism (Krsul, 1998), (Lough, 2001) and Hansmann (Hansmann & Hunt, A Taxonomy of Network and Computer Attacks, 2005), and Alhazmi et. al. (Alhazmi, Woo, & Malaiya, 2006) . It is the third most significant criterion, as it is required to ease the process of classification or identification of an element or object in the field being studied without doubt. This is to avoid confusion and difficulties to a user which will result in non-repeatability and non-exclusiveness of a process and class, and hence contributes to ineffectiveness of the taxonomy as a tool to understand the field of studies. Repeatability is the fourth criterion required to ensure a particular taxonomy is well-defined. The criterion bridges obviousness to specificity. It ascertains the earlier and former criterion so as it will be applicable and fit to any taxonomy in achieving a well-defined taxonomy. Repeatability establishes consistency in classification, thus resulting in reliable result. It is also identified by many expert as important criteria such as Hansmann (Hansmann & Hunt, A Taxonomy of Network and Computer Attacks, 2005), Alhazmi et. al. (Alhazmi, Woo, & Malaiya, 2006), Lough (Lough, 2001), Krsul (Krsul, 1998), Howard and Longstaff (Howard & Longstaff, 1998), and Killourhy (Killourhy, Maxion, & Tan, 2004). The fifth is Specificity. A.k.a Mutual Exclusive (Howard & Longstaff, 1998), (Lough, 2001), (Killourhy, Maxion, & Tan, 2004), (Hansmann & Hunt, A Taxonomy of Network and Computer Attacks, 2005) and (Alhazmi, Woo, & Malaiya, 2006), Unambiguous (Howard & Longstaff, 1998) and (Lough, 2001), (Hansmann & Hunt, A Taxonomy of Network and Computer Attacks, 2005) and Primitive (Aslam, 1995). listed after repeatability and obviousness as an object studied must first be obvious and the process of classifications must be able to be repeated by any individual user within the same domain of studies. The criteria enhance taxonomy Obviousness and Repeatability by ensuring pure consistency and avoids confusion in classifications as an object being studied can only be classified in one and only one class. There are a few taxonomies that ignore this criterion such as by Zhivich (Zhivich M. A., 2005), Krsul (Krsul, 1998) and Zitser (Zitser, An Evaluation of Static Source Code Analyzers, 2003), which have resulted in difficulties in getting reliable and consistent classifications. To strengthen the taxonomy and to bind the previous three criterions; that are Obviousness, Repeatability and Specificity, we have the sixth criterion, known as Similarity. The criterion must be used in conjunction with the other three to ensure that a taxonomy be able to achieve repeatability, obviousness of a class or object in the class and comprises of classes that are mutually exclusive. This is only possible because similarity criterion guarantees that a particular class has specific characteristics and the objects that are classified fall within the class that shares common behaviours or characteristics. The seven criterion is Completeness It is a criterion that defines comprehensiveness of a taxonomy whereby the classes listed within the taxonomy are sufficient and broad enough to cover every possible object within the field of study. Without this criterion for well-defined taxonomy, there would be a possibility of an object being filed in new class, a wrong class, a class that does not reflect the object characteristics, or a class that contains many objects with contrasting characteristics. This will result in its inconsistency and non-repeatability in applying taxonomy and thus causing users to confuse and have difficulties to understand the studied field as exemplified by taxonomy given by Bazaz and Arthur (Bazaz & Arthur, 2007), and Gegick and Williams (Gegick & Williams, 2005). Finally, the last criterion that must be complied before the taxonomy is considered as well-defined is Knowledge Compliant. The criterion indicates that the taxonomy shall be constructed within the known body of knowledge and shall use terminologies or descriptions that are friendly to user within the area being studied. With this, the taxonomy shall be able to improve user understanding on the subject. Vijayaraghan and Kaner (Vijayaraghavan & Kaner, 2003) shared the same thought whereby they stated that a good taxonomy shall be completed, useful and broad for ease of understanding especially to new or moderate person in the area of studies. In addition, although it is develop in the area of software vulnerabilities, we highly believed that it is also applicable for other kind of classifications and taxonomies
• #72: Taxonomy of C overflow vulnerabilities exploits was constructed using the developed criteria for well-defined taxonomy as the guideline to ensure it is useful and ease user in understanding the C overflow vulnerabilities. This is a characteristic-based taxonomy whereby each class listed in the taxonomy has its own unique characteristics to ensure no ambiguity in the process of classifications. It was constructed from source code perspective and exploitation methods that have been used to exploit the vulnerabilities. The taxonomy that was developed focuses on overflow vulnerabilities in C programming language. Nevertheless, C++ and Objective-C programming language is also covered in this taxonomy as both is the successor of C and therefore in inherits the C behavior and characteristics which includes the overflow vulnerabilities (Younan, Joosen, & Piessens, 2004), (Fünfrocken, 2005), (Apple Inc., 2012) and (Bitz, et al., 2008). The first class in the taxonomy is unsafe function. The class comprises of functions that are unsafe by default, for example scanf(), gets() and strcat() (Microsoft Corp., 2012), (IBM X-Force, 2011), (Secunia, 2011) and (Bitz, et al., 2008), whereby this functions does not perform validation at the time it is being executed. This differ with other functions such as strlcpy() and strlcat(), as these two functions are considered safe by default since both of the functions requires developers to define the ‘n’ length of a string as one of the input and therefore minimize the overflow possibilities. Upon being executed, it will automatically trigger overflow which have resulted in either the next assigned memory is overwritten, next functions being executed or skipped, or causing the system to behave abnormally. To classify vulnerabilities under this is rather simple as ones needs to determine two criterion; that are the use of unsafe function and non-validated input. Exploiting this vulnerability is also as simple as detecting it. Attackers only need to supply an input that is greater than the allocated size or larger than estimated length of memory addressing Nevertheless, the defence mechanism is also similarly easy; that is, avoid the use of unsafe functions. If it is required, then user shall provide an input validation function before the function call. The second class in the taxonomy is Array Out-of-Bound. The class classifies any type of array implemented in a program or function that is vulnerable for exploitation if it matches two criterions; that are use of array and, no validation on the array and its index before the array being called or processed. Attackers have exploited this class of vulnerability by supplying an index that is beyond the defined size of the array; that is either more than ‘n’ length of array or ‘-1’, or by exploiting a program that wrongly perform index calculation. The third class in C overflow vulnerabilities exploits taxonomy is integer ranger/overflow. Any arithmetic operations that are potentially triggering overflow are classified in this class. However, overflow due to numerical conversion resulted from arithmetic operations is not included in this class and the reason is described in the subsequent discussion section. This class includes all arithmetic operations such as add, multiply and deduction, and all types of numerical variable like int, double and float. The characteristics of this class of vulnerability are, it is triggered in an arithmetic operation and involve numerical variable. This vulnerability class is a difficult to detect since ones needs to understand the arithmetic operation and be able to calculate possible input and output of the operation. However, it can be prevented by validating input before any operation and checking the output of the operation before proceed to another line of code that use the output as part of its operation. The fourth class in the C overflows vulnerabilities exploits taxonomy is return-into-libC. This class of attack characteristics is similar to unsafe functions and array out-of-bound whereby it receives an input from user of the program and triggers overflow upon being executed. However, instead of overflowing the next assign variable or memory space with previous extra data, return-into-libC overflow the next assign variable or memory space with a call to function in C library which is then used to execute a call to a malicious function or program. <click> Shows the comparison of these three overflow vulnerabilities classes. (click) To prevent this vulnerability is by validating input before executing any process with the input and ensure that the argument being passing around is valid argument with valid length or refer to valid functions. The fifth class listed in the C overflow vulnerabilities exploits taxonomy is Memory Function. It is a C overflow vulnerabilities class that classified any overflow vulnerabilities which involves or use of functions concerning managing or processing memory. By default, memory function such as malloc(), memcpy(), xmalloc() and free() is safe and those not trigger overflow upon executed despite having malicious input as its parameter. This is the key difference between this class and unsafe function class. From source code perspective, this vulnerability exist where an input is not validate before being used, followed by used of memory related function and finally, the result is not validated after successfully executed the function. Uninitialized memory and unused memory after allocation is also included in this. From source code perspective, this class of vulnerability can be avoided by validating the input before being used in the memory function, removing unused memory, ensure that the second call to the same memory is verified and/or initialized memory with default value. At number six is function pointer or also known as pointer aliasing and hence is used vice versa in this thesis. Pointer aliasing relates directly to the implementation of pointer as reference variable that store variable or function address, which later used to get the variable value. This class differ from return-into-libc vulnerability class as it does not depends on input, not limited to string pointer and different vulnerabilities triggering method. The characteristics for this class of vulnerability are used of pointer to refer functions or variable and being use only as reference variable and becomes vulnerable when it refers to nullified variable, refer to null or the reference is overwritten with different values. A nullified variable or reference will open an opportunity for hackers to exploit, whereas overwritten values is injected by hackers and works the same way as return-into-libC. In terms of prevention, it can be prevented by ensuring the validation is in place before a pointer is used and this only applied to nullified reference or the pointer itself. For overwritten values, a semantic approach in static or dynamic source code analysis is required to prevent this class of vulnerability from being exploited. Variable type conversion is the seventh class in C overflow vulnerabilities exploits taxonomy. Related to the process of converting from one variable to another type of variable. Any process including arithmetic operation that resulted in type conversion; for instance, converting int type to double or float in division operation and converting char type variable to int and vice versa, that does not properly handled will be classified into this class of vulnerability. To identify this class of vulnerability is simply by looking at conversion done within the program and verify if there are validation done before the conversion code runs. It can be prevented by validating the variable used in conversion and ensure that it holds within the range of accepted variable after the conversion happens. The eight class of the constructed taxonomy is pointer scaling or also known as pointer mixing. It differ from pointer alias (pointer function) vulnerability class as this class of vulnerability is triggered in an arithmetic operation involving pointer whereas pointer alias is a vulnerability that exist on pointer that is used as references to variable or function. In terms of references, the earlier class may point to invalid references whereas the latter class still point to valid reference but the value it refers may be overflow to the next defined variable due to incorrect arithmetic operation. This vulnerability exists when there is possibilities of a pointer reference to be move unintentionally to certain bytes of address resulted by scaling of pointer process in the arithmetic operation. From source code perspective, the vulnerability is not easy to be identified. Programmers need to look on the pointer involves, the type of the pointers and the result of the arithmetic and scaling operation on the pointer. Therefore, to prevent this class of vulnerability from occurring is by ensuring that the scaling operation is mathematically proven safe. At number nine in C overflow vulnerabilities exploit taxonomy is Uninitialized Variable. The class is defined as any variable used that is not properly initialized upon or after definition and is used in any of the process within the application is vulnerable and exploitable. Therefore, the characteristics of the class are it involves variable and it is used before being initialized in a read statement. It can be prevented by ensuring that all variables used are initialized before used. Finally, the last but noted as important class of vulnerability in the C overflow vulnerabilities exploit taxonomy is Null Termination vulnerability class. The class is defined as a vulnerability that occurs due to improper string termination, an array that does not have terminator at the last index of the array or no null byte termination which resulted as a potential overflow or exploitable. The characteristics of the class are the used of variable that accepts string of input with length possible to be maximum defined for the variable; for instance if the length is defined as 12 characters thus the maximum input is also 12 characters, with possibility of having no termination at the end of the input. From source code perspective, this class of vulnerability can be identified by looking at the read statement where the input string is received and assign to a variable and no validation on the content of the input before next operation on the input. It can be prevented by having validation before read operation on the variable or limit the input to ‘n – 1’ length which allows the string to be appended with null terminator if required. Discussion It is agreed that many of the vulnerabilities classes have been identified earlier such as by Wagner (Wagner, Foster, Brewer, & Aiken, 2000), Lippmann and his students (Kratkiewicz & Lippmann, 2005) and (Zhivich, Leek, & Lippmann, 2005), and latest by Shahriar (Shariar & Zulkernine, 2011). However, these known C overflow vulnerabilities were not classified in a well-defined taxonomy with focus on exploit methodologies and source code perspectives. Sotirov stated that earlier works on taxonomy and software vulnerabilities classifications did not focus on the right attributes that contributes to the problem in static analysis of which has great impact in understanding of C overflow vulnerabilities (Sotirov, 2005). There are also taxonomies that were developed specifics to C overflow vulnerabilities and source code perspective such as by Sotirov (Sotirov, 2005) and Moore (Moore, 2007) but limited coverage of C overflow vulnerabilities. Beside taxonomies, there are also classifications on software and network vulnerabilities that cover most of known C overflow vulnerabilities such as by Shahriar and Zulkernine (Shahriar & Zulkernine, 2011), and Killourhy et. al. (Killourhy, Maxion, & Tan, 2004) despite having broad or too general classifications. Therefore, this C overflow vulnerabilities exploit taxonomy is constructed to overcomes the shortcomings of previous works in classification and taxonomy with regards to C overflow vulnerabilities. Our taxonomy is constructed based on eight criterions defined for constructing well-defined taxonomy. Besides ours, there are also earlier taxonomy constructed using criteria as guidelines such as by Krsul (Krsul, 1998), Lough (Lough, 2001), Vijayaraghavan (Vijayaraghavan G. V., 2003), Killourhy (Killourhy, Maxion, & Tan, 2004) and Hansmann (Hansmann & Hunt, A Taxonomy of Network and Computer Attacks, 2005). However, the criteria used in previous works are incomprehensive, unnecessary or incomplete. Although those previous taxonomy has improved the understanding on vulnerabilities, it is yet to be significant especially in the area of C overflow vulnerabilities. In terms of perspective, earlier works focused on computer’s memory perspective as they viewed the impact on the memory processing. This perspective is relevant but yet to be significant to developers or programmers as it is not useful to developers in writing secure codes. As such, the terminology and structures must be closely related to programming work. In contrast, C overflow vulnerabilities exploit taxonomy is constructed from source code perspective and exploit methods with the purpose of educating the software developers on secure coding in C. The characteristics and classes were derived by focusing on its appearance in the source code and the methods used to exploit that have impact on the code sequences and process. This is because it is believed that to prevent C overflow from occurring, the root cause must be cure rather than the symptom of it. Shahriar and Zulkernine (Shariar & Zulkernine, 2011), and Killourhy et. al. (Killourhy, Maxion, & Tan, 2004) constructed their classifications based on the same perspective. However, compared to their classifications, the classification in our taxonomy focuses specifically on developers view and how vulnerable codes looks like. In contrast, their classifications mentioned source code as generic and did not focus on appearance in the code. For that reason, the C overflow vulnerabilities exploit taxonomy is close and friendly to developers compared to other C overflow vulnerabilities taxonomy or classifications. We agreed with previous experts such as Krsul (Krsul, 1998), Lough (Lough, 2001), Vijayaraghavan (Vijayaraghavan G. V., 2003) and Alhazmi et. al. (Alhazmi, Woo, & Malaiya, 2006) whom stated that a well-defined taxonomy shall be specifics and cover all vulnerabilities. Therefore, the C overflow vulnerabilities exploit taxonomy is constructed specifics to C programming languages focusing only on overflow vulnerabilities. Hence, the scope of the taxonomy is C programming language and overflow vulnerabilities in C. However, although it is specifics to C, since it is also predecessor and baseline for C++ and Objective-C, the two programming languages is indirectly covered. Moore (Moore, 2007), Wilander (Wilander, 2002), Zitser (Zitser, An Evaluation of Static Source Code Analyzers, 2003), Zhivich (Zhivich M. A., 2005), Sotirov (Sotirov, 2005), Wagner (Wagner D. A., 2000) and Kratkiewicz (Kratkiewicz K. J., 2005) also constructed their taxonomy or classifications specifics to C programming language. However, due to different perspective, their taxonomy or classifications only cover limited classes of C overflow vulnerabilities. The other taxonomies such as by Aslam (Aslam, 1995), Howard and Longstaff (Howard & Longstaff, 1998), Krsul (Krsul, 1998), Pothamsetty and Akyol (Pothamsetty & Akyol, 2004), Killourhy et. al. (Killourhy, Maxion, & Tan, 2004) and Hansmann and Hunt (Hansmann & Hunt, A Taxonomy of Network and Computer Attacks, 2005), despite covers many classes of C overflow vulnerabilities, is not specifics to C programming language and C overflow vulnerabilities. Their scopes are network, generic software vulnerabilities or web application vulnerabilities. Hence, their scopes are still broad and generic. For that reason, the C overflow vulnerabilities exploit taxonomy is more relevant and significant to developers whom use C as the programming language for coding. C overflow vulnerabilities exploit taxonomy covers 10 classes of C overflow vulnerabilities. It is the first taxonomy that covers all classes of C overflow vulnerabilities. The closest to this taxonomy is classifications by Tsipenyuk et. al. (Tsipenyuk, Chess, & McGraw, 2005) of which she listed seven overflow vulnerabilities classes in the year 2005. No doubt that all of the classes in our taxonomy have been identified earlier by many experts and well-established organization, but there is no works done to consolidate and organize the information into a taxonomy for ease of understanding and educated developers. Therefore, it is conclude that our taxonomy is comprehensive and up to date compare to previous works as it contains all relevant and significant classes of C overflow vulnerabilities
• #73: Taxonomy of C overflow vulnerabilities exploits was constructed using the developed criteria for well-defined taxonomy as the guideline to ensure it is useful and ease user in understanding the C overflow vulnerabilities. This is a characteristic-based taxonomy whereby each class listed in the taxonomy has its own unique characteristics to ensure no ambiguity in the process of classifications. It was constructed from source code perspective and exploitation methods that have been used to exploit the vulnerabilities. The taxonomy that was developed focuses on overflow vulnerabilities in C programming language. Nevertheless, C++ and Objective-C programming language is also covered in this taxonomy as both is the successor of C and therefore in inherits the C behavior and characteristics which includes the overflow vulnerabilities (Younan, Joosen, & Piessens, 2004), (Fünfrocken, 2005), (Apple Inc., 2012) and (Bitz, et al., 2008). The first class in the taxonomy is unsafe function. The class comprises of functions that are unsafe by default, for example scanf(), gets() and strcat() (Microsoft Corp., 2012), (IBM X-Force, 2011), (Secunia, 2011) and (Bitz, et al., 2008), whereby this functions does not perform validation at the time it is being executed. This differ with other functions such as strlcpy() and strlcat(), as these two functions are considered safe by default since both of the functions requires developers to define the ‘n’ length of a string as one of the input and therefore minimize the overflow possibilities. Upon being executed, it will automatically trigger overflow which have resulted in either the next assigned memory is overwritten, next functions being executed or skipped, or causing the system to behave abnormally. To classify vulnerabilities under this is rather simple as ones needs to determine two criterion; that are the use of unsafe function and non-validated input. Exploiting this vulnerability is also as simple as detecting it. Attackers only need to supply an input that is greater than the allocated size or larger than estimated length of memory addressing Nevertheless, the defence mechanism is also similarly easy; that is, avoid the use of unsafe functions. If it is required, then user shall provide an input validation function before the function call. The second class in the taxonomy is Array Out-of-Bound. The class classifies any type of array implemented in a program or function that is vulnerable for exploitation if it matches two criterions; that are use of array and, no validation on the array and its index before the array being called or processed. Attackers have exploited this class of vulnerability by supplying an index that is beyond the defined size of the array; that is either more than ‘n’ length of array or ‘-1’, or by exploiting a program that wrongly perform index calculation. The third class in C overflow vulnerabilities exploits taxonomy is integer ranger/overflow. Any arithmetic operations that are potentially triggering overflow are classified in this class. However, overflow due to numerical conversion resulted from arithmetic operations is not included in this class and the reason is described in the subsequent discussion section. This class includes all arithmetic operations such as add, multiply and deduction, and all types of numerical variable like int, double and float. The characteristics of this class of vulnerability are, it is triggered in an arithmetic operation and involve numerical variable. This vulnerability class is a difficult to detect since ones needs to understand the arithmetic operation and be able to calculate possible input and output of the operation. However, it can be prevented by validating input before any operation and checking the output of the operation before proceed to another line of code that use the output as part of its operation. The fourth class in the C overflows vulnerabilities exploits taxonomy is return-into-libC. This class of attack characteristics is similar to unsafe functions and array out-of-bound whereby it receives an input from user of the program and triggers overflow upon being executed. However, instead of overflowing the next assign variable or memory space with previous extra data, return-into-libC overflow the next assign variable or memory space with a call to function in C library which is then used to execute a call to a malicious function or program. <click> Shows the comparison of these three overflow vulnerabilities classes. (click) To prevent this vulnerability is by validating input before executing any process with the input and ensure that the argument being passing around is valid argument with valid length or refer to valid functions. The fifth class listed in the C overflow vulnerabilities exploits taxonomy is Memory Function. It is a C overflow vulnerabilities class that classified any overflow vulnerabilities which involves or use of functions concerning managing or processing memory. By default, memory function such as malloc(), memcpy(), xmalloc() and free() is safe and those not trigger overflow upon executed despite having malicious input as its parameter. This is the key difference between this class and unsafe function class. From source code perspective, this vulnerability exist where an input is not validate before being used, followed by used of memory related function and finally, the result is not validated after successfully executed the function. Uninitialized memory and unused memory after allocation is also included in this. From source code perspective, this class of vulnerability can be avoided by validating the input before being used in the memory function, removing unused memory, ensure that the second call to the same memory is verified and/or initialized memory with default value. At number six is function pointer or also known as pointer aliasing and hence is used vice versa in this thesis. Pointer aliasing relates directly to the implementation of pointer as reference variable that store variable or function address, which later used to get the variable value. This class differ from return-into-libc vulnerability class as it does not depends on input, not limited to string pointer and different vulnerabilities triggering method. The characteristics for this class of vulnerability are used of pointer to refer functions or variable and being use only as reference variable and becomes vulnerable when it refers to nullified variable, refer to null or the reference is overwritten with different values. A nullified variable or reference will open an opportunity for hackers to exploit, whereas overwritten values is injected by hackers and works the same way as return-into-libC. In terms of prevention, it can be prevented by ensuring the validation is in place before a pointer is used and this only applied to nullified reference or the pointer itself. For overwritten values, a semantic approach in static or dynamic source code analysis is required to prevent this class of vulnerability from being exploited. Variable type conversion is the seventh class in C overflow vulnerabilities exploits taxonomy. Related to the process of converting from one variable to another type of variable. Any process including arithmetic operation that resulted in type conversion; for instance, converting int type to double or float in division operation and converting char type variable to int and vice versa, that does not properly handled will be classified into this class of vulnerability. To identify this class of vulnerability is simply by looking at conversion done within the program and verify if there are validation done before the conversion code runs. It can be prevented by validating the variable used in conversion and ensure that it holds within the range of accepted variable after the conversion happens. The eight class of the constructed taxonomy is pointer scaling or also known as pointer mixing. It differ from pointer alias (pointer function) vulnerability class as this class of vulnerability is triggered in an arithmetic operation involving pointer whereas pointer alias is a vulnerability that exist on pointer that is used as references to variable or function. In terms of references, the earlier class may point to invalid references whereas the latter class still point to valid reference but the value it refers may be overflow to the next defined variable due to incorrect arithmetic operation. This vulnerability exists when there is possibilities of a pointer reference to be move unintentionally to certain bytes of address resulted by scaling of pointer process in the arithmetic operation. From source code perspective, the vulnerability is not easy to be identified. Programmers need to look on the pointer involves, the type of the pointers and the result of the arithmetic and scaling operation on the pointer. Therefore, to prevent this class of vulnerability from occurring is by ensuring that the scaling operation is mathematically proven safe. At number nine in C overflow vulnerabilities exploit taxonomy is Uninitialized Variable. The class is defined as any variable used that is not properly initialized upon or after definition and is used in any of the process within the application is vulnerable and exploitable. Therefore, the characteristics of the class are it involves variable and it is used before being initialized in a read statement. It can be prevented by ensuring that all variables used are initialized before used. Finally, the last but noted as important class of vulnerability in the C overflow vulnerabilities exploit taxonomy is Null Termination vulnerability class. The class is defined as a vulnerability that occurs due to improper string termination, an array that does not have terminator at the last index of the array or no null byte termination which resulted as a potential overflow or exploitable. The characteristics of the class are the used of variable that accepts string of input with length possible to be maximum defined for the variable; for instance if the length is defined as 12 characters thus the maximum input is also 12 characters, with possibility of having no termination at the end of the input. From source code perspective, this class of vulnerability can be identified by looking at the read statement where the input string is received and assign to a variable and no validation on the content of the input before next operation on the input. It can be prevented by having validation before read operation on the variable or limit the input to ‘n – 1’ length which allows the string to be appended with null terminator if required. Discussion It is agreed that many of the vulnerabilities classes have been identified earlier such as by Wagner (Wagner, Foster, Brewer, & Aiken, 2000), Lippmann and his students (Kratkiewicz & Lippmann, 2005) and (Zhivich, Leek, & Lippmann, 2005), and latest by Shahriar (Shariar & Zulkernine, 2011). However, these known C overflow vulnerabilities were not classified in a well-defined taxonomy with focus on exploit methodologies and source code perspectives. Sotirov stated that earlier works on taxonomy and software vulnerabilities classifications did not focus on the right attributes that contributes to the problem in static analysis of which has great impact in understanding of C overflow vulnerabilities (Sotirov, 2005). There are also taxonomies that were developed specifics to C overflow vulnerabilities and source code perspective such as by Sotirov (Sotirov, 2005) and Moore (Moore, 2007) but limited coverage of C overflow vulnerabilities. Beside taxonomies, there are also classifications on software and network vulnerabilities that cover most of known C overflow vulnerabilities such as by Shahriar and Zulkernine (Shahriar & Zulkernine, 2011), and Killourhy et. al. (Killourhy, Maxion, & Tan, 2004) despite having broad or too general classifications. Therefore, this C overflow vulnerabilities exploit taxonomy is constructed to overcomes the shortcomings of previous works in classification and taxonomy with regards to C overflow vulnerabilities. Our taxonomy is constructed based on eight criterions defined for constructing well-defined taxonomy. Besides ours, there are also earlier taxonomy constructed using criteria as guidelines such as by Krsul (Krsul, 1998), Lough (Lough, 2001), Vijayaraghavan (Vijayaraghavan G. V., 2003), Killourhy (Killourhy, Maxion, & Tan, 2004) and Hansmann (Hansmann & Hunt, A Taxonomy of Network and Computer Attacks, 2005). However, the criteria used in previous works are incomprehensive, unnecessary or incomplete. Although those previous taxonomy has improved the understanding on vulnerabilities, it is yet to be significant especially in the area of C overflow vulnerabilities. In terms of perspective, earlier works focused on computer’s memory perspective as they viewed the impact on the memory processing. This perspective is relevant but yet to be significant to developers or programmers as it is not useful to developers in writing secure codes. As such, the terminology and structures must be closely related to programming work. In contrast, C overflow vulnerabilities exploit taxonomy is constructed from source code perspective and exploit methods with the purpose of educating the software developers on secure coding in C. The characteristics and classes were derived by focusing on its appearance in the source code and the methods used to exploit that have impact on the code sequences and process. This is because it is believed that to prevent C overflow from occurring, the root cause must be cure rather than the symptom of it. Shahriar and Zulkernine (Shariar & Zulkernine, 2011), and Killourhy et. al. (Killourhy, Maxion, & Tan, 2004) constructed their classifications based on the same perspective. However, compared to their classifications, the classification in our taxonomy focuses specifically on developers view and how vulnerable codes looks like. In contrast, their classifications mentioned source code as generic and did not focus on appearance in the code. For that reason, the C overflow vulnerabilities exploit taxonomy is close and friendly to developers compared to other C overflow vulnerabilities taxonomy or classifications. We agreed with previous experts such as Krsul (Krsul, 1998), Lough (Lough, 2001), Vijayaraghavan (Vijayaraghavan G. V., 2003) and Alhazmi et. al. (Alhazmi, Woo, & Malaiya, 2006) whom stated that a well-defined taxonomy shall be specifics and cover all vulnerabilities. Therefore, the C overflow vulnerabilities exploit taxonomy is constructed specifics to C programming languages focusing only on overflow vulnerabilities. Hence, the scope of the taxonomy is C programming language and overflow vulnerabilities in C. However, although it is specifics to C, since it is also predecessor and baseline for C++ and Objective-C, the two programming languages is indirectly covered. Moore (Moore, 2007), Wilander (Wilander, 2002), Zitser (Zitser, An Evaluation of Static Source Code Analyzers, 2003), Zhivich (Zhivich M. A., 2005), Sotirov (Sotirov, 2005), Wagner (Wagner D. A., 2000) and Kratkiewicz (Kratkiewicz K. J., 2005) also constructed their taxonomy or classifications specifics to C programming language. However, due to different perspective, their taxonomy or classifications only cover limited classes of C overflow vulnerabilities. The other taxonomies such as by Aslam (Aslam, 1995), Howard and Longstaff (Howard & Longstaff, 1998), Krsul (Krsul, 1998), Pothamsetty and Akyol (Pothamsetty & Akyol, 2004), Killourhy et. al. (Killourhy, Maxion, & Tan, 2004) and Hansmann and Hunt (Hansmann & Hunt, A Taxonomy of Network and Computer Attacks, 2005), despite covers many classes of C overflow vulnerabilities, is not specifics to C programming language and C overflow vulnerabilities. Their scopes are network, generic software vulnerabilities or web application vulnerabilities. Hence, their scopes are still broad and generic. For that reason, the C overflow vulnerabilities exploit taxonomy is more relevant and significant to developers whom use C as the programming language for coding. C overflow vulnerabilities exploit taxonomy covers 10 classes of C overflow vulnerabilities. It is the first taxonomy that covers all classes of C overflow vulnerabilities. The closest to this taxonomy is classifications by Tsipenyuk et. al. (Tsipenyuk, Chess, & McGraw, 2005) of which she listed seven overflow vulnerabilities classes in the year 2005. No doubt that all of the classes in our taxonomy have been identified earlier by many experts and well-established organization, but there is no works done to consolidate and organize the information into a taxonomy for ease of understanding and educated developers. Therefore, it is conclude that our taxonomy is comprehensive and up to date compare to previous works as it contains all relevant and significant classes of C overflow vulnerabilities
• #74: Legend High – Average of the classes is classified with high severity (between 6.0 – 10.0) Medium – Average of the classes is classified with medium severity (between 4.0 – 5.9) Low – Average of the classes is classified with low severity (between 1.0 – 3.9) NA – Not Available. Tester Based on the evaluation, it is found that users experience and knowledge plays an important role in identifying and classifying the C overflow vulnerabilities. The more experience in C programming and software security, the more correctness Albeit of user experiences and knowledge plays important role, the taxonomy do help improves the user understanding based on number of successful mapping increases compared between the first test iteration and the third test iteration. This also indicates that upon user understand the structures of the taxonomy, they are able to recognize and identify the vulnerabilities easily. On top of that, it is found that majority of mismatch or failure to map is due to unclear definition, limited information and confusing statement in the given reports, advisories or publications. Further analysis on the reports or advisories used for this evaluation does not have source code as references resulted in difficulties to do the matching process. As a result, we concluded that the failure of mapping or mismatch is not due to our taxonomy, but rather the source used for mapping process. Hence, based on responses, is is strongly believed that the taxonomy is well-defined and therefore useful for software developers to identify C overflow vulnerabilities in source code. In addition, compared to previous works in taxonomy area, this is the first evaluation done to evaluate a taxonomy against well-defined criteria. It is agreeable and noted that the number of testers is small and hence the result may not be a strong or concrete evidence. Nevertheless, the result can be a baseline for future validation and improvement on the taxonomy to ensure that it is meaningful and useful to software developers and software security community. On top of that, the method used to evaluate this taxonomy is also applicable to validate other taxonomy. Database As shown on the table, the taxonomy is well-defined and comprehensive as it completely covers all existing C overflow vulnerabilities since it was discovered and reported in the seven websites despite there are vulnerabilities was not seen on the site. This is because the scope of the site and numbers of advisories published. The result also shows that all these vulnerabilities are still significant and relevant with many of it still appearing and the CVSS score ranked at least medium. Persistency, Impact, and Severity As shown in the table, first three classes consistently and persistently ranked with high impact and high severity by all organizations. Additionally, these three C overflow vulnerabilities classes are persistent too with the latest advisory published for Array out-of-bound vulnerability class on the year 2014. Having mentioned that, there is also possibility without doubt that the other two high ranked vulnerabilities will appear as well in the year 2014. This is based on finding that there are advisories released at the end of year 2013 and the year 2014 is yet to end. The result also shows that pointer scaling/mixing and null termination does not appear in any of the list since late 2009. This could indicate that the two vulnerabilities are no longer relevant and significant to security community. However, further analysis brings us to a few significant findings. First, despite these two C overflow vulnerabilities classes does not appeared in any of organizations database, some of the advisories listed on the last identified year are still being revised and yet to complete. On top of that, as mentioned by Kaspersky, there are successful exploitations that utilize old vulnerability (Kaspersky Lab, 2013). Furthermore, there is possibility of the two vulnerabilities to appear on those organizations list again. This is due to there are other organization such as RedHat and HP published the vulnerabilities after the year 2009. As the result shows, first three vulnerabilities classes as arranged in hierarchy in C overflow vulnerabilities exploit taxonomy, is found to be ranked with high severity. Experts and well-known organization also consistently ranked the three classes with high severity. The result also shows that the last two classes was given a score of between low to medium severity, which indicates that the two C overflow vulnerabilities classes does not possess a high threat to security community. However, there are advisories of the three classes was ranked with medium or lower severity and the last two classes ranked with high severity. There are also advisories, which was given high severity in the first release, but later was revised with different severity level. There are many inputs contributes to the severity value. Detail analysis on advisories found that the severity is link with impact value, complexity to exploit, probability of being exploited and availability of fix or work around solution. On top of that, there are advisories/reports was later rejected nor completed and this too play important role on severity level of particular C overflow vulnerabilities class. Further analysis on the result also found that there is correlation between the severity and persistency. The more severe the vulnerability is, the more persistent it will be. On top of that, impact value plays important role on severity value too -> the more impact a vulnerability is, the more severe it will be.
• #75: Legend High – Average of the classes is classified with high severity (between 6.0 – 10.0) Medium – Average of the classes is classified with medium severity (between 4.0 – 5.9) Low – Average of the classes is classified with low severity (between 1.0 – 3.9) NA – Not Available. Tester Based on the evaluation, it is found that users experience and knowledge plays an important role in identifying and classifying the C overflow vulnerabilities. The more experience in C programming and software security, the more correctness Albeit of user experiences and knowledge plays important role, the taxonomy do help improves the user understanding based on number of successful mapping increases compared between the first test iteration and the third test iteration. This also indicates that upon user understand the structures of the taxonomy, they are able to recognize and identify the vulnerabilities easily. On top of that, it is found that majority of mismatch or failure to map is due to unclear definition, limited information and confusing statement in the given reports, advisories or publications. Further analysis on the reports or advisories used for this evaluation does not have source code as references resulted in difficulties to do the matching process. As a result, we concluded that the failure of mapping or mismatch is not due to our taxonomy, but rather the source used for mapping process. Hence, based on responses, is is strongly believed that the taxonomy is well-defined and therefore useful for software developers to identify C overflow vulnerabilities in source code. In addition, compared to previous works in taxonomy area, this is the first evaluation done to evaluate a taxonomy against well-defined criteria. It is agreeable and noted that the number of testers is small and hence the result may not be a strong or concrete evidence. Nevertheless, the result can be a baseline for future validation and improvement on the taxonomy to ensure that it is meaningful and useful to software developers and software security community. On top of that, the method used to evaluate this taxonomy is also applicable to validate other taxonomy. Database As shown on the table, the taxonomy is well-defined and comprehensive as it completely covers all existing C overflow vulnerabilities since it was discovered and reported in the seven websites despite there are vulnerabilities was not seen on the site. This is because the scope of the site and numbers of advisories published. The result also shows that all these vulnerabilities are still significant and relevant with many of it still appearing and the CVSS score ranked at least medium. Persistency, Impact, and Severity As shown in the table, first three classes consistently and persistently ranked with high impact and high severity by all organizations. Additionally, these three C overflow vulnerabilities classes are persistent too with the latest advisory published for Array out-of-bound vulnerability class on the year 2014. Having mentioned that, there is also possibility without doubt that the other two high ranked vulnerabilities will appear as well in the year 2014. This is based on finding that there are advisories released at the end of year 2013 and the year 2014 is yet to end. The result also shows that pointer scaling/mixing and null termination does not appear in any of the list since late 2009. This could indicate that the two vulnerabilities are no longer relevant and significant to security community. However, further analysis brings us to a few significant findings. First, despite these two C overflow vulnerabilities classes does not appeared in any of organizations database, some of the advisories listed on the last identified year are still being revised and yet to complete. On top of that, as mentioned by Kaspersky, there are successful exploitations that utilize old vulnerability (Kaspersky Lab, 2013). Furthermore, there is possibility of the two vulnerabilities to appear on those organizations list again. This is due to there are other organization such as RedHat and HP published the vulnerabilities after the year 2009. As the result shows, first three vulnerabilities classes as arranged in hierarchy in C overflow vulnerabilities exploit taxonomy, is found to be ranked with high severity. Experts and well-known organization also consistently ranked the three classes with high severity. The result also shows that the last two classes was given a score of between low to medium severity, which indicates that the two C overflow vulnerabilities classes does not possess a high threat to security community. However, there are advisories of the three classes was ranked with medium or lower severity and the last two classes ranked with high severity. There are also advisories, which was given high severity in the first release, but later was revised with different severity level. There are many inputs contributes to the severity value. Detail analysis on advisories found that the severity is link with impact value, complexity to exploit, probability of being exploited and availability of fix or work around solution. On top of that, there are advisories/reports was later rejected nor completed and this too play important role on severity level of particular C overflow vulnerabilities class. Further analysis on the result also found that there is correlation between the severity and persistency. The more severe the vulnerability is, the more persistent it will be. On top of that, impact value plays important role on severity value too -> the more impact a vulnerability is, the more severe it will be.
• #76: Legend High – Average of the classes is classified with high severity (between 6.0 – 10.0) Medium – Average of the classes is classified with medium severity (between 4.0 – 5.9) Low – Average of the classes is classified with low severity (between 1.0 – 3.9) NA – Not Available. Tester Based on the evaluation, it is found that users experience and knowledge plays an important role in identifying and classifying the C overflow vulnerabilities. The more experience in C programming and software security, the more correctness Albeit of user experiences and knowledge plays important role, the taxonomy do help improves the user understanding based on number of successful mapping increases compared between the first test iteration and the third test iteration. This also indicates that upon user understand the structures of the taxonomy, they are able to recognize and identify the vulnerabilities easily. On top of that, it is found that majority of mismatch or failure to map is due to unclear definition, limited information and confusing statement in the given reports, advisories or publications. Further analysis on the reports or advisories used for this evaluation does not have source code as references resulted in difficulties to do the matching process. As a result, we concluded that the failure of mapping or mismatch is not due to our taxonomy, but rather the source used for mapping process. Hence, based on responses, is is strongly believed that the taxonomy is well-defined and therefore useful for software developers to identify C overflow vulnerabilities in source code. In addition, compared to previous works in taxonomy area, this is the first evaluation done to evaluate a taxonomy against well-defined criteria. It is agreeable and noted that the number of testers is small and hence the result may not be a strong or concrete evidence. Nevertheless, the result can be a baseline for future validation and improvement on the taxonomy to ensure that it is meaningful and useful to software developers and software security community. On top of that, the method used to evaluate this taxonomy is also applicable to validate other taxonomy. Database As shown on the table, the taxonomy is well-defined and comprehensive as it completely covers all existing C overflow vulnerabilities since it was discovered and reported in the seven websites despite there are vulnerabilities was not seen on the site. This is because the scope of the site and numbers of advisories published. The result also shows that all these vulnerabilities are still significant and relevant with many of it still appearing and the CVSS score ranked at least medium. Persistency, Impact, and Severity As shown in the table, first three classes consistently and persistently ranked with high impact and high severity by all organizations. Additionally, these three C overflow vulnerabilities classes are persistent too with the latest advisory published for Array out-of-bound vulnerability class on the year 2014. Having mentioned that, there is also possibility without doubt that the other two high ranked vulnerabilities will appear as well in the year 2014. This is based on finding that there are advisories released at the end of year 2013 and the year 2014 is yet to end. The result also shows that pointer scaling/mixing and null termination does not appear in any of the list since late 2009. This could indicate that the two vulnerabilities are no longer relevant and significant to security community. However, further analysis brings us to a few significant findings. First, despite these two C overflow vulnerabilities classes does not appeared in any of organizations database, some of the advisories listed on the last identified year are still being revised and yet to complete. On top of that, as mentioned by Kaspersky, there are successful exploitations that utilize old vulnerability (Kaspersky Lab, 2013). Furthermore, there is possibility of the two vulnerabilities to appear on those organizations list again. This is due to there are other organization such as RedHat and HP published the vulnerabilities after the year 2009. As the result shows, first three vulnerabilities classes as arranged in hierarchy in C overflow vulnerabilities exploit taxonomy, is found to be ranked with high severity. Experts and well-known organization also consistently ranked the three classes with high severity. The result also shows that the last two classes was given a score of between low to medium severity, which indicates that the two C overflow vulnerabilities classes does not possess a high threat to security community. However, there are advisories of the three classes was ranked with medium or lower severity and the last two classes ranked with high severity. There are also advisories, which was given high severity in the first release, but later was revised with different severity level. There are many inputs contributes to the severity value. Detail analysis on advisories found that the severity is link with impact value, complexity to exploit, probability of being exploited and availability of fix or work around solution. On top of that, there are advisories/reports was later rejected nor completed and this too play important role on severity level of particular C overflow vulnerabilities class. Further analysis on the result also found that there is correlation between the severity and persistency. The more severe the vulnerability is, the more persistent it will be. On top of that, impact value plays important role on severity value too -> the more impact a vulnerability is, the more severe it will be.
• #77: Legend High – Average of the classes is classified with high severity (between 6.0 – 10.0) Medium – Average of the classes is classified with medium severity (between 4.0 – 5.9) Low – Average of the classes is classified with low severity (between 1.0 – 3.9) NA – Not Available. Tester Based on the evaluation, it is found that users experience and knowledge plays an important role in identifying and classifying the C overflow vulnerabilities. The more experience in C programming and software security, the more correctness Albeit of user experiences and knowledge plays important role, the taxonomy do help improves the user understanding based on number of successful mapping increases compared between the first test iteration and the third test iteration. This also indicates that upon user understand the structures of the taxonomy, they are able to recognize and identify the vulnerabilities easily. On top of that, it is found that majority of mismatch or failure to map is due to unclear definition, limited information and confusing statement in the given reports, advisories or publications. Further analysis on the reports or advisories used for this evaluation does not have source code as references resulted in difficulties to do the matching process. As a result, we concluded that the failure of mapping or mismatch is not due to our taxonomy, but rather the source used for mapping process. Hence, based on responses, is is strongly believed that the taxonomy is well-defined and therefore useful for software developers to identify C overflow vulnerabilities in source code. In addition, compared to previous works in taxonomy area, this is the first evaluation done to evaluate a taxonomy against well-defined criteria. It is agreeable and noted that the number of testers is small and hence the result may not be a strong or concrete evidence. Nevertheless, the result can be a baseline for future validation and improvement on the taxonomy to ensure that it is meaningful and useful to software developers and software security community. On top of that, the method used to evaluate this taxonomy is also applicable to validate other taxonomy. Database As shown on the table, the taxonomy is well-defined and comprehensive as it completely covers all existing C overflow vulnerabilities since it was discovered and reported in the seven websites despite there are vulnerabilities was not seen on the site. This is because the scope of the site and numbers of advisories published. The result also shows that all these vulnerabilities are still significant and relevant with many of it still appearing and the CVSS score ranked at least medium. Persistency, Impact, and Severity As shown in the table, first three classes consistently and persistently ranked with high impact and high severity by all organizations. Additionally, these three C overflow vulnerabilities classes are persistent too with the latest advisory published for Array out-of-bound vulnerability class on the year 2014. Having mentioned that, there is also possibility without doubt that the other two high ranked vulnerabilities will appear as well in the year 2014. This is based on finding that there are advisories released at the end of year 2013 and the year 2014 is yet to end. The result also shows that pointer scaling/mixing and null termination does not appear in any of the list since late 2009. This could indicate that the two vulnerabilities are no longer relevant and significant to security community. However, further analysis brings us to a few significant findings. First, despite these two C overflow vulnerabilities classes does not appeared in any of organizations database, some of the advisories listed on the last identified year are still being revised and yet to complete. On top of that, as mentioned by Kaspersky, there are successful exploitations that utilize old vulnerability (Kaspersky Lab, 2013). Furthermore, there is possibility of the two vulnerabilities to appear on those organizations list again. This is due to there are other organization such as RedHat and HP published the vulnerabilities after the year 2009. As the result shows, first three vulnerabilities classes as arranged in hierarchy in C overflow vulnerabilities exploit taxonomy, is found to be ranked with high severity. Experts and well-known organization also consistently ranked the three classes with high severity. The result also shows that the last two classes was given a score of between low to medium severity, which indicates that the two C overflow vulnerabilities classes does not possess a high threat to security community. However, there are advisories of the three classes was ranked with medium or lower severity and the last two classes ranked with high severity. There are also advisories, which was given high severity in the first release, but later was revised with different severity level. There are many inputs contributes to the severity value. Detail analysis on advisories found that the severity is link with impact value, complexity to exploit, probability of being exploited and availability of fix or work around solution. On top of that, there are advisories/reports was later rejected nor completed and this too play important role on severity level of particular C overflow vulnerabilities class. Further analysis on the result also found that there is correlation between the severity and persistency. The more severe the vulnerability is, the more persistent it will be. On top of that, impact value plays important role on severity value too -> the more impact a vulnerability is, the more severe it will be.
• #78: Legend High – Average of the classes is classified with high severity (between 6.0 – 10.0) Medium – Average of the classes is classified with medium severity (between 4.0 – 5.9) Low – Average of the classes is classified with low severity (between 1.0 – 3.9) NA – Not Available. Tester Based on the evaluation, it is found that users experience and knowledge plays an important role in identifying and classifying the C overflow vulnerabilities. The more experience in C programming and software security, the more correctness Albeit of user experiences and knowledge plays important role, the taxonomy do help improves the user understanding based on number of successful mapping increases compared between the first test iteration and the third test iteration. This also indicates that upon user understand the structures of the taxonomy, they are able to recognize and identify the vulnerabilities easily. On top of that, it is found that majority of mismatch or failure to map is due to unclear definition, limited information and confusing statement in the given reports, advisories or publications. Further analysis on the reports or advisories used for this evaluation does not have source code as references resulted in difficulties to do the matching process. As a result, we concluded that the failure of mapping or mismatch is not due to our taxonomy, but rather the source used for mapping process. Hence, based on responses, is is strongly believed that the taxonomy is well-defined and therefore useful for software developers to identify C overflow vulnerabilities in source code. In addition, compared to previous works in taxonomy area, this is the first evaluation done to evaluate a taxonomy against well-defined criteria. It is agreeable and noted that the number of testers is small and hence the result may not be a strong or concrete evidence. Nevertheless, the result can be a baseline for future validation and improvement on the taxonomy to ensure that it is meaningful and useful to software developers and software security community. On top of that, the method used to evaluate this taxonomy is also applicable to validate other taxonomy. Database As shown on the table, the taxonomy is well-defined and comprehensive as it completely covers all existing C overflow vulnerabilities since it was discovered and reported in the seven websites despite there are vulnerabilities was not seen on the site. This is because the scope of the site and numbers of advisories published. The result also shows that all these vulnerabilities are still significant and relevant with many of it still appearing and the CVSS score ranked at least medium. Persistency, Impact, and Severity As shown in the table, first three classes consistently and persistently ranked with high impact and high severity by all organizations. Additionally, these three C overflow vulnerabilities classes are persistent too with the latest advisory published for Array out-of-bound vulnerability class on the year 2014. Having mentioned that, there is also possibility without doubt that the other two high ranked vulnerabilities will appear as well in the year 2014. This is based on finding that there are advisories released at the end of year 2013 and the year 2014 is yet to end. The result also shows that pointer scaling/mixing and null termination does not appear in any of the list since late 2009. This could indicate that the two vulnerabilities are no longer relevant and significant to security community. However, further analysis brings us to a few significant findings. First, despite these two C overflow vulnerabilities classes does not appeared in any of organizations database, some of the advisories listed on the last identified year are still being revised and yet to complete. On top of that, as mentioned by Kaspersky, there are successful exploitations that utilize old vulnerability (Kaspersky Lab, 2013). Furthermore, there is possibility of the two vulnerabilities to appear on those organizations list again. This is due to there are other organization such as RedHat and HP published the vulnerabilities after the year 2009. As the result shows, first three vulnerabilities classes as arranged in hierarchy in C overflow vulnerabilities exploit taxonomy, is found to be ranked with high severity. Experts and well-known organization also consistently ranked the three classes with high severity. The result also shows that the last two classes was given a score of between low to medium severity, which indicates that the two C overflow vulnerabilities classes does not possess a high threat to security community. However, there are advisories of the three classes was ranked with medium or lower severity and the last two classes ranked with high severity. There are also advisories, which was given high severity in the first release, but later was revised with different severity level. There are many inputs contributes to the severity value. Detail analysis on advisories found that the severity is link with impact value, complexity to exploit, probability of being exploited and availability of fix or work around solution. On top of that, there are advisories/reports was later rejected nor completed and this too play important role on severity level of particular C overflow vulnerabilities class. Further analysis on the result also found that there is correlation between the severity and persistency. The more severe the vulnerability is, the more persistent it will be. On top of that, impact value plays important role on severity value too -> the more impact a vulnerability is, the more severe it will be.
• #79: Without any doubt, has shown that all of the selected OS are still vulnerable. Although Windows XP 32-bits OS is end-of-life (EOL) and the support by Microsoft ended on April 2014, the number of users using the OS is significantly still many compared to other OS such as Linux and Windows 8 (StatCounter, 2014), (Awio Web Services LLC, 2014), (Sharwood, 2014) and (Net Applications.com, 2014). Hence, the impact of exploiting the OS is still significant and substantially critical. With the result shown, it is absolute critical to provide effective security mechanism or replace the OS as soon as possible to avoid unnecessary risk. On top of that, it is highly critical for Microsoft to improve their OS security mechanism and provide effective protection against vulnerable programs or applications. As shown in the result, all C overflow vulnerabilities classes are still relevant and can be exploited in this operating system without failed. There is no doubt that the complexity of exploiting the vulnerability is increase especially for 64-bits OS, but it cannot be used to justify that the protection provided in the OS is enough. It is shown in the table that it requires a few numbers of trial for an exploit to be successful and overflow to happen. The result also that many of the vulnerabilities are exceptionally easy to exploit. This is because the vulnerabilities are easily identified from the source code or from the behaviour of the programs based on try-and-error concept. 74 bits OS is difficult to exploit. There are many reasons contributes to the difficulties of triggering overflow in Windows 7 64-bits operating system. The operating system was built with different architecture and foundation compare to its ancestor. The operating system implements n64 bytes of addressing and memory structures and randomize memory allocation of which causing difficulties to find the suitable slot for triggering overflow. Therefore, although the operating system is highly critical and defenceless from C overflow vulnerabilities; the process of exploiting the vulnerabilities is significantly difficult too compared to its ancestor; Windows XP, and its competitor; that is Linux-based operating system. From the result achieved in this evaluation, it is also concluded that all C overflow vulnerabilities are still relevant and significant and the classes constructed in C overflow vulnerabilities exploit taxonomy is useful for security community to evaluate the secureness of the operating systems.
• #80: Without any doubt, has shown that all of the selected OS are still vulnerable. Although Windows XP 32-bits OS is end-of-life (EOL) and the support by Microsoft ended on April 2014, the number of users using the OS is significantly still many compared to other OS such as Linux and Windows 8 (StatCounter, 2014), (Awio Web Services LLC, 2014), (Sharwood, 2014) and (Net Applications.com, 2014). Hence, the impact of exploiting the OS is still significant and substantially critical. With the result shown, it is absolute critical to provide effective security mechanism or replace the OS as soon as possible to avoid unnecessary risk. On top of that, it is highly critical for Microsoft to improve their OS security mechanism and provide effective protection against vulnerable programs or applications. As shown in the result, all C overflow vulnerabilities classes are still relevant and can be exploited in this operating system without failed. There is no doubt that the complexity of exploiting the vulnerability is increase especially for 64-bits OS, but it cannot be used to justify that the protection provided in the OS is enough. It is shown in the table that it requires a few numbers of trial for an exploit to be successful and overflow to happen. The result also that many of the vulnerabilities are exceptionally easy to exploit. This is because the vulnerabilities are easily identified from the source code or from the behaviour of the programs based on try-and-error concept. 74 bits OS is difficult to exploit. There are many reasons contributes to the difficulties of triggering overflow in Windows 7 64-bits operating system. The operating system was built with different architecture and foundation compare to its ancestor. The operating system implements n64 bytes of addressing and memory structures and randomize memory allocation of which causing difficulties to find the suitable slot for triggering overflow. Therefore, although the operating system is highly critical and defenceless from C overflow vulnerabilities; the process of exploiting the vulnerabilities is significantly difficult too compared to its ancestor; Windows XP, and its competitor; that is Linux-based operating system. From the result achieved in this evaluation, it is also concluded that all C overflow vulnerabilities are still relevant and significant and the classes constructed in C overflow vulnerabilities exploit taxonomy is useful for security community to evaluate the secureness of the operating systems.
• #81: Without any doubt, has shown that all of the selected OS are still vulnerable. Although Windows XP 32-bits OS is end-of-life (EOL) and the support by Microsoft ended on April 2014, the number of users using the OS is significantly still many compared to other OS such as Linux and Windows 8 (StatCounter, 2014), (Awio Web Services LLC, 2014), (Sharwood, 2014) and (Net Applications.com, 2014). Hence, the impact of exploiting the OS is still significant and substantially critical. With the result shown, it is absolute critical to provide effective security mechanism or replace the OS as soon as possible to avoid unnecessary risk. On top of that, it is highly critical for Microsoft to improve their OS security mechanism and provide effective protection against vulnerable programs or applications. As shown in the result, all C overflow vulnerabilities classes are still relevant and can be exploited in this operating system without failed. There is no doubt that the complexity of exploiting the vulnerability is increase especially for 64-bits OS, but it cannot be used to justify that the protection provided in the OS is enough. It is shown in the table that it requires a few numbers of trial for an exploit to be successful and overflow to happen. The result also that many of the vulnerabilities are exceptionally easy to exploit. This is because the vulnerabilities are easily identified from the source code or from the behaviour of the programs based on try-and-error concept. 74 bits OS is difficult to exploit. There are many reasons contributes to the difficulties of triggering overflow in Windows 7 64-bits operating system. The operating system was built with different architecture and foundation compare to its ancestor. The operating system implements n64 bytes of addressing and memory structures and randomize memory allocation of which causing difficulties to find the suitable slot for triggering overflow. Therefore, although the operating system is highly critical and defenceless from C overflow vulnerabilities; the process of exploiting the vulnerabilities is significantly difficult too compared to its ancestor; Windows XP, and its competitor; that is Linux-based operating system. From the result achieved in this evaluation, it is also concluded that all C overflow vulnerabilities are still relevant and significant and the classes constructed in C overflow vulnerabilities exploit taxonomy is useful for security community to evaluate the secureness of the operating systems.
• #82: Without any doubt, has shown that all of the selected OS are still vulnerable. Although Windows XP 32-bits OS is end-of-life (EOL) and the support by Microsoft ended on April 2014, the number of users using the OS is significantly still many compared to other OS such as Linux and Windows 8 (StatCounter, 2014), (Awio Web Services LLC, 2014), (Sharwood, 2014) and (Net Applications.com, 2014). Hence, the impact of exploiting the OS is still significant and substantially critical. With the result shown, it is absolute critical to provide effective security mechanism or replace the OS as soon as possible to avoid unnecessary risk. On top of that, it is highly critical for Microsoft to improve their OS security mechanism and provide effective protection against vulnerable programs or applications. As shown in the result, all C overflow vulnerabilities classes are still relevant and can be exploited in this operating system without failed. There is no doubt that the complexity of exploiting the vulnerability is increase especially for 64-bits OS, but it cannot be used to justify that the protection provided in the OS is enough. It is shown in the table that it requires a few numbers of trial for an exploit to be successful and overflow to happen. The result also that many of the vulnerabilities are exceptionally easy to exploit. This is because the vulnerabilities are easily identified from the source code or from the behaviour of the programs based on try-and-error concept. 74 bits OS is difficult to exploit. There are many reasons contributes to the difficulties of triggering overflow in Windows 7 64-bits operating system. The operating system was built with different architecture and foundation compare to its ancestor. The operating system implements n64 bytes of addressing and memory structures and randomize memory allocation of which causing difficulties to find the suitable slot for triggering overflow. Therefore, although the operating system is highly critical and defenceless from C overflow vulnerabilities; the process of exploiting the vulnerabilities is significantly difficult too compared to its ancestor; Windows XP, and its competitor; that is Linux-based operating system. From the result achieved in this evaluation, it is also concluded that all C overflow vulnerabilities are still relevant and significant and the classes constructed in C overflow vulnerabilities exploit taxonomy is useful for security community to evaluate the secureness of the operating systems.
• #83: Without any doubt, has shown that all of the selected OS are still vulnerable. Although Windows XP 32-bits OS is end-of-life (EOL) and the support by Microsoft ended on April 2014, the number of users using the OS is significantly still many compared to other OS such as Linux and Windows 8 (StatCounter, 2014), (Awio Web Services LLC, 2014), (Sharwood, 2014) and (Net Applications.com, 2014). Hence, the impact of exploiting the OS is still significant and substantially critical. With the result shown, it is absolute critical to provide effective security mechanism or replace the OS as soon as possible to avoid unnecessary risk. On top of that, it is highly critical for Microsoft to improve their OS security mechanism and provide effective protection against vulnerable programs or applications. As shown in the result, all C overflow vulnerabilities classes are still relevant and can be exploited in this operating system without failed. There is no doubt that the complexity of exploiting the vulnerability is increase especially for 64-bits OS, but it cannot be used to justify that the protection provided in the OS is enough. It is shown in the table that it requires a few numbers of trial for an exploit to be successful and overflow to happen. The result also that many of the vulnerabilities are exceptionally easy to exploit. This is because the vulnerabilities are easily identified from the source code or from the behaviour of the programs based on try-and-error concept. 74 bits OS is difficult to exploit. There are many reasons contributes to the difficulties of triggering overflow in Windows 7 64-bits operating system. The operating system was built with different architecture and foundation compare to its ancestor. The operating system implements n64 bytes of addressing and memory structures and randomize memory allocation of which causing difficulties to find the suitable slot for triggering overflow. Therefore, although the operating system is highly critical and defenceless from C overflow vulnerabilities; the process of exploiting the vulnerabilities is significantly difficult too compared to its ancestor; Windows XP, and its competitor; that is Linux-based operating system. From the result achieved in this evaluation, it is also concluded that all C overflow vulnerabilities are still relevant and significant and the classes constructed in C overflow vulnerabilities exploit taxonomy is useful for security community to evaluate the secureness of the operating systems.
• #84: Without any doubt, has shown that all of the selected OS are still vulnerable. Although Windows XP 32-bits OS is end-of-life (EOL) and the support by Microsoft ended on April 2014, the number of users using the OS is significantly still many compared to other OS such as Linux and Windows 8 (StatCounter, 2014), (Awio Web Services LLC, 2014), (Sharwood, 2014) and (Net Applications.com, 2014). Hence, the impact of exploiting the OS is still significant and substantially critical. With the result shown, it is absolute critical to provide effective security mechanism or replace the OS as soon as possible to avoid unnecessary risk. On top of that, it is highly critical for Microsoft to improve their OS security mechanism and provide effective protection against vulnerable programs or applications. As shown in the result, all C overflow vulnerabilities classes are still relevant and can be exploited in this operating system without failed. There is no doubt that the complexity of exploiting the vulnerability is increase especially for 64-bits OS, but it cannot be used to justify that the protection provided in the OS is enough. It is shown in the table that it requires a few numbers of trial for an exploit to be successful and overflow to happen. The result also that many of the vulnerabilities are exceptionally easy to exploit. This is because the vulnerabilities are easily identified from the source code or from the behaviour of the programs based on try-and-error concept. 74 bits OS is difficult to exploit. There are many reasons contributes to the difficulties of triggering overflow in Windows 7 64-bits operating system. The operating system was built with different architecture and foundation compare to its ancestor. The operating system implements n64 bytes of addressing and memory structures and randomize memory allocation of which causing difficulties to find the suitable slot for triggering overflow. Therefore, although the operating system is highly critical and defenceless from C overflow vulnerabilities; the process of exploiting the vulnerabilities is significantly difficult too compared to its ancestor; Windows XP, and its competitor; that is Linux-based operating system. From the result achieved in this evaluation, it is also concluded that all C overflow vulnerabilities are still relevant and significant and the classes constructed in C overflow vulnerabilities exploit taxonomy is useful for security community to evaluate the secureness of the operating systems.