ABSTRACT
Static analysis can detect a variety of defects and weaknesses in system source codes even before the code is ready to run. Runtime analysis on the other hand, looks at running software to detect problems as these occur, usually through sophisticated instrumentation. Static analysis prevents problems from entering the main code stream and ensures that any new code is up to standard. Static analysis tools can uncover security vulnerabilities, logic errors, implementation defects, and other problems, both at developer’s desktop and at system build time. Runtime analysis can be performed during module development and system integration to catch any problem missed by static analysis. In this research work, Vulnerability analysis was performed on some developed source codes with some security vulnerabilities. The analysis report supports the fact that one can expect certain number of false alarm in all vulnerability analysis tools. This research work therefore focuses on finding out a mathematical model on how to determine the probability of detection and the probability of false alarm for a given analysis tool. This information will guide the users of the tool to determine the authenticity of the detected bug. It will also help the developers to access and improve the performance of the analysis tool.
TABLE OF CONTENTS
Approval Page- – – – – – – – – – -i
Declaration – – – – – – – – – – -ii
Acknowledgement- – – – – – – – – -iii
Dedication- – – – – – – – – – – -iv
Table of Contents- – – – – – – – – – -v
Abstract- – – – – – – – – – – -ix
CHAPTER ONE INTRODUCTION
Introduction- – – – – – – – – – -1
CHAPTER TWO LITERATURE REVIEW
Literature Review- – – – – – – – – – -4
Early detection for lower development cost- – – – – – -10
Static analysis techniques- – – – – – – – -10
Static analysis workflow- – – – – – – – – -12
Runtime analysis techniques- – – – – – – – -13
Runtime library instrumentation- – – – – – – -14
Runtime analysis workflow- – – – – – – – -15
Overview of software vulnerability- – – – – – – -17
Static analysis for vulnerability detection- – – – – – -20
Approaches to vulnerability analysis – – – – – – -21
Static analysis tools- – – – – – – – – -26
Runtime analysis tools- – – – – – – – – -30
Classification of software vulnerabilities- – – – – – -32
Approaches to vulnerability detection- – – – – – – -40
CHAPTER THREE METHODOLOGY
Methodology- – – – – – – – – – -44
Sample Codes- – – – – – – – – – -45
CHAPTER FOUR ANALYSIS OF RESULT
Analysis of result- – – – – – – – – – -49
Determination of the performance of the analytical tools- – – – -49
Result of performing vulnerability analysis with Vulncheck- – – -49
Result of performing vulnerability analysis with SPLINT– – – -51
Result of performing vulnerability analysis with Flawfinder (default configuration)- – – – – – – – – – -52
Result of performing vulnerability analysis with Flawfinder
(Minlevel = 3)- – – – – – – – – – -54
Result of performing vulnerability analysis with
Flawfinder (F- Option)- – – – – – – – – -55
Determination of the probability of detection and false alarm
by analytical tools- – – – – – – – – – -56
Computation of the probability of detection and false alarm by
the analytical tools – – – – – – – – – -58
Operating characteristics curve of the analytical tools- – – – -60
CHAPTER FIVE CONCLUSION AND RECOMMENDATIONS
Conclusion- – – – – – – – – – – -62
Recommendations- – – – – – – – – -62
REFERENCES– – – – – – – – – – -65
LIST OF TABLES
Potential vulnerable functions and language construct- – – – -40
Result of performing vulnerability analysis with vulncheck- – – -49
Result of performing vulnerability analysis with SPLINT- – – -51
Result of performing vulnerability analysis with Flawfinder (default configuration)- – – – – – – – – – -52
Result of performing vulnerability analysis with Flawfinder
(Minlevel = 3)- – – – – – – – – – -54
Result of performing vulnerability analysis with Flawfinder
(F-Option)- – – – – – – – – – – -55
Performance analysis table- – – – – – – – -59
LIST OF CODES
Example of buffer overflow- – – – – – – – -17
Example of format string bugs- – – – – – – – -18
Integer overflow- – – – – – – – – – -19
Classic string buffer overflow- – – – – – – – -33
Memcpy buffer overflow- – – – – – – – -34
Format string bug- – – – – – – – – – -34
Out of bound array access- – – – – – – – -35
Out of bound array access with a negative array index- – – – -36
Arithmetic overflow when allocating an array of objects- – – – -36
Signed to unsigned conversion- – – – – – – – -37
Scan buffer overflow- – – – – – – – – -37
Gets buffer overflow- – – – – – – – – -38
Vuln1.c code- – – – – – – – – – -45
Vuln2.c code- – – – – – – – – – -45
Vuln3.c code- – – – – – – – – – -46
Vuln4.c code- – – – – – – – – – -47
Vuln5.c code- – – – – – – – – – -48
CHAPTER ONE
- INTRODUCTION
1.1 Introduction
Software engineering has evolved to a stage where security attributes of software are playing increasingly important role. Introduction of e-commerce, m-commerce, online banking and other web based applications have resulted to a whole new set of requirements for information systems. In addition to reliability, performance and other quality attributes, the level of system security is playing a major role when customers are making buying decisions. For this reason; there is an obvious need for a special consideration of system security when designing software products especially for higher security applications.
The current state of application security leaves much to be desired. The 2002 computer crime and security survey [1] conducted by the Computer Security Institute and the United State’s FBI revealed that, on yearly bases, that over half of all data bases experience at least one security breach and an average episode result in close to $4 million in losses. The survey also noted that web crime has become common place. Web crime ranges from cyber-vandalism (e.g., website defacement) at the low end, to theft of sensitive information and financial fraud at the high end.
A penetration testing study performed by the Imperva Application Defense Center [2] included more than 250 web application from e-commerce, online banking and enterprises collaboration sites. This vulnerability assessment concluded that at least 92% of web applications are vulnerable to some form of hacker attacks. Security compliance of application vendors is especially important in light of recent U.S. industry regulations such as the Sarbanes-Oxley act pertaining the information
security [3, 4]. According to the 2005 e-crime watch conducted in cooperation with the United State secret service, 43% of respondents reported an increase in e-crimes and intrusion over the previous year [5]. Over 70% of respondent reported that at least one e-crime or intrusion was committed against their organization. During the first six months of 2005; malicious codes that exposed confidential information represented 74% of the 50 malicious code samples, according to Symantec’s internet security threat report volume III [6]. The report also documents 1,872 vulnerabilities in the first half of 2005, the most ever recorded since the inception of the report. Despite this sampling of data pointing to the increasing threat of directed attacks, the threat is likely still understated. Many directed attacks go unreported for the following reasons:
- Many organizations try to suppress the fact that they were attacked in the hope of avoiding negative publicity and damage to their reputation.
- Many organizations that have been attacked simply do not know that they have been the victim of a targeted attack.
While a great deal of attention over the decades have been given to network-level attacks such as port scanning, about 75% of all attacks against web servers, target web based applications, according to a resent survey [7]. It is easy to underestimate the potential level of risk associated with sensitive information within the data bases accessed through web applications until a severe security breach actually occurs.
Analyzing reports of security attacks quickly reveals that most attacks do not result from clever attackers discovering new kinds of flaws, but rather stem from repeated exploits of well-known problems.
In Mitre’s Common Vulnerabilities and Exposures list of 190 entries from 1st January 2001 through 18th September 2001, thirty-seven of these entries are standard buffer overflow vulnerabilities (including three related memory-access vulnerabilities), and 11 involve format bugs [8]. Most of the rest also reveal common flaws which include resource leaks, file name problems, and symbolic links. Analyses of other vulnerability and incident reports reveal similar repetition. So why do developers keep making the same mistakes? Some errors are caused by legacy code, others by programmers’ carelessness or lack of awareness about security concerns. However, the root problem is that while security vulnerabilities such as buffer overflows are well understood, the techniques for avoiding them totally are not well codified into the development process. Even conscientious programmers can overlook security issues, especially those that rely on undocumented assumptions about procedures and data types. Instead of relying on programmers’ memories, the security industry has produced tools that codify what is known about common security vulnerabilities that can be integrated directly into the development process to detect software vulnerabilities. This paper proposes how the efficiency of the tools can be maximized.
Do you need help? Talk to us right now: (+234) 08060082010, 08107932631 (Call/WhatsApp). Email: [email protected].
IF YOU CAN'T FIND YOUR TOPIC, CLICK HERE TO HIRE A WRITER»
