Patent Grant
7526758
In order to correct problems in code under development, software developers often use a debugging tool. In order to be effective, a debugging tool provides information which assists a developer in determining where an identified problem has occurred. This allows the developer to correct the problem.
One way in which debugging tools provide information to a user is via an analysis of the thread stack. The thread stack contains a call stack, with data related to the function calls executed during the execution of a program. The thread stack also contains other data like local variables and parameters. The thread stack, used, for example, in the x86 architecture, contains a stack frame for each function call. The stack frame includes information about the function, including, e.g., function parameters, function return address, and locally declared variables and buffers.
When a function is called, information (e.g. a stack frame) regarding the function is pushed onto the thread stack. When the function returns, information is removed from the thread stack and the register trace. The register trace shows the value of registers at the point of the crash. One such register is the EIP, also known as the program counter. Knowing the EIP allows one to look at the machine instruction causing the failure. Since the instruction possibly uses other registers, the value of all registers can be used to determine out the specific nature of the crash. Thus, debugger users use the information in the call stack and information from a register trace performed by the debugger in order to determine where the problem has occurred.
One cause for failure in the execution of a program is a buffer overflow. One of the locally declared variables and buffers in the stack frame may be written with more information than the size of the buffer. This affects the values in other buffers, which causes errors or allows a malicious function to change function data, for example altering the execution path of a program.
Some compilers, for example Microsoft's Visual C++.NET compiler, allow for easier detection of such buffer overrun problems via a “speed bump” or “security cookie”. In such compilers, a special “security cookie” value is stored in the call stack in a location which will allow detection of a buffer overrun. If the security cookie has been altered in any way, this indicates that an overrun has happened and that data has been compromised. A compiler may allow the insertion of such cookies in the compiled code via a compile switch. The “/GS” compile switch in Microsoft Corporation's Visual C++.Net is used to indicate that security cookies should be used.
On function entry, the space allocated for the security cookie is loaded with a security cookie that is computed once at module load. Then, on function exit, a helper is called to make sure the cookie's value is still valid. If they are different, then a problem has been detected. The cookie is compared with a stored copy of the cookie to determine validity.
The security cookie is used to determine that a failure has occurred. However, a current limitation of debuggers is in their limited use of static analysis in determining the cause of failures. As discussed above, a register trace and a call stack are generally available to the debugger and a fair amount of information can be collected using merely these. However, the call stack only points out the direct failure path. This may not include the information necessary to determine what function caused the failure.
For example, when a failure occurs, the call stack may contain information regarding two functions, A and B. However, this does not mean that the failure is attributable to one of these two functions. When these two functions appear on the call stack, they have been called and not returned from. However, it is possible that many other functions could have been called and returned from, and the root cause of the failure could likely lie inside a function that is thus not even present in the call stack. Simple examination of the call stack will not yield information regarding functions which have been called and returned from, and thus do not appear on the call stack.
When a security cookie has been corrupted, determining the source of the corruption is important in order to remediate the problem which resulted in the corruption. During a crash, an application reporting tool enables the generation of what is called a “crash dump” containing information about the crash. There are different types of crash dumps and the type of dumps collected and sent depends on how the user has the system configured. Sometimes the address and value of the corrupted security cookie will be available in the crash dump. The address and/or value may not be available if the stack frame is corrupted, for example, which is likely when a buffer overrun occurs. In any case, merely having the address and value of the security cookie does not provide insight into the function which caused the corruption.
Debugging also often requires the source code of the programs. For various reasons, this source code may not always be available. For example, when using a standard library for a function, the source code may not be available for a function, which may complicate debugging.
In order to determine a cause for the failure of a program, static analysis is used. In some embodiments, to determine the actual location of program-related data in the call stack, such as the cookie, the address for the cookie is obtained, and the program is disassembled to find an instruction that places the program-related data/cookie. In some embodiments, static analysis is used to determine the actual location of the program-related data.
When the location of the program-related data is determined, nearby data structures can be identified. These data structures, then, may be the cause of the program failure, if they have been overflowed. Static analysis is performed to find some part of the program (e.g. a function or a portion of code) which has written to the data structures, and which therefore may have caused the program failure.
The determination of a cause for the failure does not require access to the source code. This allows greater flexibility in determining the cause for the failure of a program where not all source code is available.
Only some embodiments of the invention have been described in this summary. Other embodiments, advantages and novel features of the invention may become apparent from the following detailed description of the invention when considered in conjunction with the drawings.
The foregoing summary, as well as the following detailed description of preferred embodiments, is better understood when read in conjunction with the appended drawings. For the purpose of illustrating the invention, there is shown in the drawings exemplary constructions of the invention; however, the invention is not limited to the specific methods and instrumentalities disclosed. In the drawings:
Exemplary Computing Environment
The invention is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well known computing systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, embedded systems, distributed computing environments that include any of the above systems or devices, and the like.
The invention may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network or other data transmission medium. In a distributed computing environment, program modules and other data may be located in both local and remote computer storage media including memory storage devices.
With reference to
Computer 110 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer 110 and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CDROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by computer 110. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.
The system memory 130 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 131 and random access memory (RAM) 132. A basic input/output system 133 (BIOS), containing the basic routines that help to transfer information between elements within computer 110, such as during start-up, is typically stored in ROM 131. RAM 132 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 120. By way of example, and not limitation,
The computer 110 may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only,
The drives and their associated computer storage media discussed above and illustrated in
The computer 110 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 180. The remote computer 180 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 110, although only a memory storage device 181 has been illustrated in
When used in a LAN networking environment, the computer 110 is connected to the LAN 171 through a network interface or adapter 170. When used in a WAN networking environment, the computer 110 typically includes a modem 172 or other means for establishing communications over the WAN 173, such as the Internet. The modem 172, which may be internal or external, may be connected to the system bus 121 via the user input interface 160, or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer 110, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation,
Execution Failure Investigation Using Static Analysis
In order to provide information to a user regarding a buffer overflow or other overruns in the call stack of a program, static analysis of the code is performed. The code is compiled in such a way that a data value is placed into the thread stack of the program. This data value can later be examined to determine if it has been changed. If it has been changed then this is an indication of a buffer overflow.
The data value placed into the thread stack may be known as a “security cookie,” a “cookie”, or a “canary.” In certain of Microsoft Corporation's compilers (e.g. Visual C++.Net) the insertion of a security cookie can be requested at compile time with the /GS compile switch.
When a security issue has been encountered, static analysis is then used on the modules being run to determine the location of the security issue. For example, where a security cookie has been changed, static analysis is used to identify the likely source of corruption by determining the location of the security cookie in the stack.
Determining the location of the security cookie and deriving meaning from the location of the security cookie is complex. Different versions of the compiler could place the security cookie in different locations on the stack. Additionally, in some compilers, functions that use exception handling place the security cookie in a location different from functions that don't. Optimized functions may place the frame pointer differently and thus change the relative positioning of the security cookie. Some security cookie/canary implementations create a security cookie value for storage on the stack by manipulating some base security cookie data for added security. For example, a security cookie value may be XORed with the return address for the function, and the results of this XOR stored. This makes identifying the security cookie in a crash dump more difficult. Additionally, the frame pointer itself may be corrupted due to the overrun.
Finding a likely source of a problem when a security cookie has been corrupted is accomplished using static analysis.
Data regarding the function fθ with the corrupted buffer is identified in various ways. In some cases, the data on the call stack regarding a function in which the buffer is corrupted is directly identified by the debugger. In some other cases, the data on the call stack regarding the function in which the buffer is corrupted is identified more indirectly. For example, in some cases, at runtime, a failure-reporting function call (e.g. report_gsfailure) is made when a failure is detected. This function is added by the compiler and executed at runtime. The execution of that failure-reporting function call can be used to determine when the buffer was corrupted. In such cases, the compiler performs a security check call at the time of function return, this call detects the security cookie corruption and reports it, e.g. via a ‘report_gsfailure’ call. Thus, the function right before the execution of the failure-reporting function (e.g. report_gsfailure) is the function with the corrupted buffer.
This function fθ is the function with the corrupted buffer, however, it is not necessarily the function which caused the corruption. Thus, additional steps are used to determine the etiology of the corruption.
When the function fθ has been identified, the address AΦ of the security cookie Φ is identified, step 210. The simplest way of identifying AΦ is by using symbolic information in the crash dump. However, sometimes the crash dump might not contain this information. In such cases, we find AΦ by looking at the non-corrupted part of the stack frame. Fortunately, in some cases the failure-reporting function places the address of the security cookie on its non-corrupted stack frame and we can retrieve AΦ from there. The security cookie address AΦ, as described above, does not show the location of the security cookie on the stack frame of fθ. Once the security cookie address AΦ is determined, the location of the cookie on the stack frame of fθ is found in steps 220 and 230.
Once the function fθ and address AΦ have been identified, function fθ is analyzed to find an instruction which operates on address AΦ, step 220. In this way, the instruction which placed the security cookie Φ in the frame stack. In some embodiments, disassembly is used to disassemble function fθ in order to find the relevant instruction. Disassembly is the translation of low-level code (e.g.) machine language to higher-level code (e.g. assembly language.) During disassembly, an instruction with operand address AΦ is sought.
In step 230, the location ε on stack where the security cookie Φ is placed is obtained. In some embodiments, this is done using static analysis. Static analysis (also known as data flow analysis) is a set of techniques which identify the flow of instructions and data in a computer program without executing the program. In static analysis, using a set of static analysis techniques, the program is examined and information about the use of data and storage is collected. Early work on static analysis was done by Frances E. Allen and John Cocke (Allen and Cocke, “A program data flow analysis procedure.” Communications of the. ACM, 19(3):137-147, 1976) and further techniques have since been developed to perform static analysis.
In step 240, at least one storage structure proximate to location ε on stack is identified as a possible source of corruption. This step, in some embodiments, is accomplished using static analysis. In some embodiments, all arrays and structures with arrays on the stack are enumerated using symbol information. Then one or more storage structures proximate to the location ε (in which the security cookie Φ was placed) are identified. For example, the array α or the structure with an array β that is closest to location ε on the stack is identified using the symbol information for the function on the stack, and α or β is flagged as the possible corruption. Proximity, according to some embodiments, is determined according to a proximity metric. Such a proximity metric is defined in advance, specified during the execution of the method shown in
In some embodiments, when data structure(s) have been identified as possible sources of corruption, this identification is used by a user directly. However, in some embodiments of the invention, the functions which access the data structure(s) are identified, as shown by step 250.
In step 250, function(s) which access the storage structure(s) identified in step 240 are identified. These functions are the possible culprits for the buffer overflow which caused the cookie to be overwritten. Determining which functions access the storage structure, in one embodiment, occurs via static analysis. A call graph is created for function fθ. Such a call graph shows the interrelationship of functions. The call graph shows which functions are called by function fθ, either directly or indirectly, through one or more nested calls to other functions. The call graph is then pruned to eliminate functions which do not take references to any of the storage structure(s) identified in step 240 out as an output parameter. If source code is available, the call graph is further pruned to eliminate function calls that accept references to constant instances of these structures. Static analysis techniques are then used to determine which functions write to these storage structures in a way which would cause the structure to be overrun.
As can be appreciated, in no steps of the embodiments of the invention shown in
Conclusion
It is noted that the foregoing examples have been provided merely for the purpose of explanation and are in no way to be construed as limiting of the present invention. While the invention has been described with reference to various embodiments, it is understood that the words which have been used herein are words of description and illustration, rather than words of limitations. Further, although the invention has been described herein with reference to particular means, materials and embodiments, the invention is not intended to be limited to the particulars disclosed herein; rather, the invention extends to all functionally equivalent structures, methods and uses, such as are within the scope of the appended claims. Those skilled in the art, having the benefit of the teachings of this specification, may effect numerous modifications thereto and changes may be made without departing from the scope and spirit of the invention in its aspects.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5854924 | Rickel et al. | Dec 1998 | A |
| 5987626 | Greyzck | Nov 1999 | A |
| 6205560 | Hervin et al. | Mar 2001 | B1 |
| 6353924 | Ayers et al. | Mar 2002 | B1 |
| 6393606 | Davila et al. | May 2002 | B1 |
| 7401322 | Shagam et al. | Jul 2008 | B1 |
| 7401332 | Foster et al. | Jul 2008 | B2 |
| Number | Date | Country | |
|---|---|---|---|
| 20070006170 A1 | Jan 2007 | US |
