Patent Publication Number: US-2005138263-A1

Title: Method and apparatus to retain system control when a buffer overflow attack occurs

Description:
FIELD OF THE INVENTION  
      This invention relates to computer system security. In particular, the invention relates to buffer overflow attacks that are used to take control of a computer system.  
     BACKGROUND  
      Many computer systems today are vulnerable to attack using a technique known as a buffer overflow attack and more colloquially as “stack smashing.” 
      A stack is an area of memory that is dynamically assigned to a program by an operating system and comprises a number of contiguous memory locations to which data/variables required by the program may be written.  
      Programs today are written in a form in which reusable portions of code are identified with a function name that may be called from any location within the program by a function call instruction that identifies the function being called. Generally, when a function is called (hereinafter, the “called function”), the processor saves the return address at which program execution is to resume after execution of the called function on the stack. Thereafter, the operating system saves many of the variables/data required by the called function on the stack. For this purpose, the operating system allocates a stack frame or buffer within the stack to hold the data/variables.  
       FIG. 1  shows an example of a stack  100  wherein a buffer  104  comprising only four memory locations has been allocated. If, in this case, the data being written to the buffer  104  requires more than four memory locations, then the buffer  104  will be overwritten. This results in a return address  102  being overwritten.  
      In the case of a buffer overflow attack, a programmer can take control of a computer system by writing data  202  (see  FIG. 2 ) into a variable called buffer  104  to cause the buffer  104  to overflow as a result of which the return address  102  is overwritten with a pointer  200  to virus code. Thus, upon completion of the called function, the program will resume execution at the address indicated by the pointer  200  to the virus code, resulting in virus code  204  being executed.  
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       FIG. 1  shows a block diagram of a stack for a program before buffer overflow;  
       FIG. 2  shows a block diagram for a stack for the program after buffer overflow;  
       FIG. 3  shows a block diagram of hardware in accordance with one embodiment of the invention;  
       FIG. 4  shows a flowchart of processes performed in accordance with one embodiment; and  
       FIG. 5  shows a block diagram of dual stacks in accordance with one embodiment of the invention.  
    
    
     DETAILED DESCRIPTION  
      A method and system to retain system control when a buffer overflow attack occurs, is described. In one embodiment, a function call is executed during execution of a program. In response, the processor saves a return address in a first stack and in a second stack. After the called function is executed, the return addresses stored in the first and second stack are compared to determine if they match.  
      In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the invention. It will be apparent, however, to one skilled in the art that the invention can be practiced without these specific details. In other instances, structures and devices are shown in block diagram form in order to avoid obscuring the invention.  
      Reference in this specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the invention. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Moreover, various features are described which may be exhibited by some embodiments and not by others. Similarly, various requirements are described which may be requirements for some embodiments but not other embodiments.  
      Referring to  FIG. 3  of the drawings, reference numeral  300  generally indicates hardware representative of a system in accordance with embodiments of the invention. The hardware  300  typically includes at least one processor  302  coupled to a memory  304 . The processor  302  may represent one or more processors (e.g. microprocessors), and the memory  304  may represent random access memory (RAM) devices comprising a main storage of the hardware  300 , as well as any supplemental levels of memory e.g., cache memories, non-volatile or back-up memories (e.g. programmable or flash memories), read-only memories, etc. In addition, the memory  304  may be considered to include memory storage physically located elsewhere in the hardware  300 , e.g. cache memory in the processor  302 , as well as any storage capacity used as a virtual memory, e.g., as stored on a mass storage device  310 . In one embodiment, the memory  304  can conveniently be thought of as having areas  304 A- 304 D. The areas  304 A and  304 B are areas of the memory  304  corresponding to where a first stack and a second stack, respectively, are stored. The area  304 C contains an operating system for the hardware  300 , and the area  304 D contains application software.  
      The hardware  300  also typically receives a number of inputs and outputs for communicating information externally. For interface with a user or operator, the hardware  300  may include one or more user input devices  306  (e.g., a keyboard, a stylus and digitizer, etc.) and a display  308  (e.g., a liquid crystal display (LCD) panel).  
      For additional storage, the hardware  300  may also include one or more mass storage devices  310 , e.g., a disk drive such as a Compact Flash device. Furthermore, the hardware  300  may include an interface with one or more networks  312  (e.g., a local area network (LAN), a wide area network (WAN), a wireless network, and/or the Internet among others) to permit the communication of information with other computers coupled to the networks.  
      The hardware  300  operates under the control of the operating system  304 D that executes various computer software applications, components, programs, objects, modules, etc.  
      Referring now to  FIG. 4  of the drawings, operations performed by the hardware  300  of  FIG. 3 , in accordance with one embodiment are shown. At  400 , execution of a software program commences. At  402 , the operating system  304 D creates the first stack  304 A, and the second stack  304 B. At  404 , the processor  302  encounters a function call. At block  406 , in one embodiment, the return address, identifying where the program is to resume execution after execution of the called function, is stored in the first stack  304 A, as well as in the second stack  304 B. Thus, there are two copies of the return address, one copy in the first stack  304 A, and the other copy in the second stack  304 B.  
      In one embodiment, pointers to the first and second stacks are initially stored in an area of memory reserved by the operating system (OS) for storing task states. For example, in the case of X86 Intel Architecture, the pointers are stored in the Task State Segment (TSS). In one embodiment, when the stacks allocated by the OS are in use, the pointer to the stack is loaded in a register of the processor. In one embodiment, the program being executed is restricted from accessing the second stack, or any other stack that is exclusively being used to store return addresses.  
      In addition, in one embodiment the process for saving the return address may vary based upon the type of function call. In the case of a near call (a call that transfers execution of the program to a section of code that is within a predefined proximity of the call function), the instruction pointer of the function call is pushed on the first stack  304   a  and the second stack  304   b . For X86 Architecture, the extended instruction pointer (EIP) is pushed onto the stacks.  
      In the case of a far call (a call that transfers execution of the program to a section of code that is beyond a predefined proximity of the call), the instruction pointer of the function call and the code segment (CS) are pushed on the first stack  304   a  and the second stack  304   b . In the case of an inter-privilege call, a new pair of stacks is used, which correspond to the privilege level of the inter-privilege call. The new pair of stacks corresponding to the privilege level of the inter-privilege call is used in the same manner as described above with respect to the first stack  304   a  and the second stack  304   b . The pointers to the new pair of stacks are obtained from the TSS and read into one or more registers of the processor.  
      Furthermore, in the case of task switch, again, a new pair of stacks is used, which correspond to the task of the task switch. The new pair of stacks corresponding to the task of the task switch is used in the same manner as described above with respect to the first stack  304   a  and the second stack  304   b.    
      Referring again to  FIG. 4  of the drawings, at block  408 , the hardware  300  executes the called function. At block  410 , parameters and/or data variables used for execution of the called function are also stored in the first stack  304 A. Embodiments of first stack  304 A and the second stack  304 B as shown in  FIG. 5  of the drawings. As illustrated in  FIG. 5 , the first stack  304 A contains a return address  504 , as well as a buffer  506  which is used to store parameters and/or data variables for the called function. The second stack  304 B contains a return addresses  508  associated with various function calls.  
      At block  412 , a return instruction of the function, at or near the end of the function, is executed to retrieve the return address of the call from the second stack  304 B and the first stack  304 A. In one embodiment, the return instruction performs the operations of popping the top entry of the first stack  304   a  and the first entry of the second stack  304   b  (or alternatively the third stack in the case of an inter-privilege call or task switch). Thereafter, at  414 , the return addresses from the first and second stacks  304 A,  304 B are compared.  
      If, at block  416 , the return addresses match, then block  420  is executed, wherein program execution is resumed starting at the return address. If, however, at  416  it is determined that the return addresses from the first and second stacks do not match, then at block  418 , the return instruction invokes an exception to call an exception handler to determine whether execution of the program is to continue or whether an alternative form of corrective measure is necessary (e.g., whether an anti-virus response is appropriate). (not shown).  
      In one embodiment, the return instruction reports the instruction pointer of the return address which encountered the problem. In one embodiment, the exception saves return address values from the first and second stacks that did not match.  
      In block  422 , the exception handler determines whether the return address retrieved from the first stack was intentionally altered (i.e., written over) by the program being executed. While this would typically be considered a violation of software operations, the presence of a large legacy base of this behavior does exist. In one embodiment, the operating system (or some alternative logic) may cache the instruction pointers of the function calls which are expected to alter their respective return addresses. The exception handler would then read the cache to determine if the current function call which has produced the current exception is identified in the cache.  
      If the modified return address from the first stack  304   a  is determined to have been intentionally modified by the program, in block  424  the exception handler has the execution of the program resume at the modified return address. If the modified return address from the first stack  304   a  is determined to have not been intentionally modified by the program, in block  426  the exception handler has the execution of the program resume at the return address of the second stack  304   a , which represents the original return address of the function call. Alternatively, the handler can force the program to terminate execution.  
      Although the present invention has been described with reference to specific exemplary embodiments, it will be evident that the various modification and changes can be made to these embodiments without departing from the broader spirit of the invention as set forth in the claims. Accordingly, the specification and drawings are to be regarded in an illustrative sense rather than in a restrictive sense.  
      For example, in one embodiment, the first stack  304 A may only store parameters and/or data variables used for execution of the called function, and not include return addresses. The second stack  304 B would store the return address of the called function. In this case, the return address is taken from the second stack.  
      In general, the routines executed to implement the embodiments of the invention, may be implemented as part of an operating system or a specific application, component, program, object, module or sequence of instructions referred to as “computer programs.” The computer programs typically comprise one or more instructions set at various times in various memory and storage devices in a computer, and that, when read and executed by one or more processors in a computer, cause the computer to perform operations necessary to execute elements involving the various aspects of the invention. Moreover, while the invention has been described in the context of fully functioning computers and computer systems, those skilled in the art will appreciate that the various embodiments of the invention are capable of being distributed as a program product in a variety of forms, and that the invention applies equally regardless of the particular type of signal bearing media used to actually effect the distribution. Examples of signal bearing media include but are not limited to recordable type media such as volatile and non-volatile memory devices, floppy and other removable disks, hard disk drives, optical disks (e.g., Compact Disk Read-Only Memory (CD ROMS), Digital Versatile Disks, (DVDs), etc.), among others, and transmission type media such as digital and analog communication links.  
      In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.