Analysis of integer range limitations of buffer overflow vulnerability excavation
Author: brief
E-mail: brief #
FZ5FZ.org
Website:
http://www.fz5fz.org
Website:
http://www.safechina.net
Date: 05-03-2004
--[ table of Contents
1 Introduction
2 - Prototype introduction
3 - integer limitation
4 - integer limit resolution
5 Conclusion
6 - Reference
7 - About
--[ 1 Introduction
There is really no new thing, right, regardless of reading notes.
Software buffer overflow vulnerability excavation technology is primarily for advanced language source code or assembly code, which is mainly used to apply some open source systems or system developers before or after software release. Here we discuss the problem of discovering the software buffer overflow vulnerability, and only for C language source code. For more than the scope restricted buffer overflow vulnerability exploration technology, please refer to [1] for details.
I believe that everyone has a certain understanding of the problem of software buffer overflow, which is not described in detail here. Domestic friends can get some relevant technical literature in [2] and [3], or browse the latest buffer overflow vulnerability information in [4].
- [2 - Profile
Buffer overflow vulnerability exploration technology based on static source code analysis, which can discover a number of security issues in the development phase, and can also discover some software vulnerabilities for open source systems. They are primarily targeted by the program analysis of source code, including some compilation principles related knowledge, such as grammar analysis, semantic analysis, etc.
The excavation prototypes of integer ranges include program source code analysis, mathematical construction, system security, etc. related content. The first is a special analysis of the C language source code, and then generate an integer range limit, and finally analyzes the resulting restrictions to filter the code in which security issues. See [5] for a simple introduction.
As a prototype, there should be a certain practical value. This prototype is exactly in the pain after the actual work analysis. The excavation prototypes of integer ranges also have some related accuracy issues, false positive and false negative. The so-called false positives are erroneous warnings; false negatives are missing security vulnerabilities. That is, our popularity and leaks are said. As a fold, it chose the relative balance between accuracy and measuring measurement, which increases the feasibility of actual large system analysis.
In the prototype, two new perspectives are proposed:
(1) Align the C string as an abstract data type;
(2) Converse the buffer as an integer range, including allocation range and range of use;
The buffer length assigned to the string variable is defined as Alloc (s), and the buffer length currently used by the string variable is defined as LEN (s), and s is the string variable defined in the system.
If the buffer length LEN (S) currently used by the software is larger than the system assigned buffer length Alloc (s), there is a possibility that there is a buffer overflow vulnerability, as for whether it can be used for temporary not considering, this is another one The problem of automated analysis measurement. At the same time considering the length of the buffer, it must also be noted that the position of the buffer is the length and position of the buffer range associated with the variable. In this way, the excavation of the overflow vulnerability of the software buffer has become a tracking problem for integer ranges.
The entire work is divided into two parts, one is to generate a corresponding integer range limit for string operations; the second is a fast and accurate analysis of the resulting restrictions to obtain the last vulnerability report information.
See [1] for details on the detailed mathematical description of the restriction language.
- [3 - integer limitation
Analysis of the C language source code is the toolset BANE [6]. It generates an integer range limit by tracking the analysis tree of C code. For convenience, the length of the string contains end values '/ 0'. Such a relatively secure expression is LEN (S) ≤ alloc (s). For the operation of the string, it defines a series of corresponding match expressions. When the corresponding statement appears in the source code, the corresponding integer range corresponding to the table is limited. These matching expressions include: CHAR S [N], Strlen (S), STRCPY (DST, SRC), STRNCPY (DST, SRC, N), S = "FOO", P = Malloc (N ), P = strdup (s), strcat (s, suffix), strncat (s, suffix, n), p = getenv (...), Gets (s), fgets (s, n, ...), Sprintf (DST, "% S", SRC), Sprintf (DST, "% D", N), SNPRINTF (DST, N, "% S", SRC), P = 0 ', P = Strchr (s, c), h = gethostbyname (...), etc.
For measurable and easy implementation, they use non-current sensitivity analysis methods, which is to ignore the control flow and expressions in the code. We can easily think that this way is easily analyzed inaccuracies. As the loop statement in the program, they may contain some relatively repetitive statements, which may generate some errors, or lose some analysis results. Based on the type limits of flow sensitivity, you can see [7].
However, in their prototype, the function strcat () is made special processes, and all the places where strcat () appears as potential security vulnerabilities.
Let's take a look at the analysis of the prototype, define the range of Len (s) [a, b], and alloc (s) range [C, D], then three possible situations:
(1) If B ≤ C, it can be determined that the string S does not occur in the buffer overflow;
(2) If A> D, the string S always occurs a buffer overflow;
(3) If the two ranges are overlapping D> B> C> a, you cannot make a positive judgment, there may be a potential buffer overflow vulnerability;
For the simple and easy implementation of prototype, they abandoned a lot of analysis of pointer operations, where unsatisfactized operations include pointer aliansing, double pointer operation, array pointer, and function pointer. However, because structure uses very widely in C language, the analysis and processing of structures are supported.
- [4 - integer limit resolution
Discovering the buffer overflow vulnerability as an integer range limit, then it is necessary to determine whether there is a buffer overflow analysis solution. They use simple chart technology to build an algorithm that effectively solve integer range restrictions. Due to the description of some picture knowledge is not convenient, there is no too much in-depth analysis.
A solution for restriction systems provides us with a boundary range of each variable, but there is no correlation between variables. This can alleviate some analytical burden and easy to implement, but will also miss some security issues. Currently simple security issues may be due to the unfair use of a variable, but complex security issues are often generated by an intricate relationship, which is also some limitations of the original. First create a variable in the corresponding program in the vertex. The restriction relationship generated for each variable is exhibited in a directional view in the form of a direction. The solution releases some relationships by propagating some information in the figure, and finally a simplified directional view is obtained.
If the finally generated orientation is cycled, the topology is classified by the topology, and then the information is propagated in the direction of the classification.
They put forward three solutions for circulating maps:
(1) Constraints that will result in loop restriction systems;
(2) Introducing a relaxation operation of a variable that generates a loop, it can avoid infinite rising chains;
(3) Use the specificational domain information in the restriction language to directly process the loop related restriction system;
Due to the various drawbacks of the first two programs, the third solution was finally selected. Because the first solution is impractical, there are always many cycles and recursive in the real program; the second solution will produce some incorrect results.
Finally, they have gone a law that can solve the presence cycle in linear time.
--[ 5 Conclusion
In terms of performance, there are still many places that need to be optimized, although it is already a usable system. The prototype caused too much debugging information, which brought a large workload. In the future, you can do some efforts to reduce the analysis time.
The biggest limit is an inaccurate range analysis, which leads to excessive false positives. This is currently a problem that many vulnerabilities, which are common, the problem of establishing a good solution analysis, but it also provides us with a lot of practical information, which is complete. The artificial audit has been increased much. If you can provide enough time to analyze the generated integer range limit, then the effect in accuracy should be much better.
One problem that still exists is a drain, and it is still not possible to measure the leakage rate. At the same time, the resolution of the system does not provide enough detailed vulnerabilities.
As an automated software buffer overflow vulnerability static analysis prototype, it is more good, although there are many places that need to improve, but after all, the number of time and energy of the audit can be reduced. Personally think that if it is necessary to improve the accuracy of the exploitation of the exploitation, in addition to the principle of exploring the buffer vulnerability, there is a deep abstract ability to generate a deep abstract ability to produce truly and effective ideas and methods.
- [6 - Reference
[1] David Wagner et al, "a First Step Towards Automated Detection of Buff Overrun Vulnerabilities".
Http://www.isoc.org/isoc/conference/ndss/2000/proceedings/039.pdf
[2] Xfocus
http://www.xfocus.net/articles/
[3] NSFOCUS
http://www.nsfocus.net/index.php?act=magazine
[4] SecurityFOCUS
http://www.securityfocus.com/archive/1/
[5] David Wagner et al, "Towards Automated Detection of Buffer Overrun Vulnerabilities: a First Step".
http://www.isoc.org/isoc/conference/ndss/2000/proceedings/slides/01.pdf
[6] Aiken et al, "a Toolkit for constructing type- and constraint-based program analyss" .http: //theory.stanford.edu/~aiken/publications/papers/tic98.ps
[7] Jeffrey S. Foster et al, "Flow-Sensitive Type Qualifier".
http://www.cs.umd.edu/~jfoster/papers/pldi02.pdf
- [7 - About
about Us:
FZ5FZ mainly engaged in learning and research of network / system security, in-depth programming technology analysis and discussion, adhere to original, pursue sharing.
FZ5FZ Homepage:
http://www.fz5fz.org
