Patent Application
20120222116
1. Field of the Invention
Web browsers are used to access websites on the Internet. Typically, a user will access the website using the browser of the user's computer. Websites can contain a mix of active and static content. Active content performs an operation using the web browser, while static content is only viewed by the user. The code used to present the static or active content on the website can be used by attackers to gain access to the user's computer. In this regard, there are a large number of malicious websites on the Internet such that client-side vulnerabilities and especially web browser vulnerabilities are a concern.
2. Description of the Related Technology
One such attack is the heap corruption exploit of the web browser whereby shell code is placed onto the memory heap of the computer using a client scripting language such as JavaScript to allocate space. The exploit works by “spraying” or writing to the heap no operation instructions (NOPs) and payload using a browser supported language such as JavaScript, VBScript, etc . . . Next, the vulnerability is triggered to overwrite the heap headers and heap data to overwrite object and virtual function pointers. The end result is that the flow of execution gets redirected to the NOP data. The object or virtual table pointer being called redirects the flow of execution to the shell code that was sprayed onto the heap. The shell code can then cause the computer to perform a malicious or unwanted operation.
The heap exploit can fail for a variety of reasons such as if the machine has low memory or the heap state between triggering and exploit redirection has changed dramatically. Also if multiple exploits using the same heap spray address are used then the exploit can be unreliable. However, the heap exploit is a very dangerous vulnerability that can give attackers access to a user's machine.
Do to the dangerous nature of the heap corruption exploit, there is a need for a system and method to detect this exploit in order to ensure safe web browsing for users.
A method and system for detecting a heap corruption exploit of a web browser is described. The method comprises installing or injecting a detection module into the web browser. Next, the detection module patches or hooks all calls of the web browser to the heap memory to the detection module in order to identify calls indicating a heap corruption exploit. The identified calls are then analyzed to determine whether a heap corruption exploit is occurring.
Typically, the calls are identified by matching them to a predefined format that corresponds to a heap corruption exploit. It has been shown that calls in the format CALL DWORD PTR typically redirect operation to malicious operations. The calls are analyzed to determine whether a heap corruption exploit is occurring by determining whether execution of the code from the call causes a malicious operation to occur on the computer. The heap process memory can be analyzed and compared to standard characteristics of normal operation in order determine whether the call interrupts operation of the computer and is a malicious operation. If a heap corruption exploit is occurring, then the detection module can stop execution in order to prevent the exploit from occurring.
Description of the Drawings
Referring to
The system 5 identifies malicious code from the web pages retrieved from web server 14 from being executed on the computer 10. In some instances, web pages may include malicious code that executes a heap corruption attack. Code from the webpage sprays or writes the memory heap of computer 10 with malicious code in order to overwrite the memory pointer of the computer 10 and redirect execution to code that performs a malicious or unwanted operation. The execution is redirected by a call to an object or virtual function to redirect execution. In order to successfully execute the redirection, the call is typically in the format:
CALL DWORD PTR [reg+x]
where reg+x is the pointer to the virtual address table that was previously overwritten with the address of the attacker's shellcode on the heap during the heap corruption.
It is possible to identify and defend against the heap corruption attack by installing a detection module 18 within the web browser 16 of computer 10 to look for the specific call before execution.
Next, in step 210, all calls of the browser are patched through the detection module 18. The patching is an ongoing process whereby calls are patched at start and as modules are dynamically loaded. The calls are patched to virtual functions for analysis.
In step 220, the detection module 18 identifies calls that may indicate a heap corruption attack. The detection module 18 identifies calls that match a predefined pattern known to cause heap corruption attacks. Specifically, the detection module locates calls in the format CALL DWORD PTR as these are known to redirect execution to the attacker's code.
Once a matching call has been identified, the operation of the computer 10 using the redirected execution is analyzed in step 230. The detection module 18 determines if the redirected execution from the call identified in step 220 is unwanted or malicious. The behavior of the computer 10 and hence the heap process memory is determined by comparing it to standard characteristics for normal operation or using other various factors that can indicate a malicious operation is to occur. For example, if page permissions look suspicious, then it can be assumed that the redirect from the call identified in step 220 is from a heap corruption attack and the resulting operation is malicious. Also, signature matching can be performed on the code to be executed from the call in order to determine whether it is malicious. In step 240, a notification is generated that malicious code is to be executed from a heap corruption attack and/or all operations can be stopped so that the heap corruption attack is not executed. In this way it is possible to identify a heap corruption exploit before it is executed.
In addition to the foregoing, it is also possible to use the method described in
The various illustrative logical blocks, modules and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP) an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may by any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.
The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in RAM memory, flash memory, ROM memory EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, o any other form a storage medium known in the art. A storage medium is coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a user terminal. In the alternative, the processor and the storage medium may reside as discrete components in a user terminal.
