JP2010049627A - Computer virus detection system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a computer virus detection system for surely detecting computer virus having a concealment function such as "rootkit". <P>SOLUTION: A computer virus detection object includes: a virtualization means which operates a first guest OS which provides an execution environment of an application and a second guest OS which provides an execution environment of a virus detection means separately from each other; and a first means which directly accesses a virtual storage means to be used by the application and the first guest OS to detect whether computer virus exists in the virtual storage means. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to a computer virus (or malware) detection system, and more particularly to a computer virus detection system called a “rootkit”.

Conventionally, as a computer virus detection technique, a method of collating the contents of a monitored file with a virus pattern (signature) has been typical.
Also, as disclosed in Patent Document 1 below, there is known a system in which an event monitoring unit is provided in a kernel space corresponding to an OS (operating system) to monitor a sign of virus intrusion.

JP 2006-65835 A

However, in the above-mentioned conventional technology, since the virus intrusion is monitored through the interface provided by the OS even though it is the kernel space, a computer virus called “rootkit” with a function of hiding itself is detected. There is a problem that you can not do.
A “rootkit” hooks a program interface that is widely used from an application or system library, hides itself, and escapes detection. For example, there is a rootkit that hooks a programming interface for obtaining a list of active processes and returns a process list to a caller, excluding its own process information. In another rootkit, some modules of virtual memory are modified to hide their data so that viruses cannot be detected from the memory.

  The present invention is intended to solve such problems, and an object of the present invention is to provide a computer virus detection system capable of reliably detecting a computer virus having a function of hiding itself such as a “rootkit”. Is to provide.

In order to achieve the above object, a computer virus detection system according to the present invention provides a first guest OS providing an application execution environment and a virus detection means execution environment in a computer virus detection target computer. With virtualization means for operating two guest OSes isolated from each other,
The virus detecting means is
The virtual storage means used by the application and the first guest OS is directly accessed, and first means for detecting whether a computer virus exists in the virtual storage means is provided.
The first means detects a computer virus by comparing the process list traced from the process management block pointer in the virtual storage means with the process list obtained from the interface provided by the first guest OS. It is characterized by providing the means to do.
Further, the first means compares the thread list traced from the state of the virtual storage means and the thread management block pointer by priority with the thread list obtained from the interface provided by the first guest OS. A means for detecting a computer virus is provided.
Whether the first means is a process traceable from the process management block pointer of the virtual storage means is a process corresponding to the thread traceable from the thread management block pointer according to the status and priority of the virtual storage means. A means for detecting a computer virus by determining is provided.
A first means for identifying a physical memory address using a virtual address traced from the process management block of the first guest OS and a physical address conversion table and detecting a computer virus in the physical memory; It is characterized by providing.
Further, the first means compares the list of files accessible from the first guest OS with the file list obtained from the virtual storage means used by the first guest OS, thereby preventing computer viruses. It comprises a means for detecting.
Further, the virtual machine constructed by the virtualization means detects a computer virus instead of the virus detection means.

  According to the present invention, the virus detection means executed in the operating environment of the second guest OS that operates isolated from the first guest OS that provides the application execution environment is the virtual storage means (virtual memory, virtual disk). ) And directly searching for viruses, it is possible to detect rootkit viruses that cannot be detected by ordinary virus detection technology. In particular, by directly searching the text area of the virtual storage means, it becomes possible to detect a virus recorded as an execution code in the virtual storage means. The same applies to disks and processes.

Hereinafter, the present invention will be described in detail with reference to embodiments shown in the drawings.
FIG. 1 is a system configuration diagram showing a first embodiment of the present invention.
In FIG. 1, reference numeral 101 denotes a general application that runs on a virus search target computer. Reference numeral 102 denotes a monitoring agent that operates on a virus detection target computer, and notifies the virus detection means 103 of information on accessible files and processes through an interface provided by a normal OS (first guest OS described later). The information notified here may be information that has been falsified by the rootkit.
Reference numeral 103 denotes virus detection means, which is a main component of virus detection in the present invention, and directly searches the memory and disk of the search target computer.
Reference numeral 104 denotes a first guest OS that provides an execution environment for the application 101 in a virus detection target computer.
Reference numeral 105 denotes a second guest OS that provides an execution environment of the virus detection unit 103.
Reference numeral 106 denotes a virtual machine monitor (VMM) that operates the first and second guest OSs separately from each other, and is software necessary for operating a plurality of OSs on one PC hardware. This VMM 106 constitutes a virtualization means for controlling access to the memory and disk of each guest OS 104, 105 and preventing conflicts.
Reference numeral 107 denotes hardware of a computer to be searched for viruses. On this hardware 107, the VMM 106, the guest OS 104, and the guest OS 105 operate.
Reference numeral 108 denotes a signature database including virus patterns used by the virus detection means 103. The entity is a part of a hard disk attached to the hardware 107.
Reference numeral 109 denotes a search target process management block accessed by the virus detection means 103, and is configured as shown in FIG.

Reference numeral 110 denotes a virtual memory corresponding to the physical memory used by the first guest OS 104. The entity is a part of the physical memory of the hardware 107. The physical memory address recognized by the first guest OS 104 is converted into the physical memory address of the hardware 107 by the VMM 106. The virus detection means 103 searches the virtual memory directly. The address used for this search is a physical address that can be seen from the first guest OS 104, and is converted into a physical memory address of the hardware 107 by the VMM 106.
Reference numeral 111 denotes a virtual disk corresponding to the hard disk used by the first guest OS 104. The entity is a file on the hard disk of the hardware 107. The sector of the disk recognized by the first guest OS 104 is converted into a sector or block of a file by the VMM 106. The virus detection means 103 directly searches the virtual disk.
A management server 113 updates a virus pattern used by the virus detection unit 103 and receives a report of a virus detection result.

FIG. 2 is a diagram illustrating a configuration example of a process management block managed by the first guest OS 104.
In FIG. 2, reference numeral 201 denotes a global variable that stores a point to a management block at a fixed address on the physical memory. By tracing from this pointer, information of processes running on the first guest OS 104 can be obtained.
211 to 216 are one process management block. The actual process management block contains more information, but more information is omitted because it is not related to the present invention.
Reference numeral 211 denotes a process ID which is a part of the process management block.
A parent process ID 212, which is a part of the process management block, indicates the ID of the process that generated this process.
Reference numeral 213 denotes a pointer to the next process management block. By following this pointer one after another, all process management blocks can be accessed.
214 includes information on the virtual memory used by this process. Actually, it includes information such as a pointer to the Page Directory (PD) 302 and a memory size.
Reference numeral 215 denotes an access token indicating the authority when this process accesses a resource. When this process accesses a resource such as a file, the first guest OS 104 refers to this access token to the resource. Determine whether access is allowed or prohibited.
Reference numeral 216 denotes a handle table held by this process. The handle is an identifier for identifying the file or communication path that is being accessed by the process.

FIG. 3 illustrates virtual memory for one process.
In FIG. 3, 301 indicates the memory management 214 of the process management block shown in FIG. 2, and includes the physical address of the PD 302. Since the virtual memory exists for each process, information serving as a base point of the virtual memory is included in the memory management 214.
Reference numeral 302 denotes a PD (Page Directory), which is an array including a pointer to the Page Table (PT) 304. The index of this array is in the Page Directory Index (PDI) 311 which is a part of the virtual address.
303 is an element of the PD 302 and includes the physical address of the PT 304.
Reference numeral 304 denotes a PT (Page Table), which is an array including a physical address that is a pointer to a page on the physical memory. The index of this array is in Page Table Index (PTI) 312 which is a part of the virtual address.
305 is an element of the PT 304 and includes the address of a page on the physical memory.
Reference numeral 306 denotes a page on the physical memory. The index in this page is in Byte Index (BI) 313 which is a part of the virtual address.

Here, the conversion from the virtual memory address, which is a combination of the PDI 311, the PTI 312, and the BI 313, to the physical memory address is performed as follows.
First, the physical address of the PD is specified from the memory management 214, and the physical address of the PT 304 is specified from the PDI 311.
Next, the page 306 in the physical memory is specified from the PTI 312 and the physical address is obtained from the BI 311. Even if it is not the first guest OS 104, if the memory management 214 and the virtual address are known, the physical address on the first guest OS 104 can be specified from the second guest OS 105 through the VMM 106, and the physical memory can be accessed. In a normal VMM, a virtual memory and a virtual disk are managed for each guest OS, and the virtual memory of another guest OS cannot be accessed.

  In the above description, it is assumed that the page 306 of the physical memory indicated by the PT 304 is on the physical memory. However, if the virtual memory cannot be stored in the physical memory, a page fault process is required. . That is, the page on the physical memory that has been paged out is searched from the virtual disk 111 and the corresponding page on the virtual disk is accessed. In normal page fault processing, page data on the disk is copied onto the physical memory, but is not copied because another guest OS 105 originally accesses the physical memory of the guest OS 104.

FIG. 4 is a diagram illustrating a configuration example of the search target process management block 109 used by the virus detection unit 103.
In FIG. 4, 401 indicates the process ID of the process being searched, and corresponds to the process ID 211 of the process management block 109.
Reference numeral 402 denotes the physical address of the process management block being searched.
Reference numeral 403 denotes a virtual address to be started when searching for virtual memory.
Reference numeral 404 denotes a flag indicating that the search for the process has ended.
Hereinafter, a virus detection method included in the virtual memory 110 and the virtual disk 111, a virus detection method included in the file, and a virus detection method that hides the process will be described with reference to flowcharts. These can detect rootkits alone or in combination of these three.

FIG. 5 is a flowchart showing a virus detection procedure in the virtual memory in the guest OS 104 by the virus detection unit 103.
A virtual memory exists for each process, and when the process ends, the corresponding virtual memory disappears. Since the end of the process in the first guest OS 104 cannot be detected in the second guest OS 105 in which the virus detection means 103 operates, the virus detection means independently determines the end of the process and searches for the virus of the ended process. There is a need to. For this purpose, the search target process management block 109 shown in FIG. 4 is used.
First, in step 510, if the end flag 404 in the search target process management block 109 indicates end, the process management table shown in FIG. 2 managed by the first guest OS 104 is traced to set the next process. . If the end is not indicated, the process proceeds to step 520 as it is.
As a method of tracing, the process management block at the process management block address 402 in the virtual memory 110 is accessed, and it is confirmed that the process ID 211 of the block matches the process ID 401 of the search target process management block. The next process management block indicated by the process link 213 is accessed, the process ID 211 of the block is copied to the process ID 401 of the search target process management block, the address corresponding to the process link 213 is set to the process management block address 402, and the next scan The address 403 is set to the head address of the text area, and the end flag 404 is set to NO. The text area is an area in which so-called execution code is placed instead of data.

Next, in step 520, the signature 108 is checked whether a virus code is included from the virtual address at the next scan address 403. The method of accessing the physical memory from the virtual address has been described with reference to FIG.
Next, in step 530, if there is a code pattern that matches the signature 108, the management server 113 is notified.
Next, in step 540, when a text area of a certain size is scanned, the address of the virtual memory to be scanned next is stored in the next scan address 403. After scanning to the end, set the end flag to YES.
Next, the processing returns to step 510 and the processing of FIG. 5 is continued.

FIG. 6 is a flowchart showing a procedure for detecting hidden files in the virtual disk in the first guest OS 104 by the virus detection means 103.
First, in step 610, the virus detection means 103 inquires of the monitoring agent 102 on the first guest OS 104 about a list of files accessible from the application. Normally, the VMM 106 uses TCP / IP communication between guest OSes, and this is used.
Next, in step 620, the monitoring agent 102 sends the file list back to the virus detection means 103. The method of creating the list is not particularly important. Created using a normally available OS interface.

Next, in step 630, the virus detection means 103 receives the previous response. Further, the virtual disk 111 is searched to generate a file list on the virtual disk 111. The entity of the virtual disk 111 is a file. However, when viewed as a file system, there is no difference between a disk and a file, so that a file list can be created by regarding a normal disk sector as a file sector (block).
Next, in step 640, the two file lists are compared, and if there is a file that cannot be seen from the monitoring agent 102, it is assumed that there is a file hidden by the rootkit virus, and the management server 113 is notified.
Here, the file lists are compared all at once, but the upper limit of the number of files at the time of creating the file list may be determined by dividing the file list.

FIG. 7 is a flowchart showing a hidden process detection procedure in the first guest OS 104 by the virus detection means 103.
First, in step 710, the virus detection unit 103 inquires of the monitoring agent 102 on the first guest OS 104 about a process list that can be seen from the application.
In step 720, the monitoring agent 103 sends the process list back to the virus detection unit 103. The method of creating the list is not particularly important. Created using a normally available OS interface.
In step 730, the virus detection means 103 receives the previous response. Further, a process list is created by tracing the process management block 109 of the first guest OS 104 shown in FIG.

  In subsequent step 740, the two process lists are compared, and if there is a process that cannot be seen by the monitoring agent, it is assumed that there is a process hidden by the rootkit virus, and the management server 113 is notified.

(Second Embodiment)
In the above-described embodiment, the hidden process detection method has been described. However, it is also possible to detect a hidden thread by a similar method. The process can be traced from the process block pointer, but the thread is managed in the form of a link in the same manner as in FIG. 2 according to the state and priority. The state includes a state such as ready and standby, and there are 32 levels of priority, for example. By tracing the thread management block with a combination of state and priority, all threads can be obtained, and hidden threads can be searched for as well as processes.
Since the corresponding process ID is included in the thread management block, it is found from the thread even if there is a process that has been missed in the previous form by comparing with the process list obtained in FIG. You can also

(Third embodiment)
In the above-described embodiment, the virus detection unit 103 on the second guest OS 105 other than the first guest OS 104 is the main subject of detection. However, the virtual memory 110 and the virtual disk 111 are separate from the first OS 104. As long as it is a main body that can access the network, a configuration in which the VMM 106 is a main body for virus search may be used.

It is a system configuration figure showing an embodiment of the invention. It is a figure which shows the structural example of the process management block in FIG. It is a figure which shows the structural example of the virtual memory in FIG. It is a figure which shows the example of a process management block structure. It is a flowchart which shows the virus search procedure on a virtual memory. It is a flowchart which shows the search procedure of the hidden file on the disk concealed with the virus. It is a flowchart which shows the search procedure of the hidden process on the disk concealed with the virus.

Explanation of symbols

101: General application 102: Monitoring agent 103: Virus detection means 104: First guest OS
105: Second guest OS
106: VMM (virtualization means) in which the first and second guest OSs run
107: Hardware on which the first and second guest OSs and VMM operate 108: Virus signature database 109: Search target process management block 110: Virtual memory 111: Virtual disk 112: Network 113: Management server 201: Process block Pointer 211: Process ID
212: Parent process ID
213: Process link 214 pointing to the next process management block: Memory management including virtual memory information 215: Access token 216: Handle table 311: Page Directory Index in virtual memory address
312: Page Table Index in the virtual memory address
313: Byte Index in virtual memory address
401: Process ID
402: Process management block address 403: Next scan address 404: End flag

Claims (7)

The computer virus detection target computer includes a virtualization unit that operates the first guest OS that provides the execution environment of the application and the second guest OS that provides the execution environment of the virus detection unit separately from each other. ,
The virus detecting means is
A computer virus detection system comprising: first means for directly accessing virtual storage means used by the application and the first guest OS and detecting whether a computer virus exists in the virtual storage means.   The first means detects a computer virus by comparing a process list traced from a process management block pointer in the virtual storage means with a process list obtained from an interface provided by the first guest OS. The computer virus detection system according to claim 1, further comprising:   The first means compares the list of threads traced from the state of the virtual storage means and the thread management block pointer by priority with the list of threads obtained from the interface provided by the first guest OS, thereby generating a computer virus. The computer virus detection system according to claim 1, further comprising means for detecting   The first means determines whether or not the corresponding process of the thread traced from the thread management block pointer according to the status and priority of the virtual storage means is a process traced from the process management block pointer of the virtual storage means. The computer virus detection system according to claim 1, further comprising means for detecting a computer virus.   The first means includes means for specifying a physical memory address using a virtual address and a physical address conversion table traced from the process management block of the first guest OS and detecting a computer virus in the physical memory. The computer virus detection system according to claim 1.   The first means detects a computer virus by comparing a list of files accessible from the first guest OS and a file list obtained from virtual storage means used by the first guest OS. The computer virus detection system according to claim 1, further comprising means.   The computer virus detection system according to claim 1, wherein a virtual machine constructed by the virtualization unit detects a computer virus instead of the virus detection unit.

Images