WO2005024630A1 - 不正コード実行の防止方法および防止プログラム - Google Patents

不正コード実行の防止方法および防止プログラム Download PDF

Info

Publication number
WO2005024630A1
WO2005024630A1 PCT/JP2004/012858 JP2004012858W WO2005024630A1 WO 2005024630 A1 WO2005024630 A1 WO 2005024630A1 JP 2004012858 W JP2004012858 W JP 2004012858W WO 2005024630 A1 WO2005024630 A1 WO 2005024630A1
Authority
WO
WIPO (PCT)
Prior art keywords
program
return address
address
execution
stack
Prior art date
Application number
PCT/JP2004/012858
Other languages
English (en)
French (fr)
Inventor
Koichiro Shoji
Yoshiyasu Takefuji
Takashi Nozaki
Original Assignee
Science Park Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Science Park Corporation filed Critical Science Park Corporation
Priority to US10/570,502 priority Critical patent/US8042179B2/en
Priority to EP04772807A priority patent/EP1662379A4/en
Priority to JP2005513686A priority patent/JP4518564B2/ja
Publication of WO2005024630A1 publication Critical patent/WO2005024630A1/ja

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1405Saving, restoring, recovering or retrying at machine instruction level
    • G06F11/141Saving, restoring, recovering or retrying at machine instruction level for bus or memory accesses
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/362Software debugging
    • G06F11/3648Software debugging using additional hardware
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs

Definitions

  • the present invention relates to a method for preventing execution of an unauthorized code, a program for preventing the execution of an unauthorized code, and a program for preventing the execution of an unauthorized code, in which a program operating on a computer protects against a malfunction due to an unauthorized code or an external attack.
  • the present invention relates to a recording medium for an application program.
  • the present invention relates to a method for preventing unauthorized code execution, a program for preventing unauthorized code execution, and a recording medium for a program for preventing unauthorized code execution, which detects a buffer overflow and improves deficiencies in program operation.
  • a security hole is a structure of vulnerabilities caused by flaws or bugs in software design. Malicious users can use this security hole in the operating system to gain unauthorized access to the operating system and perform malicious activities such as hacking and cracking. One way to do this is to use buffer overflow in the memory.
  • a program running on a computer consists of two parts: program code and program data.
  • the program code is a read-only code written in a machine language.
  • the program data is an information portion such as a position on a memory of a program code executed by an execution instruction of the operating system.
  • the program is usually stored on a hard disk of an electronic computer.
  • a program is called and executed by an operating system, the whole or a part of the program is stored and operated in a random access memory (RAM), which is a main memory of a computer.
  • Main memory stores data directly from the CPU (central processing unit) of the computer. This is a memory that can read and write data, and is managed by assigning an address number to each unit capacity for storing data.
  • the smaller address number of the main memory is defined as an upper address (High Memory) area, and the larger address number is defined as a lower address (Low Memory) area.
  • the main memory will be simply described as a memory.
  • a program When a program is read by the operating system, a part of the memory is allocated to the program, the program data is stored in an upper address (High Memory) area of the allocated memory, and a lower address (Low Memory) is stored.
  • the program code is stored in the (Memory) area.
  • Program data is divided into three data areas: stack data, heap data, and static data. These three areas are located in memory independently of each other.
  • FIG. 5 is a conceptual diagram showing a structure of a memory of an electronic computer.
  • the upper address side of the memory is a stack memory area.
  • the stack memory area In the stack memory area, each time a program is executed, the stack memory for the program and the subroutines in the program is secured here, and the stack memory area is sequentially stored in a lower address of the memory.
  • the stack memory includes an argument (Argument) area, a return address (Return Address) area, a stack data area, and the like.
  • the lower address side of the memory includes areas such as a heap data area, a static data area, and a program code area.
  • the static data area is located at a higher address than the program code area and is a memory area where global variables and static C ++ class members are reserved.
  • the heap data area is located at a higher address than the static data area.
  • the heap data area is allocated to the C language malloc () and allocO functions, and the C ++ language new operator.
  • the stack memory area is accessed by a LIFO (Last-in, first-out) method.
  • the stack memory stores function parameters such as a return address at which the next instruction after the execution instruction is executed, local variables, and the like. This return address is an important value at all.
  • FIG. 6 illustrates a program written in C language.
  • the program runs Then, the main () function is executed first (lines 13), sub (Datal) of the subroutine on the fourth line is called, and the processing of the program is shifted to the tenth line.
  • the return instruction on the 16th line moves the processing to the position where sub () was called. At this time, how data is stored in the memory will be described.
  • Non-patent literature describes a method for providing a mechanism for preventing a buffer overflow in a compiler.
  • the GCC compiler has a protection section at the lower address of the stack memory to detect overwriting of data.
  • Patent Document 1 an area of a protected numerical value is defined in a storage device, data in a stack memory is stored and protected in the protected numerical value area, and a processing command is executed. Since the return address is protected in the protected numerical value area, the program counter is protected even if processing instructions such as subroutines are executed.
  • Non-Noon Document 1 Openwall Linux kernel patch project
  • Non-Patent Document 2 StackGuard: Simple Stack Smash Protection go GCC, URL:
  • Patent document 1 US published patent number US2001013094? Al?-? 2001-08_09, "Memory device, stack protection system, computer system, compiler, stack protection method, storage medium and program transmission apparatus.
  • An object of the present invention is to provide a method for preventing falsification of data stored in an address of a memory of a computer and detecting data falsification, a program thereof, and a recording medium of the program.
  • An object of the present invention is to provide a method for preventing and detecting return address in a stack memory during execution of a program.
  • Still another object of the present invention is to provide a function for effectively preventing execution of malicious code even when application software and kernel mode software are vulnerable to buffer overflow.
  • Still another object of the present invention is to detect an unauthorized code before it is executed, and to suppress execution of the unauthorized code.
  • the present invention employs the following means in order to achieve the above object.
  • the method for preventing unauthorized code execution according to the first aspect of the present invention is characterized in that when a program stored in a storage medium of a computer is executed by a central processing unit, the program is stored in a stack memory area of a memory. Return address capability This is a method for detecting a buffer overflow of the memory, which is overwritten by execution of an illegal code, and preventing the occurrence of the buffer overflow.
  • the return address is backed up, and when the return address is altered by execution of the illegal code, the alteration is detected by a debugging function of the central processing unit. It is characterized by.
  • a memory address where the return address is stored is recorded in a debug register used for the debug function, and when the value of the memory address recorded in the debug register is falsified, The central processing unit outputs an error signal and It is good to perform detection.
  • the backup is performed by storing the return address in a memory area where the data of the execution program is not stored.
  • the apparatus further comprises means for detecting the buffer overflow by comparing the return address stored in the stack memory area with the backed up address.
  • control means for rewriting the memory address with the stored return address when the return address is falsified it is preferable to have a control means for rewriting the memory address with the stored return address when the return address is falsified.
  • ttmp the return address is specified in the ttmp stack memory command, and the ttmp, the return address address, and the treasure maker is told.
  • ttmRttmp stack memory area enter: To perform the above-mentioned play, enter the following message: “Processing error” >> ttmp n »fi, ttmp, error message, ttmp, program
  • the return address may be a process called when the program is executed, and at least one return address of a thread called from the process. It is good to be.
  • the program for preventing execution of unauthorized code according to the second invention of the present invention is stored in a stack memory area of a memory when a program stored in a storage medium of a computer is executed by a central processing unit.
  • the program for preventing illegal code execution includes an analysis step for acquiring and analyzing a branch instruction in the program when the program is called from the storage medium; An extraction step for extracting a return address, a registration step for registering an address where the return address is stored in the stack memory area as a debug address of a debug function of the central processing unit, and an operation of the program.
  • An extraction step for extracting a return address
  • a registration step for registering an address where the return address is stored in the stack memory area as a debug address of a debug function of the central processing unit, and an operation of the program.
  • a backup step for registering and backing up the return address and the address.
  • the central processing unit is debugged by the debug function. Outputting an error signal, interrupting the execution of the program, and moving the flow of the program to the control step.
  • control step may include a step of stopping the program.
  • control step may include a step of rewriting the return address with the backed-up return address.
  • control step may include a step of storing the rewritten value.
  • the central processing unit When performing a check, the central processing unit outputs an error signal to perform the detection, and the program is stopped or stopped after receiving the error signal. And the control step for controlling the flow of the program.
  • program is preferably at least one selected from application software, operating system software modules, kernel mode software, functions used in these, and subroutines.
  • a recording medium for a program for preventing unauthorized code execution according to the third invention of the present invention is a recording medium on which the above-described program for preventing unauthorized code execution is recorded.
  • the illegal code prevention method of this invention can prevent execution of an illegal code without changing hardware, an operating system, kernel mode software, and application software.
  • the illegal code prevention method of the present invention can effectively cope with a case where application software and kernel mode software have vulnerabilities due to buffer overflow.
  • the unauthorized code prevention method of this invention can detect an unauthorized code before it is executed, and can suppress execution of an unauthorized code.
  • An object of the present invention is to provide a method for detecting an operation in which data stored in a main memory of a computer is rewritten and falsified.
  • data stored in the main memory of the electronic computer is rewritten, and a program for detecting the falsification of the data and restoring the rewritten or falsified data is provided.
  • the present invention provides a recording medium on which the program is recorded. An outline of the embodiment of the present invention will be described.
  • the debug function of the CPU is a function for detecting an error that occurs when an application program is executed.
  • the CPU has multiple memories called debug registers, which are used to monitor the operation of specific addresses in the main memory. The address of the monitored address and the CPU operation are registered in this debug register, and when the value of this address is changed, the CPU detects this and issues an error signal. Then, another program can be operated by interrupting the execution of the application program.
  • an operation of a program for detecting execution of an illegal code due to a buffer overflow and preventing data tampering or the like will be described.
  • the return address is stored in the stack memory area every time a program, subprogram, or function is called, as described in the related art.
  • In the debug register of the computer CPU specify and record the main memory address where the return address is stored. At the same time, the return address is backed up in another area of the main memory. If the data at this address is tampered with, an error is detected by the CPU, interrupting the program being executed, and transferring control to another program to prevent data tampering and execution of illegal code. it can. Rewrite the backup return address to the original address, and return the program to normal operation. It is also possible to back up the rewritten address and use it for pattern analysis of computer virus attacks due to buffer overflow.
  • the unauthorized code prevention method uses driver software to realize a method of detecting data tampering using the debug register and restoring the tampered data. It provides layers and error routines.
  • This driverware layer has a function of grasping the above-mentioned return address, registering it in a debug register, and backing up.
  • the error routine provides a function to repair the alteration if the return address data is altered.
  • Embodiment 1 of the present invention will be described in detail.
  • FIG. 1 shows an outline of an embodiment of the present invention.
  • FIG. 1 shows software 1, driverware 2, file system driver 3, and hard disk 4 operating on the computer.
  • the executable program is stored as an executable file 5 on the hard disk 4, read out by an operating system call command, and stored in the memory 6.
  • Software 1 means an application program running on a computer. This application program may be any program that operates in the kernel mode or user mode of the operating system.
  • the driverware 2 is located between the file system driver 3 and a service provided by the operating system, and performs control when reading / writing from / to each device of the computer from the operating system. It is a program.
  • the file system driver 3 is a driver for reading data stored in a storage device built in or connected to the computer and writing the data to the storage device.
  • the hard disk 4 is usually a hard disk built into the computer. But software 1 is stored and called from the operating system
  • An external storage device such as an external hard disk, a flash memory, or a CD-ROM may be used as long as it can be executed.
  • an instruction for calling a program (executable file 5 in FIG. 1) from the operating system takes a format transmitted to the file system driver 3 via the driverware 2.
  • the file system driver 3 calls the program from the hard disk 4 and passes it to the driver 2.
  • the driverware 2 analyzes the program, grasps the main routine and subroutine, obtains the return address of each, and performs control to detect a buffer overflow.
  • the return address is the address that is output by a branch instruction such as the CALL instruction, stored in the stack memory, and returned by the RET, RETxx instruction.
  • the driverware 2 detects the start of the program (step 2).
  • the driverware 2 analyzes the program, grasps the main routine and subroutine, and obtains the respective return addresses.
  • Driverware 2 checks the arguments, local variables, and function addresses generated when the program is started (step 3), and stores the function addresses. Specifically, it checks the events executed by branch instructions such as calls (CALL), returns (RET, RETN), and jumps (JMP) executed in the program, acquires the return address, and saves it (step 4).
  • branch instructions such as calls (CALL), returns (RET, RETN), and jumps (JMP) executed in the program, acquires the return address, and saves it (step 4).
  • the driverware 2 hooks a branch instruction such as a call instruction (Call instruction) so that control can be transferred to the driverware 2 (step 5).
  • a branch instruction such as a call instruction (Call instruction)
  • PsSetLoadlmageNotifyRoutineO provided by the OS is called, and a callback function (LoadlmageNotifyRoutine) called at the time of process startup is registered.
  • a callback function LoadlmageNotifyRoutine
  • Driverware 2 incorporates protection of return addresses on the stack memory and detection of tampering during program execution (Step 6).
  • the above-described debug function of the CPU is used for the protection of the return address.
  • the CPU debugging functions there is a function that outputs an error when a specific memory address is rewritten, and control can be moved to a specified address.
  • the operating system issues an interrupt instruction and transfers control to the driverware 2. Apply this function to the return address. Therefore, when the return address is rewritten, an error is detected by the debug function, and control is transferred to the driverware 2.
  • Driverware 2 executes the program specified in step 1 (step 7).
  • FIG. 4 is a flowchart showing a procedure for detecting a buffer overflow when the program is activated and executed.
  • call instruction When a call instruction (Call instruction) is executed from the operating system or the application program when executing the program, an interrupt of the CPU occurs, and control is transferred to the driver 2 (steps 10-11).
  • the driverware 2 checks the arguments, local variables, and function addresses generated by the execution of the program (step 12), and protects or stores the return address on the stack 2 ⁇ during execution by the debug function (step 12). 13).
  • This corruption is performed by setting the stack memory in which the return address is stored to a read-only attribute, and when writing to this stack memory and making an entry, the CPU generates an error and generates an interrupt of the CPU. Since the control is transferred to the driverware 2, the return address cannot be changed and tampered with, and it is possible to corrupt the memory.
  • the above memory stores the return address on the stack memory in a separate area of the memory. If the return address has been tampered with, this backup can be compared to the return address and the tampering can be performed.
  • the driverware 3 issues an instruction (IRET) (Step 14), returns control to the execution address interrupted in Step 11 (Step 15), and executes (Step 16).
  • ITT instruction
  • Step 14 the driverware 3 issues an instruction (IRET) (Step 14)
  • Step 15 returns control to the execution address interrupted in Step 11 (Step 15)
  • Step 16 executes
  • the driverware compares the return address stored in step 13 with the return address on the stack (step 1719).
  • Driverware 2 detects an error (step 20).
  • the execution of the program is interrupted, and control is transferred to the error routine (step 21).
  • the error routine (not shown) is executed when an error is detected.
  • the error routine stops the execution of the program, saves the contents of the stack memory, and rewrites the return address with the previously saved data. It is a program that has This error routine allows you to stop, continue, and save malicious code (step 22).
  • FIG. 2 illustrates an example in which the computer is attacked from the outside.
  • Network card
  • External data having a virus, an unauthorized code, and the like is transmitted via the communication device 10.
  • External data is stored in the memory 6 via the network card 10, NDIS 11, and Winsockl 2.
  • the CPU outputs an error and the control shifts to the driverware 2.
  • Driver way 2 receives this error detection and hooks an error routine to respond.
  • the present embodiment is applicable not only to an application program that operates only in the user mode, but also to a program that operates in the kernel mode.
  • the same method can be applied to any program that uses the buffer overflow method.
  • Embodiment 1 of the present invention An example of Embodiment 1 of the present invention will be described.
  • a processor having a 32-bit architecture of Intel (registered trademark) and having an instruction trace function is implemented.
  • Intel registered trademark
  • it is a processor developed after PentkimPro (registered trademark) or a processor compatible with this processor.
  • the operating system is Microsoft Windows 2000 (registered trademark).
  • the driverware 2 operates, performs initialization processing in preparation for buffer overflow detection, detects processes and threads generated when a program is executed, and Understand routines and subroutines. Then, when the driverware 2 detects a buffer overflow, a process interruption process is operated as an error routine to take measures. These operations will be described in detail.
  • the flowchart in FIG. 8 shows the outline of the initialization processing.
  • the driverware starts and reads the process name for monitoring buffer overflow from the registry (Step 100).
  • the process creation callback of the process to be monitored is registered (step 101). Details of the registration of this process generation callback are shown in the flowchart of FIG.
  • the stack recorder is initialized to secure a memory area (step 102).
  • a hook for the thread generation event of the monitored thread is set (step 103).
  • trace the execution instruction is set.
  • LoadlmageNotifyRoutine is registered. This callback function is defined by the following prototype:
  • FIG. 9 shows a procedure of registering a process generation callback.
  • the LoadlmageNotifyRoutine function is called (step 110).
  • the operation in LoadlmageNotifyRoutine is shown below.
  • It is determined whether the process is to be monitored (step 111). At this time, it is checked whether the target process module name exists in the argument FulllmageName of LoadlmageNotifyRoutine. If it does exist, move on to the next process.
  • the entry point address of the process module is obtained (step 112). Examine the beginning (header) of the executable module file used in Windows and obtain the address of the function (entry point) to be executed first. Then, a break point is set at the entry point (step 113).
  • An example of the program code at this time is as follows.
  • PVOID ImageBase (PVOID) lmagelnfo-> lmageBase
  • MZ-HEADER * mz_Header (MZ—HEADER *) lmageBase;
  • MZ_NE * mz one ne (MZ_NE *) ((char *) ImageBase + siz8of (MZ_HEADER));
  • Oldt (PIDTENTRY) MAKELONG (idtr ⁇ owlDTbase, idtr.HilDTbase);
  • gOldlNTOI H_Handler MAKELONG (Oldt [IGATE01] .OffsetLow, Oldt [IGATE01] .OffsetHigh);
  • MOV DR7, EAX; II Set DE7 Initialization of the stack recorder (see step 102) is performed dynamically each time a thread of the specified monitored process is created.
  • Each stack of the stack recorder is defined as follows.
  • the flowchart of FIG. 10 shows a procedure for setting a hook for a thread generation event (see step 103).
  • a thread is created (step 120)
  • Oldt (PIDTENTRY) MAKELONG (idtr.LowlDTbase, idtr.HilDTbase);
  • g0ldlNT2EH_Handler M AKE LONG (01 d t [IG AT E2 E]. Of f set Low, 0ldt [IGATE2E] .0ffsetHigh);
  • the program is executed, and a branch instruction such as CALL or RET is traced.
  • a branch instruction such as CALL or RET is traced.
  • the processing during tracing is shown in the flowcharts of FIGS.
  • the trace processing is started (step 150)
  • the trace flag of DR6 is cleared (step 151), and the CALL instruction and the RET instruction are determined.
  • the CALL, RET, and RETN instructions are discriminated, and “CALL processing”, “RET processing”, and “RENT processing”, respectively. It has become.
  • “To the CALL processing”, “to the RET processing”, and “to the RENT processing” are shown in the flowcharts of FIGS. 13, 14, and 15, respectively.
  • the program code for determining the CALL, RET, and RETN instructions is as follows.
  • MOV ECX, 0x000001DB; II MSR 0x01DB (LastBranchFromlp)
  • CALL, RET, and RETN are determined by CALL_FOUND and RET.FOUND, respectively. Coded as RETN_FOUND.
  • FIG. 13 shows the processing when the CALL instruction is executed.
  • the execution of the CALL instruction is started (step 200)
  • the address of the stack segment (CS) in the stack memory allocated to the CALL instruction is obtained (step 201).
  • the stack point of the return address stored by the CALL instruction is obtained (step 202).
  • the return address is obtained from the stack memory (step 203).
  • the program code at this time is as follows.
  • MOV AX, 0x001 B // Usermode Only
  • KeRaiselrql (HIGH_LEVEL, &Oldlrql);
  • PASO-STACK-UST StackList (PASO_STACK_LIST) gStackList [Threadld];
  • FIG. 14 shows the processing when the RET instruction is executed.
  • the execution of the RET instruction is started (step 250)
  • the address of the stack segment (CS) of the stack memory allocated to the RET instruction is obtained (step 251).
  • the stack pointer of the return address specified by the RET instruction is obtained (step 252).
  • the return address is obtained from the stack memory (step 253).
  • the program code at this time is as follows.
  • the return address is the one registered in the stack recorder at the time of the CALL instruction corresponding to this RET instruction. However, if the return address has been tampered with, the stack recorder will be able to find the same address. In this case, the process proceeds to the process interruption processing (Terminate_VirusCodeO of the next code) (step 260). If the same address is found, one record is deleted from the stack recorder (step 255).
  • the program code at this time is as follows.
  • KeRaiselrql HGH—LEVEL, &Oldlrql
  • PASO— STACK_LIST StackList (PASO_STACK_LIST) gStackList [Threadld];
  • Terminate_VirusCode (Fromlp, Tolp, ExpectedRetlp);
  • FIG. 15 shows processing when the RETN instruction is executed.
  • execution of the RETN instruction starts (step 300) the RETN instruction is harmed.
  • the address of the client (CS) is obtained (step 301). Then, the stack point of the return address specified by the RETN instruction is obtained (step 302). Then, the return address is obtained from the stack memory (step 303).
  • the program code at this time is as follows.
  • a search is made from the stack recorder as to whether there is the same value as the return address (step 304).
  • the return address is the one registered in the stack recorder at the time of the CALL instruction corresponding to this RETN instruction. However, if the return address has been tampered with, the power of the stack recorder will not be able to find the same address. In this case, the process proceeds to the process interruption processing (Terminate_VirusCodeO of the next code) (step 310). Find the same address Then, one record is deleted from the stack recorder (step 305).
  • the program code at this time is as follows.
  • KeRaiselrql HGH—LEVEL, &Oldlrql
  • PASO-STACK-LIST StackList (PASO_STACK_LIST) gStackList [Threadld];
  • Terminate_VirusCode (Fromlp, Tolp, ExpectedRetlp);
  • FIG. 16 shows a process when the JMP ESP process is executed.
  • JMP ESP is an instruction necessary for, for example, a virus or the like invading via a network to execute the program code on the stack memory. Therefore, execution modules that use the JMPESP instruction that do not depend on the search result of the stack return address are rare and are prohibited.
  • a process interruption process is performed (step 351). In the process interruption processing in steps 260, 310, and 351, the address of the instruction executed next to the RET and RETN instructions is obtained, and the address is rewritten to an invalid instruction (such as INT3). Continue the execution of the process and stop it with an illegal instruction.
  • the program code at this time is as follows.
  • MOV SS [EDX], AL
  • the present invention is used in all fields where computer virus countermeasures, prevention of unauthorized intrusion from outside, and security are required. In particular, use it for systems that use computers, supercomputers, and servers connected to a network. It is used for e-government, military, and defense-related systems that require protection of personal information and security of electronic files. Also, it is preferable to use this function when detecting a defect of a program or use of an illegal code.
  • FIG. 1 is a conceptual diagram showing an outline of the present invention.
  • FIG. 2 is a conceptual diagram showing error detection due to a buffer overflow according to the present invention.
  • FIG. 3 is a flowchart showing a procedure at the time of loading an executable file.
  • FIG. 4 is a flowchart showing a procedure when executing an execution file.
  • FIG. 5 is a diagram showing a structure of a memory.
  • FIG. 6 is a diagram illustrating a main routine and a subroutine of a program.
  • FIG. 7 is a diagram showing a structure of a stack memory.
  • FIG. 8 is a flowchart showing a procedure of an initialization process when the driverware is started.
  • FIG. 9 is a flowchart showing a procedure of registering a process generation callback.
  • FIG. 10 is a flowchart showing a procedure for setting a hook for a thread generation event.
  • FIG. 11 is a flowchart showing a processing flow when tracing a branch instruction such as CALL and RET.
  • FIG. 12 is a flowchart showing a processing procedure of the CALLorJMP processing of FIG.
  • FIG. 13 is a flowchart showing processing when a CALL instruction is executed.
  • FIG. 14 is a flowchart showing processing when an RET instruction is executed.
  • FIG. 15 is a flowchart showing a process when a RET instruction is executed.
  • FIG. 16 is a flowchart showing the procedure of JPM ESP processing.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Quality & Reliability (AREA)
  • Debugging And Monitoring (AREA)
  • Executing Machine-Instructions (AREA)
  • Storage Device Security (AREA)

Description

明 細 書 不正コードの防止方法おょぴ防止プログラム 技術分野
[0001] 本発明は、電子計算機で動作するプログラムが不正コードによる動作不備又は外 部からの攻撃から保護する不正コード実行の防止方法、不正コード実行の防止用プ ログラム、及び不正コード実行の防止用プログラムの記録媒体に関する。
詳しくは、バッファオーバーフローを検出し、プログラムの動作不備を改善する不正 コード実行の防止方法、不正コード実行の防止用プログラム、及び不正コード実行の 防止用プログラムの記録媒体に関する。
背景技術
[0002] 電子計算機のオペレーティングシステムは複雑に設計されている。このため、オペ レーティングシステムには、セキュリティホールと呼ばれる弱点がある。セキュリティホ ールとは、ソフトウェアの設計の欠陥やバグにより生じる脆弱性の構造である。悪意の あるユーザは、オペレーティングシステムのこのセキュリティホールを利用して、オペ レーティングシステムへ不正に侵入し、ハッキング、クラッキング等の悪意の行為を行 うこと力 Sある。その手段としては、メモリのバッファオーバーフロー(Buffer over flow)を 利用する方法がある。
[0003] ここで、バッファオーバーフローについて説明する。電子計算機で動作するプログ ラムは、プログラムコードとプログラムデータの 2つの部分力 構成される。プログラム コードは、機械語で書かれた読み出し専用のコードである。プログラムデータは、ォ ペレ一ティングシステムの実行命令によって実行されるプログラムコードのメモリ上の 位置等のインフォメーション部分である。
[0004] プログラムは、通常は、電子計算機のハードディスクに保存されている。プログラム はオペレーティングシステムによって呼び出され実行するとき、プログラム全体で又は その一部が電子計算機のメインメモリである RAM (Random Access Memory)に格納 されて動作する。メインメモリは、電子計算機の CPU (中央処理装置)から直接データ の読み書きできるメモリで、データを格納する単位容量ごとに番地番号をつけて管理 されている。メインメモリの番地番号の小さい方を上位番地(High Memory)領域、番 地番号が大きくなると下位番地(Low Memory)領域としている。以下、メインメモリを単 にメモリとして説明する。
[0005] プログラムがオペレーティングシステムによって読み出されると、メモリの一部がこの プログラムに割り当てられて、その割り与えられたメモリの上位番地(High Memory)領 域にプログラムデータが格納され、下位番地(Low Memory)領域にプログラムコード が格納される。プログラムデータは、スタックデータ(Stack data)、ヒープデータ(Heap data)、スタティックデータ(Static data)の 3つのデータ領域に分かれている。これら の 3つの領域は、お互いに独立してメモリに配置されている。実行されるプログラムが 、オペレーティングシステムによってハードディスクから呼び出されると、最初は、プロ グラムコードが読み出されメモリに格納される。続いて、プログラムデータが読み出さ れてメモリに格納される。
[0006] 図 5は、電子計算機のメモリの構造を示す概念図である。メモリの上位番地側はスタ ックメモリ領域になっている。スタックメモリ領域は、プログラムが実行されるごとに、そ のプログラムとプログラム内のサブルーチン用のスタックメモリがここに確保されてメモ リの下位番地へと順番に格納される。スタックメモリは、引数 (Argument)領域、リタ一 ンアドレス(Return Address)領域、スタックデータ領域等から構成される。
[0007] メモリの下位番地側は、ヒープデータ領域、スタティックデータ領域、プログラムコー ド領域等の領域から構成されている。スタティックデータ領域は、プログラムコード領 域より上位番地側に位置し、グローバル変数と static C++クラスメンバーが予約される メモリ領域である。スタティックデータ領域より上位番地側にはヒープデータ領域が位 置する。ヒープデータ領域は C言語の malloc()、 allocO関数、 C++言語の newオペレー タに割り当てられてレ、る領域である。
[0008] スタックメモリ領域は LIFO (Last-in,first-out)方式でアクセスされる。スタックメモリ は、実行命令が終了後の次の命令が実行されるリターンアドレス等の関数パラメータ やローカル変数等が格納される。このリターンアドレスはもつとも重要な値である。
[0009] 図 6には、 C言語で書かれているプログラムを例示している。プログラムが実行され ると、まず main()関数が実行されて(行 1一 3)、 4行目のサブルーチンの sub(Datal)が 呼び出されてプログラムの処理が 10行目に移っている。 sub()サブルーチンでは、 16 行目の return命令で、 sub()を呼び出した元の位置へ処理を移している。このとき、メ モリにどのようにデータが格納されるかを説明する。
[0010] サブルーチンが呼び出されると、図 7に図示したように、スタックメモリ領域にデータ が書き込まれる。スタックメモリ領域の上位番地側から「main()へのリターンアドレス」が 格納されて、サブルーチン内のローカル変数が格納される領域が予約される。この例 では、変数 i (11行目)と buf(12行目)がある。 14行目の strcpy命令でサブルーチンの 引数 Dataの値を bufにコピーしている。このとき、引数 Dataの値が bufのサイズより大き い場合は、ローカル変数 i、場合によっては、 main()ルーチンへのリターンアドレスまで 上書きしてしまうことになる。このように、データが確保されたメモリの領域に入りきれ ないで別の変数のための領域にまで書き込まれる。これは、バッファオーバーフロー である。リターンアドレスが別の値に書き換えられているので、プログラムは正常の動 作をしなくなる。
[0011] 通常これらのプログラム、プログラムのサブルーチン、関数が実行されて終わると、リ ターンアドレスに示された位置に戻され、プログラムの実行が継続される。し力し、プ ログラムの作り方に不具合があると、上に説明したように、データを書き込みするとき にローカル変数の確保領域を超えてリターンアドレスを上書きすることが可能になる。
[0012] 通常リターンアドレスの書き換えによってバッファオーバーフローを起こしたプログラ ムは、不定な実行状態となる。場合によっては、プログラムが暴走、あるいは停止する ことが殆どである。リターンアドレスが意図的に用意したメモリ番地に戻されると、オペ レーティングシステムはこれを不正なコードと分からずにこのメモリ番地に格納されて レ、る命令を継続して実行させる。ノ ッファオ一バーフローによる脆弱性を利用した攻 撃は、このように意図的に用意したコードを実行させることである。
[0013] このようなバッファオーバーフローによる不正コードの実行は、プログラムの実行管 理を行っているオペレーティングシステムでは全く把握できなレ、。この不正コードの実 行を防ぐには、リターンアドレスの改ざん、書き換えを如何に防ぐ力、、あるいは検知で きるかが非常に重要である。 [0014] この問題を解決する方法としては、オペレーティングシステムに修正を加える方法 や、コンパイラにバッファオーバーフローを防ぐ仕組みを作る方法等が提案されてい る。オペレーティングシステムに修正をカ卩える方法としては、非特許文献 1のプロジェ タトがある。このプロジェクトでは、オープンソースのオペレーティングシステムのバッ ファオ一バーフローを防ぐためには、スタックのリターンアドレス領域を関数が実行さ れなレ、別のメモリ領域に移す方法で対処してレ、る。
[0015] コンパイラにバッファオーバーフローを防ぐ仕組みをする方法としては、非特許文献
2がある。この方法は、 GCCコンパイラに、スタックメモリの下位番地に保護セクション を設けてデータのオーバーライトを検知している。
[0016] また、特許文献 1の場合は、記憶装置に保護数値の領域を定義し、スタックメモリの データを保護数値の領域に保存して保護し、処理指令を実行している。保護数値の 領域にリターンアドレス等が保護されているためサブルーチン等の処理指令が実行 されてもプログラムカウンタが保護される。
非特午文献 1: Openwall Linux kernel patch project,
URL:http://www. openwall.com/linux/
非特許文献 2 : StackGuard: Simple Stack Smash Protection go GCC, URL:
http:// www.immunix .com/^wagle
特許文献 1 :米国公開特許番号 US2001013094? Al?-?2001-08_09、 "Memory device, stack protection system, computer system, compiler, stack protection method, storage medium and program transmission apparatus .
発明の開示
発明が解決しょうとする課題
[0017] 上記のいずれの方法においても、プログラムコードの変更及びリビルドが必要であ る。よって、これらの方法を実施しする際には、時間が掛かる。また、この不正コード の実行を利用している代表的なものは、コンピュータウィルスである。従来からコンビ ユータウィルスからの防止手法はシグネチヤ方式であり、未知の攻撃パターンの場合 は何の効果も無い。そのため、不具合が生じる度にオペレーティングシステムの変更 、パッチファイルの提供が必要とされている。 [0018] 本発明は上述のような技術背景のもとになされたものであり、下記の目的を達成す る。
本発明の目的は、電子計算機のメモリの番地に格納されているデータの改ざん防 止、データ改ざんの検出を行う方法、そのプログラム、プログラムの記録媒体を提供 することである。
本発明の目的は、プログラムの実行時におけるスタックメモリ内のリターンアドレスへ の改ざん防止と検出を行う方法を提供することである。
本発明の他の目的は、ハードウェア、オペレーティングシステム、カーネルモードソ フトウエア、アプリケーションソフトウェアを変更することなく利用できる不正コード実行 の防止機能を提供することである。
本発明の更に他の目的は、アプリケーションソフトウェア及び、カーネルモードソフト ウェアがバッファオーバーフローによる脆弱性を有するときも有効に不正コード実行 の防止機能を提供することである。
本発明の更に他の目的は、不正コードが実行される前に検出し、不正なコードの実 行を抑止することである。
課題を解決するための手段
[0019] 本発明は、前記目的を達成するため、次の手段を採る。
本発明の 1発明の不正コード実行の防止方法は、電子計算機の記憶媒体に格納さ れているプログラムが中央演算処理装置によって実行されるとき、メモリのスタックメモ リ領域に格納されてレ、るリターンアドレス力 不正コードの実行によってオーバーライ トされる前記メモリのバッファオーバーフローを検知し、前記バッファオーバーフロー の発生を防止するための方法である。
[0020] この不正コード実行の防止方法は、前記リターンアドレスをバックアップし、前記不 正コードの実行によって前記リターンアドレスが改ざんされるとき、前記改ざんを前記 中央演算処理装置のデバッグ機能によって検知することを特徴とする。
[0021] また、前記デバッグ機能に利用されるデバッグレジスタに、前記リターンアドレスが 格納されているメモリ番地を記録し、前記デバッグレジスタに記録された前記メモリ番 地の値が改ざんされたとき、前記中央演算処理装置がエラーの信号を出力して前記 検知を行うと良い。
[0022] 更に、前記リターンアドレスを実行プログラムのデータが格納されていないメモリ領 域に保存して 前記バックアップを行うと良い。
また更に、前記スタックメモリ領域に格納されている前記リターンアドレスを、前記バ ックアップされたアドレスと比較して前記バッファオーバーフローを検知する手段を有 すると良い。
[0023] また更に、前記リターンアドレスが改ざんされたとき、前記メモリ番地を保存された前 記リターンアドレスで書き換える制御手段を有すると良い。
また更に、 ttmp,リターンアド'レスが格 されている ttmpスタックメモリ令百 み出し の) †牛にして、 ttmp,リターンアド'レス 呆讜し、 み出し専 の) †牛に言 され ている ttmRttmpスタックメモリ領 ¾に¾き; ί入み 行う に、前記中 演》処理 置 力エラーのィ言 》 力して ttmp n»fiい、 ttmp,ヱラーのィ言 を けて、 ttmp,プロ グラムを停止又は、前記プログラムの流れを制御するための制御手段を有すると良い 前記リターンアドレスは、前記プログラムが実行されるときに呼び出されるプロセス、 前記プロセスから呼び出されるスレッドの内の 1以上のリターンアドレスであると良レ、。
[0024] 本発明の第 2の発明の不正コード実行の防止用プログラムは、電子計算機の記憶 媒体に格納されているプログラムが中央演算処理装置によって実行されるとき、メモリ のスタックメモリ領域に格納されているリターンアドレスが不正コードの実行によってォ 一バーライトされるメモリのバッファオーバーフローを検知し、前記バッファオーバー フローの発生を防止させるように前記電子計算機を動作させるためのプログラムであ る。
この不正コード実行の防止用プログラムは、前記プログラムが前記記憶媒体から呼び 出されるとき、前記プログラムの中の分岐命令を取得して解析するための解析ステツ プと、 前記プログラムのプロセス又はスレッドの前記リターンアドレスを抽出するため の抽出ステップと、前記リターンアドレスが前記スタックメモリ領域に格納される番地を 前記中央演算処理装置のデバッグ機能のデバッグアドレスに登録するための登録ス テツプと、前記プログラムが動作するとき、前記プログラムの流れを制御するための制 御ステップと、前記リターンアドレスと前記番地を登録してバックアップするためのバッ クアップステップとから構成され、前記プログラムの実行時に前記リターンアドレスが 改ざんされるとき、前記デバッグ機能により前記中央演算処理装置がエラーの信号を 出力し、前記プログラムの実行に割り込みを行い、前記プログラムの流れを前記制御 ステップに移動させることを特徴とする。
[0025] また、前記リターンアドレスが書き換えられたとき、前記制御ステップは、前記プログ ラムを停止させるステップを有すると良い。
更に、前記リターンアドレスが書き換えられたとき、前記制御ステップは、前記リターン アドレスをバックアップされた前記リターンアドレスで書き換えするステップを有すると 良い。
[0026] また更に、前記リターンアドレスが書き換えられたとき、前記制御ステップは、前記 書き換えした値を保存するステップを有すると良い。
前記リターンアドレスが格納されている前記スタックメモリ領城を読み出し専用の属件 にして、前記リターンアドレスを保譁するための保譁ステップ 、読み出し専用の属性 に設定されている前記 tmpスタックメモリ領ナ或に書 j入みを行う きに、前 冲央演 算処理装置がヱラーの信号を出力して前記檢知を行うための檢知ステップ 、 前記 エラーの信号を けて、前記プログラムを停止又は、前記プログラムの流れを制御す るための前記制御ステップ を有する 良い。
また更に、前記プログラムは、アプリケーションソフトウェア、オペレーティングシステ ムのソフトウェアモジュール、カーネルモードソフトウェア、これらの中で使用する関数 、サブルーチンから選択される内 1以上であると良い。
[0027] 本発明の第 3の発明の不正コード実行の防止用プログラムの記録媒体は、上述の 不正コード実行の防止用プログラムを記録した記録媒体である。
発明の効果
[0028] 本発明によると、次の効果が奏される。
本発明の不正コード防止方法は、ハードウェア、オペレーティングシステム、カーネ ルモードソフトウェア、アプリケーションソフトウェアを変更することなぐ不正コードの 実行を防止できる。 本発明の不正コード防止方法は、アプリケーションソフトウェア及び、カーネルモー ドソフトウェアが、バッファオーバーフローによる脆弱性を有するときも有効に対応でき る。
本発明の不正コード防止方法は、不正コードが実行される前に検出し、不正なコー ドの実行を抑止できる。
発明を実施するための最良の形態
[0029] 以下、本発明の最良の実施の形態を図面によって具体的に説明する。
[実施の形態 1]
以下、本発明の実施の形態 1を説明する。
本発明は、電子計算機のメインメモリに格納されているデータが書き換えをされ、改 ざんされる行為を検知する方法を提供するものである。また、この方法により、電子計 算機のメインメモリに格納されてレ、るデータが書き換えをされ、改ざんされる行為を検 知し、書き換えまたは改ざんされたデータを復元するためのプログラムを提供する。 更に、本発明は、そのプログラムを記録した記録媒体を提供するものである。この本 発明の実施の形態の概要を説明する。
[0030] CPUのデバッグ機能は、アプリケーションプログラムが実行されるときに発生するェ ラーを検出するための機能である。このためには、 CPUにデバッグレジスタと呼ばれ る複数のメモリを用意しており、メインメモリの特定の番地の動作を監視するために利 用している。このデバッグレジスタに監視する番地のアドレス及び CPU動作を登録し、 この番地の値が変更されるときに CPUがこれを検知してエラー信号を出している。そ して、アプリケーションプログラムの実行に割り込みをして、別のプログラムを動作させ ることが可能である。
[0031] 本実施の形態 1では、バッファオーバーフローによる不正コードの実行を検知し、デ ータ改ざん等を防止するプログラムの動作を説明する。電子計算機上にプログラムが 動作するときに、従来技術で説明したように、プログラム、サブプログラム、関数が呼 び出されるごとにそのリターンアドレスがスタックメモリ領域に格納される。電子計算機 の CPUのデバッグレジスタには、リターンアドレスが格納されているメインメモリの番 地を指定して記録して置く。 [0032] また同時に、リターンアドレスをメインメモリの別の領域にバックアップして置く。この 番地のデータが改ざんされると CPUによってエラーが検知され、実行されているプロ グラムに割り込みをし、制御を別のプログラムに移動させて、データ改ざん、不正コー ドの実行を防止することができる。バックアップしたリターンアドレスを、元の番地に書 き換えし、プログラムを正常な動作に戻す。また、書き換えられたアドレスをバックアツ プして、バッファオーバーフローによるコンピュータウィルス攻撃のパターン解析にも 利用することが可能である。
[0033] 以下、本発明の実施の形態 1の不正コード防止方法は、このデバッグレジスタを利 用したデータの改ざんを検知し、改ざんされたデータを修復する方法を実現させるた めに、ドライバウェア層と、エラールーチンを提供するものである。このドライバウェア 層は、上述のリターンアドレスを把握し、デバッグレジスタに登録し、バックアップする 機能を有する。エラールーチンは、リターンアドレスのデータが改ざんされると、この 改ざんを修復するための機能を提供している。以下、本発明の実施の形態 1を詳細 に説明する。
[0034] 図 1には、本発明の実施の形態の概要を図示している。図 1には、電子計算機上で 動作するソフトウェア 1、ドライバウェア 2、ファイルシステムドライバ 3、ハードディスク 4 が図示されている。通常、実行可能なプログラムはハードディスク 4に実行可能フアイ ル 5として保存され、オペレーティングシステムの呼び出し命令で読み出されメモリ 6 へ格納される。ソフトウェア 1は、電子計算機上に動作しているアプリケーションプログ ラムを意味する。このアプリケーションプログラムは、オペレーティングシステムのカー ネルモード又は、ユーザモードで動作するどのようなプログラムでも良い。
[0035] ドライバウェア 2は、ファイルシステムドライバ 3とオペレーティングシステムが提供す るサービスとの間に位置するもので、オペレーティングシステムから電子計算機の各 デバイスから/へ読み出し/書き込みをするときの制御を行うプログラムである。
[0036] ファイルシステムドライバ 3は、電子計算機に内蔵又は接続されてレ、る記憶装置に 格納されているデータを読み出し、この記憶装置にデータを書き込みするためのドラ ィバである。ハードディスク 4は、通常、電子計算機に内蔵されているハードディスク である。しかし、ソフトウェア 1が格納され、オペレーティングシステムから呼び出され て実行可能であれば、外付けハードディスク、フラッシュメモリ、 CD— ROMなどの外 部記憶装置であっても良い。
[0037] 本実施の形態 1では、オペレーティングシステムからプログラム(図 1の実行可能フ アイル 5)を呼び出しする命令は、ドライバウェア 2を介してファイルシステムドライバ 3 へ送信される形式をとる。
ファイルシステムドライバ 3はハードディスク 4からプログラムを呼び出し、ドライバゥェ ァ 2へ渡す。ドライバウェア 2はプログラムを解析してメインルーチン、サブルーチンを 把握し、それぞれのリターンアドレスを取得し、バッファオーバーフローを検出する制 御を行う。リターンアドレスは、 CALL命令等の分岐命令で出力されてスタックメモリに 格納され、 RET, RETxx命令で戻るためのアドレスである。
この一連の動作を図 3のフローチャートを参照しながら説明する。オペレーティング システム、又はアプリケーションプログラムからプログラム(図 1の実行可能ファイル 5) を起動する(ステップ 1)。ドライバウェア 2は、プログラムの起動を検出する(ステップ 2 )。ドライバウェア 2は、プログラムを解析してメインノレ一チン、サブルーチンを把握し、 それぞれのリターンアドレスを取得する。ドライバウェア 2は、プログラムの起動によつ て生成される引数、ローカル変数、関数アドレスを調べ (ステップ 3)、関数アドレスを 保存する。具体的には、プログラム内で実行されるコール(CALL)、リターン (RET、 RETN)、ジャンプ(JMP)等の分岐命令の実行するイベントを調べリターンアドレスを 取得し、保存する (ステップ 4)。
[0038] そして、ドライバウェア 2は、プログラムが実行している間に、コール命令(Call命令) 等の分岐命令をフックするようにしてドライバウェア 2へ制御を移動できるようにする( ステップ 5)。具体的には、 OSが提供する PsSetLoadlmageNotifyRoutineOを呼び出し 、プロセス起動時に呼び出されるコールバック関数(LoadlmageNotifyRoutine)を登録 して行われる。スレッド生成の場合は、 _beginthread()の開始アドレスを取得し、この開 始アドレスにブレークポイントを設置する。ドライバウェア 2は、プログラムの実行時に、 スタックメモリ上のリターンアドレスの保護と改ざんの検出機能を組み込む(ステップ 6
) o
[0039] リターンアドレスの保護には、上述の CPUのデバッグ機能を利用する。このように、 CPUのデバッグ機能の内、特定のメモリ番地が書き換えられるとエラー出力をする機 能があり、制御が指定された番地へ移動させることが可能である。このとき、 CPUの デバッグレジスタにリターンアドレスのメモリ番地を指定してエラーが検知されるとき、 オペレーティングシステムは割り込み命令を出し、ドライバウェア 2へ制御を移す。 リターンアドレスにこの機能を適用する。よって、リターンアドレスが書き換えられると デバッグ機能によりエラーを検出し、ドライバウェア 2へ制御が移動するように設定さ れる。ドライバウェア 2はステップ 1で指定されたプログラムを実行する (ステップ 7)。
[0040] 図 4は、プログラムが起動されて実行されるときのバッファオーバーフローを検出す る手順を示すフローチャートである。
[0041] オペレーティングシステム又はアプリケーションプログラムからは、プログラムを実行 するときに呼び出し命令(Call命令)が実行されると、 CPUの割り込みが発生し、ドライ バウエア 2に制御が移る(ステップ 10— 11)。ドライバウェア 2はプログラムの実行によ つて生成される引数、ローカル変数、関数アドレスを調べ (ステップ 12)、実行時にお けるスタック 2 ^上のリターンアドレスをデバッグ機能によって保護、又は、記憶する (ステップ 13)。
[0042] この保譏は、リターンアドレスが格納されているスタックメモリを読み出し専用の属性 に設定して行われ このスタックメモリに書き i入みを行うとき CPUがエラーを発生し CPUの割り込みが発生しドライバウェア 2に制御が移るため、リターンアドレスを変更 し改ざんすることができなくなり、保譏することが可能にな 上述の記憶は、スタック メモリ上のリターンアドレスをメモリの別の領域にバックアップして保存す リターンァ ドレスが改ざんされたときは、このバックアップしてリターンアドレスと比較して改ざんを 木金雷 ΪΗするこ が可 になる。
[0043] そして、ドライバウェア 3が命令(IRET)を出し (ステップ 14)、ステップ 1 1で割り込ま れた実行アドレスへ制御を戻す (ステップ 15)、実行する(ステップ 16)。
プログラムの実行中にバッファオーバーフローになると、リターンアドレスが上書きさ れて、 CPUがエラーを出力する。又は、呼び出された関数からの戻る直前で、ドライ バウエアがステップ 13で記憶したリターンアドレスと、スタック上のリターンアドレスを比 較する(ステップ 17 19)。ドライバウェア 2がエラーを検出する(ステップ 20)。そして 、プログラムの実行を中断して、エラールーチンへ制御が移る(ステップ 21)。エラー ルーチン(図示せず)は、エラーが検出されたときに実行され、プログラムの実行が停 止、スタックメモリの内容の保存やリターンアドレスを事前に保存したデータで書き換 えする等の機能を持つプログラムである。このエラールーチンによって、プログラムの 実行を停止、継続、そして不正コードの保存ができる (ステップ 22)。
[0044] 図 2には、電子計算機が外部から攻撃される例を図示している。ネットワークカード
10を介して、ウィルスや不正コード等を有する外部データが送信されてくる。外部デ ータはネットワークカード 10、 NDIS 11、 Winsockl 2を介してメモリ 6に格納される。 外部データがメモリ 6に格納されるとき、プログラムのリターンアドレスの一部又は全部 が書き換えられると、 CPUがエラーを出力し制御がドライバウェア 2に移る。ドライバウ エア 2はこのエラー検出を受けてエラールーチンをフックして対応する。
このように、バッファオーバーフローを利用した不正侵入、攻撃はすべて把握し、対 処すること力 Sできる。実行中のプロセスの停止、スタックメモリの内容の保存、元のプ 口セスの実行継続などができる。プロセスの停止によっては、実行しているプロセスを 停止して、プログラムの暴走を止めることができる。スタックメモリの内容の保存によつ ては、不正コードを保存でき、その後の解析などの作業で攻撃、ウィルスの種類、そ のパターンを把握できる。
[0045] 本実施の形態は、ユーザモードだけで動作するアプリケーションプログラムだけは なくて、カーネルモードで動作するプログラムにも適応される。また、同様な方法でバ ッファオ一バーフローの手法を利用するプログラムであれば全てに適応できる。
[0046] (実施例)
本発明の実施の形態 1の実施例を示す。本実施例では、 Intel社 (登録商標)の 32 ビットアーキテクチャーのプロセッサで、命令トレース機能を実装しているものを想定 してレ、る。具体的には、 PentkimPro (登録商標)以後に開発されたプロセッサ、又はこ のプロセッサと互換性のあるプロセッサである。オペレーティングシステムは、マイクロ ソフト社の Windows2000 (登録商標)である。
ドライバウェア 2が動作し、バッファオーバーフローの検知を行うための準備としての 初期化処理、プログラムが実行されると発生されるプロセスとスレッドを検知し、メイン ルーチン、サブルーチンを把握する。そして、ドライバウェア 2がバッファオーバーフロ ーを検知すると、エラールーチンとしてプロセス中断処理を動作させて対処する。こ れらの動作について、詳細に説明する。
[0047] ドライバウェアが起動すると初期化処理を行う(図 8を参照、説明は後述する。)。こ の初期化処理では、プログラムが呼び出されるとき生成されるプロセスとスレッドの検 知を行う。この初期化処理の詳細は、図 8— 10のフローチャート(後述する)で示して いる。
この初期化処理を行った後は、プログラムが動作を開始する。このプログラムの動 作中に実行されるジャンプ (JMP)、コール(CALL)、リターン (RET)等の分岐命令を すべて登録し、トレースする。 CALL, RET、 RETxx命令が実行されるとき、バッファォ 一バーフローを検知している。 CALL, RET、 RETxx命令の検知は、図 11、 12に示す フローチャートに示している。
[0048] CALL, RET、 RETxx命令の検知された後の処理は、図 13—図 16のフローチャート と、このフローチャートに対応する説明中のプログラムコードに示している。
[0049] (初期化処理)
図 8のフローチャートは、初期化処理の概要を示している。まずは、ドライバウェアが 起動し、バッファオーバーフローを監視するプロセス名をレジストリから読み込む(ステ ップ 100)。そして、監視対象のプロセスのプロセス生成コールバックを登録する(ステ ップ 101)。このプロセス生成コールバックの登録について詳細には、図 9のフローチ ヤートに示している。その後、スタックレコーダを初期化し、メモリ領域を確保する(ステ ップ 102)。そして、監視対象スレッドのスレッド生成イベントのフック設定を行う(ステ ップ 103)。それから、実行命令のトレースを開始する。
プロセス生成コールバックの登録は、 OSが提供する PsSetLoadlmageNotifyRoutineO を呼び出し、プロセス起動時に呼び出されるコールバック関数(
LoadlmageNotifyRoutine)を登録して行われる。このコールバック関数は、次のプロト タイプで定義される。
[0050] [プログラムコード 1 ]
void LoadlmageNotifyRoutine (
PUNICODE_STRING FulllmageName
HANDLE Processld,
PIMAGE— INFO Imagelnfo
[0051] 次に、図 9のフローチャートには、プロセス生成コールバックの登録の手順を示して いる。プロセスが生成されると LoadlmageNotifyRoutine関数が呼び出される(ステップ 110)。以下、 LoadlmageNotifyRoutine内での動作を示す。監視する対象のプロセス かを判定する(ステップ 111)。この判定のときは、 LoadlmageNotifyRoutineの引数 FulllmageNameに、対象となるプロセスモジュール名が存在するかどうかを調べる。存 在してレ、た場合は次の処理に移る(はレ、)。
プロセスモジュールのエントリポイントアドレスの取得する(ステップ 112)。 Windows で使用される実行モジュールファイルの先頭部分 (ヘッダ)を調査し、最初に実行さ れる関数(エントリポイント)のアドレスを取得する。そして、エントリポイントに、ブレー クポイントを設置する(ステップ 113)。このときのプログラムコードの例は次の通りであ る。
[0052]
[プログラムコ一ド 2 ]
PVOID ImageBase = (PVOID)lmagelnfo->lmageBase;
MZ一 HEADER *mz_Header = (MZ—HEADER *)lmageBase;
MZ_NE *mz一 ne = (MZ_NE *)((char *) ImageBase + siz8of(MZ_HEADER));
I AGE_NT_HEADERS *lmageNtHeaders =
(IMAGE一 NT_HEADERS *)((char ImageBase + mz_ne->ne_header);
char *EntryPoint =
(char *)((ULONG)lmagelnfo->lmageBase+
lmageNtHeaders->OptionalHeader.AddressOfEntryPoint); そして、 IA-32命令のトレース機能を有効にして、トレースコールバック関数(
ASO_HookJNT01H)の登録のために IDT (割り込みディスクリプタテーブル)の 01Hを 書き換える(ステップ 114)。この登録のためのプログラムコードは以下の通りである。 [0054]
[プログラムコード 3 ]
IDTR idtr;
PIDTENTRY Oldt;
PIDTENTRY Nldt;
― asm{
SIDT idtr;
Oldt = (PIDTENTRY)MAKELONG(idtr丄 owlDTbase, idtr.HilDTbase);
gOldlNTOI H_Handler= MAKELONG(Oldt[IGATE01].OffsetLow, Oldt[IGATE01].OffsetHigh);
Nldt = &(Oldt【IGATE01】);
― asm{
LEA EAX, ASO— Hook— INT01 H //
MOV EBX, Nldt;
MOV [EBX], AX
SHR EAX, 16
MOV [EBX+6], AX;
LIDT idtr
プロセスが起動した時に最初に実行される命令にハードウェアブレークポイントを設 定し、実行された際にトレースコールバック関数 (ASO_Hook_INT01H)が呼び出され るようにする(ステップ 115)。このためのプログラムコードは以下の通りである。
[0056]
[プログラムコード 4 ]
MOV EAX, KickStartAddress //最初に実行される命令のァドレス
MOV DR0, EAX
MOV EAX, DR7
OR EAX, 0x00000000; II Set LEN0 = 00 (lByte Length)
OR EAX, 0x00000000; II Set RAV0 = 00 (On Execution Only) OR EAX, 0x00000200; II Set GE
OR EAX, 0x00000002; II Enable GO
MOV DR7, EAX; II Set DE7 スタックレコーダの初期化(ステップ 102を参照)は、指定された監視対象のプロセ スのスレッドが生成される度に動的に実施される。スタックレコーダの各スタックは、次 のように定義される。
[0058] [プログラムコード 5]
typedef struct _ASO_STACK_LIST{
LIST— ENTRY m_ListEntry;
ULONG Threadld;
ULONG *StackPointer;
LONG CurrentStackLocation;
}ASO_STACK一 LIST, *PASO_STACK_LIST;
[0059] 図 10のフローチャートには、スレッド生成イベントのフック設定(ステップ 103を参照 )の手順を示している。スレッドが生成される(ステップ 120)と、監視する対象のプロ セスか否かを判定する(ステップ 121)。生成されたスレッドが監視する対象のプロセ スのときは、 _beginthread()の開始アドレスを取得する(ステップ 122)。この開始アドレ スにブレークポイントを設置する(ステップ 123)。それから、トレースを開始する(ステ ップ 124)。
複数スレッドのシステムには、スレッドを生成するカーネル APIである
NtCreateThreadをフックすることで適用させている。そのため、 NtCreateThreadを呼 び出す際に経由されるべクタ 2Eの割り込みハンドラ(ASO_HookJNT2EH)を書き換え る。このときのプログラムコードは次のようになる。
[0060]
[プログラムコード 6]
IDTR idtr;
PIDTENTRY Oldt;
PIDTENTRY Nldt;
一 asm SIDT idtr;
Oldt = (PIDTENTRY)MAKELONG(idtr.LowlDTbase, idtr.HilDTbase);
g0ldlNT2EH_Handler = M A KE LO N G (01 d t[ I G AT E2 E] . Of f set Lo w, 0ldt[IGATE2E].0ffsetHigh);
Nldt = & (Oldt[IGATE2E】);
一 asm {
CLI
LEA EAX, ASO_Hook_INT2EH
MOV EBX, Nldt;
MOV [EBX], AX
SHR EAX, 16
MOV [EBX+6], AX;
LIDT idtr
STI [0061] スレッド生成イベント(CreateThreadO)のフック設定で使用されるプログラムコードは 次のとおりである。
[0062]
[プログラムコード 7 ]
KIRQL Oldlrql;
KeRaiselrq!(HIGH LEVEL, &Oldlrql);
asm(
PUSHAD
II Tor CreateThreadO
MOV EAX, EBP II現在の EBP
MOV EAX, [EAX] II前の EBP(ASO_Hook_INT2BH)
MOV EAX, [EAX] II前の EBP(CreateThread)
ADD EAX, 0x10 II Stack + 10H (IpStartAddress)
MOV EBX, [EAX] II EBX <- Thread address
CMP EBX, 0X7800BE4A II if EBX == — beginthread's start_address (2K+SP0) then
JNZ SET_MEMORYBREAK
II for _beginthread()
MOV EAX, EBP II現在の EBP
MOV EAX, [EAX] II前の EBP(ASO_Hook_INT2BH)
MOV EAX, [EAX] II前の EBP(CreateThread)
MOV EAX, [EAX] II前の EBPし beginthread)
ADD EAX, OxOC II Stack + 0CH (start一 address)
MOV EBX, [EAX] II EBX <- Thread address
SET MEMORYBREAK:
PUSH EBX II Paraml
CALL InstallNewlntOI Handler
POPAD
[0063] このように、一連の初期化処理が終了すると、プログラムが実行され、 CALL、 RET 等の分岐命令をトレースする。次に、トレースしているときの処理を、図 11、 12のフロ 一チャートに示している。トレース処理が開始されると(ステップ 150)、 DR6のトレース フラッグをクリアして(ステップ 151)、 CALL命令、 RET命令を判別している。図 11、図 12の分岐半 IJ定のときは(ステップ 154— 183)、 CALL、 RET, RETN命令を判別し、そ れぞれ「CALL処理へ」、「RET処理へ」、「RENT処理へ」となっている。 「CALL処理へ 」、「RET処理へ」、「RENT処理へ」は、それぞれ図 13、図 14、図 15のフローチャート に示している。 CALL, RET, RETN命令を判別するときのプログラムコードは、次のようになる。
[0064]
[プログラムコード 8 ]
II DR6く- 0x00000000
MOV EAX, DR6
AND EAX, OxFFFFBFFF
MOV DE6, EAX
II EDX:EAX <- LastBranchFromlp
MOV ECX, 0x000001DB; II MSR = 0x01DB (LastBranchFromlp)
RDMSR;
PUSH ES MOV BX, OxOOlB
MOV ES, BX
MOV EDX, EAX
MOV EAX, ES: [EAX]
POP ES
II
II Branch on Instruction
II
CMP AL, 0xE8 II Relative near call
JZ CALL_FOUND
CMP AL, OxFF II Direct near/far call
JZ CALLORJMP一 FOUND
CMP AL, 0x9A II Direct far call
JZ CALL_FOUND
CMP AL, 0xC3 II near RET
JZ RET一 FOUND
CMP AL, OxCB II far RET
JZ RET_FOUND
CMP AL, 0xC2 II near RET with POP
JZ RETN— FOUND
CMP AL, OxCA II far RET with POP
JZ RETN_FOUND
JMP CALL_NOTFOUND
CALLORJMP— FOUND
TEST AH, 0x10 // CALL/2
JNZ CALL— FOUND
TEST AH, 0x18 II CALL/3
JNZ CALL— FOUND
CMP AH, 0xE4 II JMP ESP
JZ JMPESP一 FOUND
JMP CALL— NOTFOUND
[0065] ここでは、 CALL, RET、 RETNの判別は、それぞれ CALL_FOUND、 RET.FOUND RETN_FOUNDとしてコード化されている。プログラムコードの分岐命令にて
CALL_FOUNDにジャンプした場合、 CALL命令が実行されたと見なして、図 13のフロ 一チャートに示す処理が行われる。 RET, RETNの場合は同様である。
図 13には、 CALL命令が実行されるときの処理を示している。 CALL命令の実行が開 始されると(ステップ 200)、 CALL命令に割り与えられたスタックメモリのスタックセグメ ント(CS)のアドレスを取得する(ステップ 201)。そして、 CALL命令で格納されるリタ ーンアドレスのスタックポイントを取得する(ステップ 202)。その後、スタックメモリから リターンアドレスを取得する(ステップ 203)。このときのプログラムコードは次のように なる。
[プログラムコード 9 ]
CALL一 FOUND:
PUSH ES
II Get Stack segment (CS)
MOV ECX, EBP
ADD ECX, + 4 + 4 + 4 + 4 + 4
MOV EAX, [ECX]
MOV ES, AX
II Get Stack pointer
MOV ECX, EBP
ADD ECX, + 4 + 4 + 4 + 4
LES EDX, [ECX] // Now EDX point to Stack Address
II Get RetlP
MOV ECX, EDX
MOV AX, 0x001 B // Usermode Only
MOV ES, AX II
MOV EDX, ES:[ECX] 〃 Retrieve RetlP on Stack
II
II Now EDX point to RetlP on Stack
II
POP ES この取得したリターンアドレスをスタックレコーダに登録する(ステップ 204)。このとき のプログラムコードは、次のようになる。 [0068]
[プログラムコード l 0 ]
KeRaiselrql(HIGH_LEVEL, &Oldlrql);
PASO-STACK-UST StackList = (PASO_STACK_LIST)gStackList[Threadld];
if (StackList == 0){
II Error
}else if (StackList->CurrentStackLocation > STACK_LIMIT){
StackList = NULL;
}else if (StackList->CurrentStackLocation >= 0){
StackList->StackPointer[StackList->CurrentStackLocation] = ExpectedRetlp;
StackList->CurrentStackLocation ++;
KeLowerlrql(Oldlrql);
[0069] そして、 MSRと EFLAGを設定して命令トレースを再開する(ステップ 205、 206)。
IRETDにて処理を完了。
図 14には、 RET命令が実行されるときの処理を示している。 RET命令の実行が開始 されると(ステップ 250)、 RET命令に割り与えられたスタックメモリのスタックセグメント( CS)のアドレスを取得する(ステップ 251)。そして、 RET命令で指定されたリターンァ ドレスのスタックポインタを取得する(ステップ 252)。その後、スタックメモリからリタ一 ンアドレスを取得する(ステップ 253)。このときのプログラムコードは次のようになる。
[0070]
[プログラムコード 1 1 ]
RET—FOUND:
PUSH ES
II Get Stack segment (CS)
MOV ECX, EBP
ADD ECX, + 4 + 4 + 4 + 4 + 4
MOV EAX, [ECX1
MOV ES, AX
II Get Stack pointer
MOV ECX, EBP
ADD ECX, + 4 + 4 + 4 + 4
MOV EAX, [ECX]
LES EDX, [ECX] II Now EDX point to Stack Address
SUB EDX, +4 II Back 4Bytes from Current Stack Address MOV ECX, EDX
MOV AX, 0x001 B
MOV ES, AX
MOV EDX, ES:[ECX] [0071] そして、スタックレコーダからリターンアドレスと同じ値があるかを検索する(ステップ 254)。リターンアドレスは、この RET命令に対応する CALL命令のときにスタックレコ ーダに登録されているものである。しかし、リターンアドレスが改ざんされた場合は、ス タックレコーダの中力 同じアドレスが見つ力 なレ、。このときは、プロセス中断処理( 次のコードの Terminate_VirusCodeO)へ移る(ステップ 260)。同じアドレスが見つかる と、スタックレコーダから 1レコードを削除(ステップ 255)する。このときのプログラムコ ードは次のようになる。
[0072]
[プログラムコード 1 2 ]
KeRaiselrql(HIGH— LEVEL, &Oldlrql);
PASO— STACK_LIST StackList = (PASO_STACK_LIST)gStackList[Threadld];
if (StackList == 0){
II Stack not found
jelse if (StackList->CurrentStackLocation > 0){
StackList->CurrentStackLocation—;
ULONG ExpectedRetlp
= StackList->StackPointer[StackList->CurrentStackLocation];
StackList->StackPointer[StackList->CurrentStackLocation] = 0;
if (ExpectedRetlp != Tolp){
LONG i;
BOOLEAN StackFound = FALSE;
for (i = Stackし ist->CurrentStackLocation; i >= 0; i -){
if (StackList->StackPointer[i] == Tolp){
LONG j;
for (j = i; j <= StackList->CurrentStackLocation; j++){
StackList->StackPointer[j] = 0;
StackList->CurrentStackLocation = i;
StackFound = TRUE;
break; if (!StackFound){
II Not found
Terminate_VirusCode(Fromlp, Tolp, ExpectedRetlp);
}else{
DbgPrint(" Illegal Stack LocationVn");
KeLowerlrql(Oldlrql);
[0073] そして、 MSRと EFLAGを設定して命令トレースを再開する(ステップ 256、 257)。
IRETDにて処理を完了。 図 15には、 RETN命令が実行されるときの処理を示している。 RETN命令の実行が開 始されると(ステップ 300)、 RETN命令に害 IJ
ント(CS)のアドレスを取得する(ステップ 301)。そして、 RETN命令で指定されたリタ ーンアドレスのスタックポイントを取得する(ステップ 302)。その後、スタックメモリから リターンアドレスを取得する(ステップ 303)。このときのプログラムコードは次のように なる。
[0074]
[プログラムコード 1 3 ]
RETN_FOUND:
II Get Stack Byte Length
ADD EDX, +1
MOV EAX, [EDX]
PUSH ES PUSH EAX
II Get Stack segment (CS)
MOV ECX, EBP
ADD ECX, + 4 + 4 + 4 + 4 + 4
MOV EAX, [ECX]
MOV ES, AX
II Get Stack pointer
MOV ECX, EBP
ADD ECX, + 4 + 4 + 4 + 4
MOV EAX, [ECX]
LES EDX,【ECX] II Now EDX point to Stack Address
POP EAX
MOVZX EAX, EAX
SUB EDX, EAX
SUB EDX, +4
MOV ECX, EDX
MOV AX, 0x001 B
MOV ES, AX
MOV EDX, ES:[ECX]
[0075] そして、スタックレコーダからリターンアドレスと同じ値があるかを検索する(ステップ 304)。リターンアドレスは、この RETN命令に対応する CALL命令のときにスタックレコ ーダに登録されているものである。しかし、リターンアドレスが改ざんされた場合は、ス タックレコーダの中力も同じアドレスが見つ力もなレ、。このときは、プロセス中断処理( 次のコードの Terminate_VirusCodeO)へ移る(ステップ 310)。同じアドレスが見つ力、る と、スタックレコーダから 1レコードを削除(ステップ 305)する。このときのプログラムコ ードは次のようになる。
[0076]
[プログラムコード 1 4 ]
KeRaiselrql(HIGH— LEVEL, &Oldlrql);
PASO-STACK-LIST StackList = (PASO_STACK_LIST)gStackList[Threadld];
if (StackList == 0){
II Stack not found
}else if (StackList->CurrentStackLocation > 0){
StackList->CurrentStackLocation—;
ULONG ExpectedRetlp
= StackList->StackPointer[StackList->CurrentStackLocation];
StackList->StackPointer[StackList->CurrentStackLocation] = 0;
if (ExpectedRetlp != Tolp){
LONG i;
BOOLEAN StackFound = FALSE;
for (i = StackList->CurrentStackLocalion; i >= 0; i— ){
if (StackList->StackPointer[i] == Tolp){
LONG j;
for (j = i; j <= StackList->CurrentStackLocation; j++){
StackList->StackPointer[j] = 0;
}
StackList->CurrentSね ckLocation = i;
StackFound = TRUE;
break; if (!StackFound){
II Not found
Terminate_VirusCode(Fromlp, Tolp, ExpectedRetlp);
}else{
DbgPrint(" Illegal Stack LocationVn");
KeLowerlrql(Oldlrql);
[0077] そして、 MSRと EFLAGを設定して命令トレースを再開する(ステップ 306、 307)。
IRETDにて処理を完了。
図 16には、 JMP ESP処理が実行されるときの処理を示している。 JMP ESPは、例え ばネットワークを経由して侵入するウィルス等がスタックメモリ上のプログラムコードを 実行するために必要な命令である。そのためスタックのリターンアドレスの検索結果に 依存することなぐ JMPESP命令を使用する実行モジュールは稀であるため禁止対象 としてある。 JMP ESPが判別すると、プロセス中断処理を行う(ステップ 351)。 ステップ 260、 310、 351のプロセス中断処理は、 RET、 RETN命令の次に実行され る命令のアドレスを取得し、そこを不正な命令(INT3等)に書き換える。プロセスの実 行を継続させ、不正な命令でプロセスを停止させる。このときのプログラムコードは次 のようになる。
[プログラムコード 1 5 ]
void— stdcall Terminate— VirusCode(ULONG Fromlp, ULONG Tolp)
IsDetected = TRUE;
II Rewrite Fromlp(Next instruction of JMP ESP) to INT3
asm!
PUSH EAX PUSH EDX
MOV AL, OxCC // INT 3
MOV EDX, Fromlp
MOV SS:[EDX], AL
POP EDX POP EAX
[0079] 上述したように、バッファオーバーフローを利用した不正侵入、攻撃はすべて把握 し、対処すること力できる。実行しているプロセスを停止して、プログラムの暴走を止め ること力 Sできる。
このような方法でバッファオーバーフローを実現可能な、すべてのオペレーティング システムにも適応可能である。
[0080] (その他の実施の形態)
産業上の利用可能性
[0081] 本発明は、コンピュータウィルス対策、外部からの不正侵入の防止、セキュリティが 要求される分野のすべてに利用される。特に、ネットワークに接続して利用されるパソ コン、スーパーコンピュータ、サーバを利用したシステムに利用してよレ、。個人情報保 護、電子ファイルのセキュリティが要求される電子政府、軍事、防衛関連のシステムに 用いられる。 また、プログラムの欠陥、不正コードの利用を検知するとき利用すると良い。
図面の簡単な説明
[0082] [図 1]図 1は、本発明の概要を図示している概念図である。
[図 2]図 2は、本発明のバッファオーバーフローによるエラー検出を示す概念図である
[図 3]図 3は、実行ファイルのロード時の手順を示すフローチャートである。
[図 4]図 4は、実行ファイルの実行時の手順を示すフローチャートである
[図 5]図 5は、メモリの構造を示す図である。
[図 6]図 6は、プログラムのメインルーチン、サブルーチンを例示した図ある。
[図 7]図 7は、スタックメモリの構造を示す図ある。
[図 8]図 8のは、ドライバウェアが起動するときの初期化処理の手順を示すフローチヤ ートである。
[図 9]図 9は、プロセス生成コールバックの登録の手順を示すフローチャートである。
[図 10]図 10は、スレッド生成イベントのフック設定の手順を示しているフローチャート である。
[図 11]図 11は、 CALL, RET等の分岐命令をトレースしているときの処理の流れを示 すフローチャートである。
[図 12]図 12は、図 11の CALLorJMP処理の処理手順を示すフローチャートである。
[図 13]図 13は、 CALL命令が実行されるときの処理を示すフローチャートである。
[図 14]図 14は、 RET命令が実行されるときの処理を示すフローチャートである。
[図 15]図 15は、 RET命令が実行されるときの処理を示すフローチャートである。
[図 16]図 16は、 JPM ESP処理の手順を示すフローチャートである。
符号の説明
[0083] 1…ソフトウェア
2…ドライバウェア
4…ハードディスク 5…実行可能ファイル …メモリ
…ネットワークカード- --NDIS
- --Winsock

Claims

請求の範囲
電子計算機の記憶媒体に格納されているプログラムが中央演算処理装置によって 実行されるとき、
メモリのスタックメモリ領域に格納されているリターンアドレス力 不正コードの実行 によってオーバーライトされる前記メモリのバッファオーバーフローを検知し、前記バ ッファオ一バーフローの発生を防止する方法において、
Figure imgf000029_0001
前記不正コードの実行によって前記リターンアドレスが改ざんされるとき、前記改ざ んを前記中央演算処理装置のデバッグ機能によって検知する
ことを特徴とする不正コード実行の防止方法。
[2] 請求項 1において、
前記デバッグ機能に利用されるデバッグレジスタに、前記リターンアドレスが格納さ れてレ、るメモリ番地を記録し、
前記デバッグレジスタに記録された前記メモリ番地の値が改ざんされたとき、前記中 央演算処理装置がエラーの信号を出力して前記検知を行う
ことを特徴とする不正コード実行の防止方法。
[3] 請求項 1又は 2において、
前記リターンアドレスを実行プログラムのデータが格納されていなレ、メモリ領域に保存 して前記バックアップを行う
ことを特徴とする不正コード実行の防止方法。
[4] 請求項 3において、
前記スタックメモリ領域に格納されている前記リターンアドレスを、前記バックアップ されたアドレスと比較して前記バッファオーバーフローを検知する手段を有する ことを特徴とする不正コード実行の防止方法。
[5] 請求項 3又は 4において、
前記リターンアドレスが改ざんされたとき、前記メモリ番地を保存された前記リターン アドレスで書き換える制御手段を有する
ことを特徴とする不正コード実行の防止方法。
[6] 請求項 1又は 2において、
前記リターンアドレスが格納されている前記スタックメモリ領域を読み出し専用の属性 にして、前記リターンアドレスを保護し、
読み出し専用の属性に設定されている前記前記スタックメモリ領域に書き込みを行う ときに、前記中央演算処理装置がエラーの信号を出力して前記検知を行い、 前記エラーの信号を受けて、前記プログラムを停止又は、前記プログラムの流れを 制御するための制御手段を有する
ことを特徴とする不正コード実行の防止方法。
[7] 請求項 1から 6の中から選択されるいずれか 1項において、
前記リターンアドレスは、前記プログラムが実行されるときに呼び出されるプロセス、 前記プロセスから呼び出されるスレッドの内の 1以上のリターンアドレスである ことを特徴とする不正コード実行の防止方法。
[8] 電子計算機の記憶媒体に格納されているプログラムが中央演算処理装置によって 実行されるとき、
メモリのスタックメモリ領域に格納されているリターンアドレスが不正コードの実行に よってオーバーライトされるメモリのバッファオーバーフローを検知し、前記バッファォ 一バーフローの発生を防止させるように前記電子計算機を動作させる不正コード実 行の防止用プログラムにおいて、
前記プログラムが前記記憶媒体から呼び出されるとき、前記プログラムの中の分岐 命令を取得して解析するための解析ステップと、
前記プログラムのプロセス又はスレッドの前記リターンアドレスを抽出するための抽 出ステップと、
前記リターンアドレスが前記スタックメモリ領域に格納される番地を前記中央演算処 理装置のデバッグ機能のデバッグアドレスに登録するための登録ステップと、 前記プログラムが動作するとき、前記プログラムの流れを制御するための制御ステツ プと、
前記リターンアドレスと前記番地を登録してバックアップするためのバックアップステ ップと から構成され、
前記プログラムの実行時に前記リターンアドレスが改ざんされるとき、前記デバッグ 機能により前記中央演算処理装置がエラーの信号を出力し、前記プログラムの実行 に割り込みを行レ、、前記プログラムの流れを前記制御ステップに移動させる ことを特徴とする不正コード実行の防止用プログラム。
請求項 8において、
前記リターンアドレスが書き換えられたとき、前記制御ステップは、前記プログラムを 停止させるステップを有する
ことを特徴とする不正コード実行の防止用プログラム。
請求項 8又 9において、
前記リターンアドレスが書き換えられたとき、前記制御ステップは、前記リターンアド レスをバックアップされた前記リターンアドレスで書き換えするステップを有する ことを特徴とする不正コード実行の防止用プログラム。
請求項 8又 9において、
前記リターンアドレスが書き換えられたとき、前記制御ステップは、前記書き換えし た値を保存するステップを有する
ことを特徴とする不正コード実行の防止用プログラム。
請求項 8において、
前記リターンアドレスが格納されている前記スタックメモリ領域を読み出し専用の属性 にして、前記リターンアドレスを保護するための保護ステップと、
読み出し専用の属性に設定されている前記前記スタックメモリ領域に書き込みを行う ときに、前記中央演算処理装置がエラーの信号を出力して前記検知を行うための検 知ステップと、
前記エラーの信号を受けて、前記プログラムを停止又は、前記プログラムの流れを 制御するための前記制御ステップとを有する
ことを特徴とする不正コード実行の防止用プログラム。
請求項 8から 12の中から選択される 1項において、
前記プログラムは、アプリケーションソフトウェア、オペレーティングシステムのソフト ウェアモジュール、カーネルモードソフトウェア、これらの中で使用する関数、サブル 一チンから選択される内 1以上である
ことを特徴とする不正コード実行の防止用プログラム。
請求項 8から 13の中から選択される 1項に記載された、不正コード実行の防止用プ ログラムを記録した不正コード実行の防止用プログラムの記録媒体。
PCT/JP2004/012858 2003-09-04 2004-09-03 不正コード実行の防止方法および防止プログラム WO2005024630A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US10/570,502 US8042179B2 (en) 2003-09-04 2004-09-03 False code execution prevention method, program for the method, and recording medium for recording the program
EP04772807A EP1662379A4 (en) 2003-09-04 2004-09-03 FALSE COORDINATE PROCEDURE AND PREVENTION PROGRAM
JP2005513686A JP4518564B2 (ja) 2003-09-04 2004-09-03 不正コード実行の防止方法、不正コード実行の防止用プログラム、及び不正コード実行の防止用プログラムの記録媒体

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2003-312517 2003-09-04
JP2003312517 2003-09-04

Publications (1)

Publication Number Publication Date
WO2005024630A1 true WO2005024630A1 (ja) 2005-03-17

Family

ID=34269739

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2004/012858 WO2005024630A1 (ja) 2003-09-04 2004-09-03 不正コード実行の防止方法および防止プログラム

Country Status (6)

Country Link
US (1) US8042179B2 (ja)
EP (1) EP1662379A4 (ja)
JP (1) JP4518564B2 (ja)
KR (1) KR100777938B1 (ja)
CN (1) CN1886728A (ja)
WO (1) WO2005024630A1 (ja)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008083382A1 (en) * 2006-12-29 2008-07-10 Microsoft Corporation Automatic vulnerability detection and response
JP2010224908A (ja) * 2009-03-24 2010-10-07 Fujitsu Semiconductor Ltd 情報処理装置およびデータ修復方法
JP4572259B1 (ja) * 2009-04-27 2010-11-04 株式会社フォティーンフォティ技術研究所 情報機器、プログラム及び不正なプログラムコードの実行防止方法
US8141163B2 (en) * 2007-07-31 2012-03-20 Vmware, Inc. Malicious code detection
WO2015044993A1 (ja) * 2013-09-24 2015-04-02 株式会社 エーティーティーコンサルティング プロセッサ、処理装置、プログラム作成方法
JP2017123119A (ja) * 2016-01-08 2017-07-13 株式会社デンソー 電子制御装置
JPWO2021059478A1 (ja) * 2019-09-27 2021-04-01

Families Citing this family (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7971255B1 (en) * 2004-07-15 2011-06-28 The Trustees Of Columbia University In The City Of New York Detecting and preventing malcode execution
JP3768516B1 (ja) * 2004-12-03 2006-04-19 株式会社ソニー・コンピュータエンタテインメント マルチプロセッサシステムとそのシステムにおけるプログラム実行方法
US7849444B2 (en) * 2004-12-21 2010-12-07 National Instruments Corporation Test executive with buffer overwrite detection for parameters of user-supplied code modules
US7607122B2 (en) * 2005-06-17 2009-10-20 Microsoft Corporation Post build process to record stack and call tree information
US7930733B1 (en) * 2006-04-10 2011-04-19 At&T Intellectual Property Ii, L.P. Method and system for execution monitor-based trusted computing
US20080148399A1 (en) * 2006-10-18 2008-06-19 Microsoft Corporation Protection against stack buffer overrun exploitation
FR2910144A1 (fr) * 2006-12-18 2008-06-20 St Microelectronics Sa Procede et dispositif de detection errones au cours de l'execution d'un programme.
CN101241464B (zh) * 2007-02-05 2010-08-18 中兴通讯股份有限公司 一种检测堆栈帧破坏的方法
CN101295278B (zh) * 2007-04-23 2010-08-11 大唐移动通信设备有限公司 定位被改写代码段所在进程的方法及装置
CN101414340B (zh) * 2007-10-15 2015-12-02 北京瑞星信息技术有限公司 一种防止远程线程启动的方法
WO2009055914A1 (en) * 2007-11-02 2009-05-07 Klocwork Corp. Static analysis defect detection in the presence of virtual function calls
US8099636B2 (en) * 2008-07-15 2012-01-17 Caterpillar Inc. System and method for protecting memory stacks using a debug unit
CA2806368C (en) * 2009-07-29 2019-04-30 Reversinglabs Corporation Portable executable file analysis
US20120227033A1 (en) * 2011-03-02 2012-09-06 Lei Yu Method and apparatus for evaluating software performance
US8935674B2 (en) * 2012-08-15 2015-01-13 International Business Machines Corporation Determining correctness conditions for use in static analysis
US20140283060A1 (en) * 2013-03-15 2014-09-18 Oracle International Corporation Mitigating vulnerabilities associated with return-oriented programming
CN103514405B (zh) * 2013-07-08 2016-08-10 北京深思数盾科技股份有限公司 一种缓冲区溢出的检测方法及系统
CN103559439A (zh) * 2013-11-19 2014-02-05 浪潮(北京)电子信息产业有限公司 一种缓冲区溢出检测方法及系统
US9245110B2 (en) 2013-12-17 2016-01-26 International Business Machines Corporation Stack entry overwrite protection
US9703948B2 (en) * 2014-03-28 2017-07-11 Intel Corporation Return-target restrictive return from procedure instructions, processors, methods, and systems
CN105426752A (zh) * 2015-11-24 2016-03-23 无锡江南计算技术研究所 缓冲区溢出保护方法
CN106203069B (zh) * 2016-06-27 2019-10-15 珠海豹趣科技有限公司 一种动态链接库文件的拦截方法、装置及终端设备
US10540498B2 (en) * 2016-08-12 2020-01-21 Intel Corporation Technologies for hardware assisted native malware detection
US10481999B2 (en) 2016-12-05 2019-11-19 Microsoft Technology Licensing, Llc Partial process recording
US10467407B2 (en) * 2017-03-30 2019-11-05 Check Point Advanced Threat Prevention Ltd. Method and system for detecting kernel corruption exploits
US10613864B2 (en) 2018-03-16 2020-04-07 Texas Instruments Incorporated Processor with hardware supported memory buffer overflow detection
CN109033821A (zh) * 2018-07-12 2018-12-18 郑州云海信息技术有限公司 一种栈溢出攻击防护系统及方法
JP2022502723A (ja) * 2018-10-18 2022-01-11 スターナム リミテッドSternum Ltd. スタック破損のエクスプロイトに対する中間コードファイルにおけるセキュリティ緩和手段の適用
US11182472B2 (en) * 2019-09-30 2021-11-23 Vmware, Inc. Security in a computing environment by monitoring expected operation of processes within the computing environment
CN112784261B (zh) * 2021-01-04 2023-10-27 北京蓝军网安科技发展有限责任公司 用于程序运行的方法及相应的系统、计算机设备和介质
US11900154B2 (en) * 2021-03-08 2024-02-13 Dell Products L.P. Enabling modern standby for unsupported applications

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH02304635A (ja) * 1989-05-19 1990-12-18 Pfu Ltd プログラム暴走検知方法
JPH09128267A (ja) * 1995-10-31 1997-05-16 Nec Corp データ処理装置およびデータ処理方法
JP2001511271A (ja) * 1997-01-15 2001-08-07 シーメンス アクチエンゲゼルシヤフト ソフトウェアプログラムの規定通りの実行を監視するための方法

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH03175537A (ja) * 1989-12-04 1991-07-30 Nec Corp デバッグ用マイクロプロセッサのエラー制御装置
JPH05216717A (ja) * 1992-01-31 1993-08-27 Nec Corp デバッガのトレース機能
JPH09128277A (ja) * 1995-10-27 1997-05-16 Nec Software Ltd 複数os搭載システムにおけるファイル管理方式
JPH11120028A (ja) * 1997-10-13 1999-04-30 Nec Corp プログラム移植サポート方式
JP3339482B2 (ja) * 1999-12-15 2002-10-28 日本電気株式会社 分散デバッグ装置及びデバッグ方法並びに制御プログラムを記録した記録媒体
JP3552627B2 (ja) * 2000-02-04 2004-08-11 インターナショナル・ビジネス・マシーンズ・コーポレーション スタック保護システム、コンピュータシステム、コンパイラ、スタック保護方法および記憶媒体
US6915416B2 (en) * 2000-12-28 2005-07-05 Texas Instruments Incorporated Apparatus and method for microcontroller debugging
CA2345416C (en) * 2001-04-27 2005-05-03 Ibm Canada Limited-Ibm Canada Limitee High performance debugging in a message flow environment
US6947047B1 (en) * 2001-09-20 2005-09-20 Nvidia Corporation Method and system for programmable pipelined graphics processing with branching instructions
US7853803B2 (en) * 2001-09-28 2010-12-14 Verizon Corporate Services Group Inc. System and method for thwarting buffer overflow attacks using encrypted process pointers
US7243340B2 (en) * 2001-11-15 2007-07-10 Pace Anti-Piracy Method and system for obfuscation of computer program execution flow to increase computer program security
US20030126590A1 (en) * 2001-12-28 2003-07-03 Michael Burrows System and method for dynamic data-type checking
US6996677B2 (en) * 2002-11-25 2006-02-07 Nortel Networks Limited Method and apparatus for protecting memory stacks

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH02304635A (ja) * 1989-05-19 1990-12-18 Pfu Ltd プログラム暴走検知方法
JPH09128267A (ja) * 1995-10-31 1997-05-16 Nec Corp データ処理装置およびデータ処理方法
JP2001511271A (ja) * 1997-01-15 2001-08-07 シーメンス アクチエンゲゼルシヤフト ソフトウェアプログラムの規定通りの実行を監視するための方法

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
COWAN C.: "Darpa Information Survivability Conference and Exposition, 2000, DISCE X '00, Proceedings Hilton Head, SC, USA 25-27 Jan. 2000, Las Alamitos, CA, USA, IEEE Comput. SOC", vol. 2, 25 January 2000, article "Buffer Overflows: Attacks and Defenses for the Vulnerability of the Decade", pages: 119 - 129
JUN XU ET AL.: "Architecture Support for Defending against Buffer-Overflow Attacks", CRHC TECHNICAL REPORT, July 2002 (2002-07-01), pages 1 - 18
See also references of EP1662379A4
SKADRON, E. ET AL.: "Improving Prediction for Procedure Returns with Re turn-Address-Stack Repair Mechanisms", MICRO-31. PROCEEDINGS OF THE 31ST. ANNUAL ACM/IEEE INTERNATIONAL SYMPOSIUM ON MICROARCHITECTURE, 30 November 1998 (1998-11-30)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008083382A1 (en) * 2006-12-29 2008-07-10 Microsoft Corporation Automatic vulnerability detection and response
US8453245B2 (en) 2006-12-29 2013-05-28 Microsoft Corporation Automatic vulnerability detection and response
US8141163B2 (en) * 2007-07-31 2012-03-20 Vmware, Inc. Malicious code detection
JP2010224908A (ja) * 2009-03-24 2010-10-07 Fujitsu Semiconductor Ltd 情報処理装置およびデータ修復方法
JP4572259B1 (ja) * 2009-04-27 2010-11-04 株式会社フォティーンフォティ技術研究所 情報機器、プログラム及び不正なプログラムコードの実行防止方法
JP2010257275A (ja) * 2009-04-27 2010-11-11 Fourteenforty Research Institute Inc 情報機器、プログラム及び不正なプログラムコードの実行防止方法
WO2015044993A1 (ja) * 2013-09-24 2015-04-02 株式会社 エーティーティーコンサルティング プロセッサ、処理装置、プログラム作成方法
JP2017123119A (ja) * 2016-01-08 2017-07-13 株式会社デンソー 電子制御装置
JPWO2021059478A1 (ja) * 2019-09-27 2021-04-01
WO2021059478A1 (ja) * 2019-09-27 2021-04-01 日本電気株式会社 情報処理装置、情報処理方法、及び、プログラムが記録された非一時的なコンピュータ可読媒体
JP7283552B2 (ja) 2019-09-27 2023-05-30 日本電気株式会社 情報処理装置、情報処理方法、及び、プログラム

Also Published As

Publication number Publication date
US20070101317A1 (en) 2007-05-03
US8042179B2 (en) 2011-10-18
KR100777938B1 (ko) 2007-11-21
JPWO2005024630A1 (ja) 2007-11-08
EP1662379A4 (en) 2008-12-03
EP1662379A1 (en) 2006-05-31
CN1886728A (zh) 2006-12-27
JP4518564B2 (ja) 2010-08-04
KR20060056998A (ko) 2006-05-25

Similar Documents

Publication Publication Date Title
WO2005024630A1 (ja) 不正コード実行の防止方法および防止プログラム
US11106792B2 (en) Methods and systems for performing a dynamic analysis of applications for protecting devices from malwares
RU2637997C1 (ru) Система и способ обнаружения вредоносного кода в файле
US7996904B1 (en) Automated unpacking of executables packed by multiple layers of arbitrary packers
Castro et al. Fast byte-granularity software fault isolation
Guo et al. A study of the packer problem and its solutions
US9275229B2 (en) System to bypass a compromised mass storage device driver stack and method thereof
Volckaert et al. Cloning your gadgets: Complete ROP attack immunity with multi-variant execution
Wojtczuk Subverting the Xen hypervisor
Lanzi et al. K-Tracer: A System for Extracting Kernel Malware Behavior.
US8510828B1 (en) Enforcing the execution exception to prevent packers from evading the scanning of dynamically created code
US8104089B1 (en) Tracking memory mapping to prevent packers from evading the scanning of dynamically created code
JP2018041438A5 (ja)
US7284276B2 (en) Return-to-LIBC attack detection using branch trace records system and method
Kawakoya et al. Api chaser: Anti-analysis resistant malware analyzer
Böhne Pandora’s bochs: Automatic unpacking of malware
WO2004075060A1 (ja) コンピュータウィルス検出装置
US8819822B1 (en) Security method for detecting intrusions that exploit misinterpretation of supplied data
CN117725583A (zh) 基于虚拟机自省的Linux恶意代码检测方法与系统
Gupta et al. Dynamic code instrumentation to detect and recover from return address corruption
Bacs et al. System-level support for intrusion recovery
Shields Anti-debugging–a developers view
Singh Breaking the sandbox
Harbour Stealth secrets of the malware ninjas
EP3293660A1 (en) System and method of detecting malicious code in files

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200480028989.1

Country of ref document: CN

AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2005513686

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 1020067003788

Country of ref document: KR

WWE Wipo information: entry into national phase

Ref document number: 2004772807

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2004772807

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2007101317

Country of ref document: US

Ref document number: 10570502

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 10570502

Country of ref document: US