A survey of static analysis methods for identifying security vulnerabilities in software systems <s> Integrity <s> This paper shows how system-specific static analysis can find security errors that violate rules such as "integers from untrusted sources must be sanitized before use" and "do not dereference user-supplied pointers." In our approach, programmers write system-specific extensions that are linked into the compiler and check their code for errors. We demonstrate the approach's effectiveness by using it to find over 100 security errors in Linux and OpenBSD, over 50 of which have led to kernel patches. An unusual feature of our approach is the use of methods to automatically detect when we miss code actions that should be checked. <s> BIB001 </s> A survey of static analysis methods for identifying security vulnerabilities in software systems <s> Integrity <s> Software vulnerabilities have had a devastating effect on the Internet. Worms such as CodeRed and Slammer can compromise hundreds of thousands of hosts within hours or even minutes, and cause millions of dollars of damage [26, 43]. To successfully combat these fast automatic Internet attacks, we need fast automatic attack detection and filtering mechanisms. In this paper we propose dynamic taint analysis for automatic detection of overwrite attacks, which include most types of exploits. This approach does not need source code or special compilation for the monitored program, and hence works on commodity software. To demonstrate this idea, we have implemented TaintCheck, a mechanism that can perform dynamic taint analysis by performing binary rewriting at run time. We show that TaintCheck reliably detects most types of exploits. We found that TaintCheck produced no false positives for any of the many different programs that we tested. Further, we describe how TaintCheck could improve automatic signature generation in <s> BIB002
The data that originate from an untrusted source is referred to as tainted. BIB002 Tainted data and the variables that hold or reference it can be maliciously used for overwrite attacks, address. Sometimes, however, it is necessary to use a tainted variable in a trusted environment when restricted resources are accessed. In such cases, the data can be endorsed by performing sanity checks on it before using it in restricted operations. BIB001 Sanity checks are usually domain or component specific. For example, the SQL query in Figure 5 needs to perform a security-sensitive operation based on input coming from a user. If the program did not validate user inputs, a malicious client could call submit Query passing " ' ' OR '1' ¼ '1' " as the value of the password parameter, causing the password check in the SQL query to become password ¼ " ' ' OR '1' ¼ '1' ", which always succeeds. In SBAC systems, integrity issues commonly arise in the context of privilege-asserting code. The requirement for integrity establishes that no value defined in untrusted code should ever be used inside privilege-asserting code unless that value has been previously endorsed. In an SBAC system, a tainted variable is not necessarily a security problem. It may constitute a security problem if it is also a privileged variable, meaning that it is used inside privilegeasserting code.  Figure 2 , variable logFileName is not tainted because its value cannot be set by a client application. In RBAC systems, integrity violations can arise due to incorrectly specified principal-delegation policies. A principal-delegation policy overwrites the roles granted to the executing user with the roles specified by the policy itself. From that point on, the execution of all the cascading calls will be performed as if the user had been granted the roles specified by the principal-delegation policy. A principal-delegation policy is often used to elevate, in special circumstances, the authority of the users executing the program, without making it necessary to grant those users roles that would allow them to execute unintended operations. For example, in the scenario of Figure 4 , the principal-delegation policy associated with the component of methods m 1 and m 4 assigns user bob the role of Manager, which is required to invoke m 3 . This principal-delegation policy has made it unnecessary to grant user bob the role of Manager, which could have been misused. The integrity requirement establishes that no value defined by the user be used after the user's authority has been elevated unless that value has been previously endorsed.