(19)
(11)EP 2 653 994 B1

(12)EUROPEAN PATENT SPECIFICATION

(45)Mention of the grant of the patent:
30.09.2020 Bulletin 2020/40

(21)Application number: 13163780.3

(22)Date of filing:  15.04.2013
(51)International Patent Classification (IPC): 
G06F 21/52(2013.01)
G06F 12/14(2006.01)
G06F 21/56(2013.01)
G06F 9/445(2018.01)

(54)

Information security techniques including detection, interdiction and/or mitigation of memory injection attacks

Informationssicherheitstechniken, umfassend Detektion, Verbot und/oder Reduzierung von Speicherinjektionsangriffen

Techniques de sécurité d'informations comprenant la détection, l'interdiction et/ou l'atténuation d'attaques par injection de mémoire


(84)Designated Contracting States:
AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

(30)Priority: 17.04.2012 US 201261625544 P
17.04.2012 US 201261625541 P
15.03.2013 US 201313841245

(43)Date of publication of application:
23.10.2013 Bulletin 2013/43

(73)Proprietor: Ivanti, Inc.
South Jordan, UT 84095 (US)

(72)Inventor:
  • Teal, David M.
    Austin, TX 78730 (US)

(74)Representative: Hoarton, Lloyd Douglas Charles et al
Forresters IP LLP Skygarden Erika-Mann-Strasse 11
80636 München
80636 München (DE)


(56)References cited: : 
EP-A1- 2 065 825
  
  • Michael Hale Ligh: "Locating Hidden Clampi DLLs (VAD-style)", , 11 February 2008 (2008-02-11), XP055210493, Retrieved from the Internet: URL:http://mnin.blogspot.de/2008/11/locati ng-hidden-clampi-dlls-vad-style.html [retrieved on 2015-09-01]
  • Anonymous: "Find Injected DLLs In A Process?", , 6 February 2010 (2010-02-06), XP055210360, Retrieved from the Internet: URL:http://cboard.cprogramming.com/windows -programming/110979-find-injected-dlls-pro cess-printable-thread.html?pp=80 [retrieved on 2015-08-31]
  • Aaron Walters: "FATKit: Detecting Malicious Library Injection and Upping the "Anti"", , 31 July 2006 (2006-07-31), XP055210619, Retrieved from the Internet: URL:http://4tphi.net/fatkit/papers/fatkit_ dll_rc3.pdf [retrieved on 2015-09-01]
  • Anonymous: "Locating Hidden Clampi DLLs (VAD-style) second figure suspicious.png (image)", , 2 November 2008 (2008-11-02), XP055345817, Retrieved from the Internet: URL:http://3.bp.blogspot.com/_jAVGHwajDek/ SQ4NsnswlmI/AAAAAAAABFg/s9IzLA8dmDY/s1600- h/suspicious.png [retrieved on 2017-02-14]
  • Anonymous: "Locating Hidden Clampi DLLs (VAD-style) third figure", , 2 November 2008 (2008-11-02), XP055345819, Retrieved from the Internet: URL:http://1.bp.blogspot.com/_jAVGHwajDek/ SQ4WaVNjsWI/AAAAAAAABFw/I5MIkFGDEx4/s1600- h/winsock.png [retrieved on 2017-02-14]
  
Note: Within nine months from the publication of the mention of the grant of the European patent, any person may give notice to the European Patent Office of opposition to the European patent granted. Notice of opposition shall be filed in a written reasoned statement. It shall not be deemed to have been filed until the opposition fee has been paid. (Art. 99(1) European Patent Convention).


Description

CROSS-REFERENCE TO RELATED APPLICATION



[0001] This patent application claims priority to U.S. Provisional Patent Application No. 61/625,544, entitled "INFORMATION SECURITY TECHNIQUES INCLUDING LIBRARY INDICATIVE INFORMATION ENCODING CHECK FOR DETECTION, INTERDICTION AND/OR MITIGATION OF MEMORY INJECTION ATTACKS", filed April 17, 2012, and U.S. Provisional Patent Application No. 61/625,541, entitled "INFORMATION SECURITY TECHNIQUES INCLUDING VALID MAPPING CHECKS FOR DETECTION, INTERDICTION AND/OR MITIGATION OF MEMORY INJECTION ATIACKS" filed April 17, 2012.

BACKGROUND



[0002] Modern information systems (including desktop and portable computers, servers, mobile devices and even media devices and information appliances) often exhibit vulnerabilities to attacks that seek to exploit a flaw or weakness in the system's design, implementation, or operation and management. Many conventional security solutions employ one of two foundational techniques: blacklisting and whitelisting.

[0003] A conventional method for locating hidden DLLs is described in Michael Hale Ligh "Locating Hidden Claimpi DLLS (VAD-style)", 11 February 2008 (2008-02-11), EP055210493, retrieved from the internet: URL:http://mnin.blogspot.de/2008/11/locating-hidden-clampi-dlls-vad-style.html [retrived on 2015-09-01]

[0004] The internet blog "Find Injected DLLs In A Process?", which show entries until the 6 February 2010 (2010-02-06), XP055210360, Retrieved from the Internet:URL:http://cboard.cprogramming.com/ windows-programming/110979-find-injected-dlls-process-printable-thread.html?pp=80 [retrieved on 2015-08-31] is a discussion between several users on the most efficient way and the time point at which such a memory DLL extracting method should be conducted. Source code of the cloakedDLL program is also disclosed.

SUMMARY OF THE DISCLOSURE



[0005] Broadly, the present disclosure relates to information processing system security, and more specifically, to computer implemented security techniques that may be employed to detect, interdict and/or mitigate certain classes of malware including memory injections.

[0006] According to one aspect of the present invention, there provided a method as defined in claim 1 hereinafter.

[0007] According a further aspect of the present invention, there is provided a system as defined in claim 10 hereinafter.

[0008] In one aspect, a method for detecting memory injections includes enumerating, based on a query of an operating executive of a computer system, a plurality of memory regions of an address space in memory of the computer system, thereby creating memory region address information. The method further includes scanning memory of the computer system for a memory injection in response to a start of socket operation trigger. The scanning step may comprise determining whether a first memory region of the plurality of memory regions corresponds to any of a plurality of loaded modules registered with the operating executive; wherein, when the first memory region does not correspond to any of the plurality of loaded modules, determining whether the first memory region contains library indicative coding; and wherein, when the first memory region contains library indicative coding, generating a first memory injection alarm. The step of determining whether the first memory region corresponds to any of the loaded modules may include one or both of: examining the plurality of loaded modules for loaded module address information; and comparing the memory region address information associated with the first memory region to the loaded module address information. The comparing and the determining steps may be performed in kernel code.

[0009] In one embodiment, when the first memory region corresponds to one of the plurality of loaded modules, the method for detecting memory injection may include determining whether that loaded module is mapped from a file system of the computer system. In other embodiments, when the loaded module is not mapped from a file system of the computer system, the method may include determining whether the first memory region contains library indicative coding and/or generating a second memory injection alarm.

[0010] In one embodiment, the first memory injection alarm may be indicative of a Reflective DLL memory injection and/or the second memory injection alarm may be indicative of a Skape/JT memory injection.

[0011] In one embodiment, a method for detecting memory injections includes enumerating, based on a query of an operating executive of the computer system, a plurality of memory regions of an address space in memory of the computer system, thereby creating memory region address information. The method further includes scanning memory of the computer system for a memory injection. The scanning step may comprise determining whether a first memory region of the plurality of memory regions corresponds to any of a plurality of loaded modules registered with the operating executive; wherein, when the first memory region corresponds to one of the plurality of loaded modules, determining whether that loaded module is mapped from a file system of the computer system; and wherein, when the loaded module is not mapped from a file system of the computer system, generating a memory injection alarm. The step of determining whether the first memory region corresponds to any of the loaded modules may include one or both of: examining the plurality of loaded modules for loaded module address information; and comparing the memory region address information associated with the first memory region to the loaded module address information. The comparing and the determining steps may be performed in kernel code.

[0012] In one embodiment, the scanning step may include determining whether the first memory region is in use by checking whether the first memory is committed memory, and when the first memory region is in use, determining whether the first memory region corresponds to any of the plurality of loaded modules.

[0013] In one embodiment, the scanning step may include determining whether the first memory region is a read/write/executable memory region or was initially allocated as a read/write/executable memory region; and when the first memory region is a read/write/executable memory region or was initially allocated as a read/write/executable memory region, determining whether the first memory region contains library indicative coding.

[0014] In one embodiment, the enumerating step may include enumerating the plurality of loaded modules based on the query, thereby creating loaded module address information. For a WINDOWS operating system, enumerating the loaded modules may employ one or more of: the CreateToolhelp32Snapshot function to take a snapshot of all running processes and the modules used by the process; the EnumProcessModules function to obtain a handle to each module in a specified process, then the GetModuleInformation functions to obtain the name, size, and base address of a module; the NtQueryInformationProcess and NtReadVirtualMemory functions to query the virtual memory of a process; and the PsSetLoadImageNotifyRoutine function to register a callback function that will be called each time a module is loaded; among others.

[0015] In one embodiment, a loaded module may be compared to a first memory region to check for correspondence between the two by comparing loaded module address information to memory region address information. When the addresses of a loaded module span the addresses of the first memory region, or partially overlap the addresses of the first memory region, then the module corresponds to the first memory region. Conversely, when the addresses of a module lie completely outside of the addresses of the first memory region, then the module does not correspond to the first memory region. The comparing step may be performed at successive times during operation of the computer system. In one embodiment, the comparing is substantially limited to those address space regions having a current, or as-allocated, executable type protection attribute.

[0016] In one embodiment, the operating executive may include at least one of an operating system and a virtualization system or hypervisor.

[0017] In one embodiment, process handles for each process executing on the computational system may be obtained. The process handles may be used to query the operating executive to obtain memory region address information for successive memory regions within the address space associated with a process.

[0018] In one embodiment, the process handles may be obtained from a shadow process table, wherein entries in the shadow process table are populated in response to the start of new processes or threads. In other embodiments, the process handles may be obtained from a process table maintained by the operating executive.

[0019] In one embodiment, the operating executive may be queried to obtain an identifier of a file system object from which the contents of a memory region are mapped.

[0020] In one embodiment, the query of the operating executive may comprise walking a call stack. For example, walking a call stack may include using stack commands to view functions currently on the call stack, which represent currently active routines. Thus, navigation of live process may be facilitated by moving from the current frame toward the stop location at the "bottom" of the stack, and vice versa.

[0021] Similarly, systems for detection of memory injections are disclosed. In one embodiment, a system for detection of memory injections includes computer executable code, wherein the code includes instructions for enumerating, based on a query of an operating executive of a computer system, a plurality of memory regions of an address space, thereby creating memory region address information. The instructions further include scanning memory of the computer system for a memory injection. The scanning step may comprise determining whether a first memory region of the plurality of memory regions corresponds to any of a plurality of loaded modules registered with the operating executive; wherein, when the first memory region does not correspond to any of the plurality of loaded modules, determining whether the first memory region contains library indicative coding; and wherein, when the first memory region contains library indicative coding, generating a first memory injection alarm. The step of determining whether the first memory region corresponds to any of the loaded modules may include one or both of: examining the plurality of loaded modules for loaded module address information; and comparing the memory region address information associated with the first memory region to the loaded module address information.

[0022] In one embodiment, a system for detection of memory injections includes computer executable code, wherein the code includes instructions for enumerating, based on a query of an operating executive of the computer system, a plurality of memory regions of an address space allocated to processes executing on the computer system, thereby creating memory region address information. The instructions further include scanning memory of the computer system for a memory injection. The scanning step may comprise determining whether a first memory region of the plurality of memory regions corresponds to any of a plurality of loaded modules registered with the operating executive; wherein, when the first memory region corresponds to one of the plurality of loaded modules, determining whether that loaded module is mapped from a file system of the computer system; and wherein, when the loaded module is not mapped from a file system of the computer system, generating a memory injection alarm. The step of determining whether the first memory region corresponds to any of the loaded modules may include one or both of: examining the plurality of loaded modules for loaded module address information; and comparing the memory region address information associated with the first memory region to the loaded module address information. The system may be modified to perform any of the processes above.

[0023] These and other aspects and advantages, and novel features of this new technology are set forth in part in the description that follows and will become apparent to those skilled in the art upon examination of the following description and figures, or may be learned by practicing one or more embodiments of the technology provided for by the present disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS



[0024] 

FIG. 1 is a schematic illustration of an exploitation of a PDF reader application vulnerability resulting in a memory injection onto the memory of a computer.

FIG. 2 is a schematic illustration of an exploitation of a generalized application vulnerability resulting in a memory injection onto the memory of a computer.

FIGS. 3a-3c are illustrations of a process flow of methods useful for memory injection detection.

FIG. 4 is an illustration of a process flow of other methods useful for memory injection detection.

FIG. 5a is a schematic view of one embodiment of a process tracking table, including the propagation of whitelist trust attributes along a code trajectory and the enumeration of memory regions and loaded modules in accordance with some embodiments of memory injection detection.

FIG. 5b is a schematic view of a security infrastructure for implementing one embodiment of the whitelist trust attributes as shown in FIG. 5a.

FIG. 5c is a schematic view of a security infrastructure for implementing another embodiment of the whitelist trust attributes as shown in FIG. 5a.

FIG. 6 is an illustration of a three-tiered console/manager/client architecture provided in some implementations of some security solutions in accordance with the present disclosure.

FIGS. 7a-7d are illustrations of various computer components associated with memory injection detection.


DETAILED DESCRIPTION



[0025] Reference will now be made in detail to the accompanying drawings, which at least assist in illustrating various pertinent embodiments of the new technology provided for by the present disclosure.

[0026] FIG. 1 illustrates steps in a simplified illustration of exploitation of an application vulnerability that results in malware being introduced to storage and potentially executed on a target computer. In the illustration, the vulnerable application is a portable document format (PDF) reader application 111. The PDF reader application 111 executes on a computer 110 having file storage 140 (e.g., a hard disk drive) and memory 150 (e.g., Random Access Memory or "RAM"). The PDF reader application 111 loads PDF content 121 from a web server 120 (or from some other source). Although it is typically unrecognized by the user, PDF content 121 may include an exploit (e.g., code, data or other information) that exploits vulnerability in PDF reader application 111 to perform actions that further the malware's objective. In the illustration of FIG. 1, a vulnerability in PDF reader application 111 allows the exploit to open an ftp connection to server 130 that acts as a source of malicious code 131. In general, server 130 may be a repository specifically provided to host the malicious code or may be some other computer that has been previously compromised and acts as a transmission vector. An advantage of strategies such as illustrated in FIG. 1, at least from the malware's perspective, is that there are numerous avenues to introduce the malicious code into storage accessible to the target (here, computer 110). In general, the software is easy to write and directly accomplishes the hacker's objective. As a practical matter, the hacker can often place the malicious code in, and subsequently execute from, any of a variety of storage accessible to the computer 110.

[0027] Turning now to FIG. 2, a more general exploitation of an application vulnerability is illustrated. In the illustration, the vulnerable application is a web content reader application 211. In the illustration, reader application 211 executes on computer 110 and, at some point loads exploited web content 221 from a web server 220 (or from some other source). Although it is typically unrecognized by the user of computer 110, web content 221 may include an exploit (e.g., code, data or other information) that exploits vulnerability in reader application 211 to perform actions that further the malware's objective. In the illustration of FIG. 2, a vulnerability in reader application 211 allows the exploit to open an ftp connection to malicious server 230 that acts as a source of malicious code 231. In general, malicious server 230 may be a repository specifically provided to host the malicious code or may be some other computer that has been previously compromised and acts as a transmission vector. An advantage of strategies such as illustrated in FIG. 2, at least from the malware's perspective, is that there are numerous avenues to introduce the malicious code into storage accessible to the target (here, computer 110). In general, the software is easy to write and directly accomplishes the hacker's objective. As a practical matter, the hacker can often place the malicious code in, and subsequently execute from, any of a variety of storage accessible to the computer 110. Persons of ordinary skill in the art will appreciate the simplified, though nonetheless illustrative, depictions of FIGS. 1 and 2 as representative of a wide range of memory injection type exploits, such as (for example and without limitation) those reflective DLL injection and Skape/JT type memory injection attacks (e.g., due to the memory injection techniques described by authors known by monikers Skape and JT (see Skape and JT, Remote Library Injection, 2004), and those described by Fewer (see Fewer, Reflective DLL Injection, 2008)) referenced herein. As used herein, "memory injection" means unauthorized and/or malicious executable code that has been inserted into the address space of one or more processes executing on a computer system. Examples of memory injection techniques include, among others.

[0028] Turning now to FIGS. 3a-c, one embodiment of a computer program for detection of memory injection attacks is illustrated. In the illustrated embodiment, one or more trigger(s) 320 trigger the computer program to query 322 an operating executive 599. Triggers 320 may include the start of a new process or thread, the start of a socket operation, the writing of information to the file system, and/or the expiration of a polling timer, among others. In response to the query 322, the operating executive 599 enumerates 326, 324 loaded modules 170 (see FIG. 7b) and memory regions 160 (see FIG. 7c), thereby populating entries in one or more process tracking table(s) 301. Enumerating the loaded modules 170 may include populating entries in the process tracking table 301. These entries may include loaded module address information such as the start address, end address, and/or size of each loaded module 170 in the address space of memory 150, among others. Similarly, enumerating the memory regions 160 may include populating entries in the process tracking table 301. These entries may include memory region address information such as the start address, end address, and/or size of each memory region in the address space of memory 150. Because the information related to the memory regions 160 is derived from the operating executive kernel, this information may be less susceptible to malicious altering than information derived from the user space. Thus, the entries related to the memory regions 160 in the process tracking table 301 may provide a basis of comparison to facilitate detection of memory injection attacks.

[0029] The computer program, in process block 328, selects a first memory region from the process tracking table 301. The computer program then determines, in decision block 330, whether a module listed in the process tracking table 301 corresponds to the first memory region. In the illustrated embodiment, the start and end addresses of each listed module may be compared to the start and end addresses of the first memory region to determine if a module corresponds to the first memory region. If a module spans the first memory region, or partially overlaps the first memory region, then the module corresponds to the first memory region. Conversely, if a module lies completely outside of the first memory region, then the module does not correspond to the first memory region. If a module listed in the process tracking table 301 corresponds to the first memory region, then the computer program checks, in decision block 336, whether that corresponding module is mapped to the file system 110. If the corresponding module is not mapped from the file system 110, then the computer program generates a Skape/JT injection detection alarm 335. If, on the other hand, the corresponding module is mapped from the file system 110, then the computer program continues to decision block 340.

[0030] Returning now to decision block 330, if none of the modules listed in the process tracking table 301 correspond to the first memory region, then the computer program continues to decision block 338. In decision block 338 the computer program determines whether the first memory region contains library indicative coding (e.g., an executable). If the first memory region contains library indicative coding, then the computer program generates a Reflective DLL injection detection alarm 337. If, on the other hand, the first memory region does not contain library indicative coding, then the computer program continues to decision block 340.

[0031] In decision block 340, the computer program determines whether all the memory regions 160 listed in the process tracking table 301 have been analyzed. If there is at least one memory region listed in the process tracking table 301 that has not yet been analyzed, then the computer program selects the next memory region to be analyzed, restarting at process block 328. If all of the memory regions 160 listed in the process tracking table 301 have been analyzed, the process is complete (as represented by block 341).

[0032] Turning now to FIG. 4, another embodiment of a computer program for detection of memory injection attacks is illustrated. In the illustrated embodiment of FIG. 4, as described above with respect to FIGS. 3a-c, one or more trigger(s) 320 trigger the computer program to query 322 an operating executive 599. In response to the query 322, the operating executive 599 enumerates 324 memory regions 160, thereby populating entries in one or more process tracking table(s) 401. Enumerating the memory regions 160 may include populating entries in the process tracking table 401 that indicate the start address, end address, and/or size of each memory region in the address space of memory 150.

[0033] The computer program, in process block 428, selects a first memory region from the process tracking table 401. The computer program then determines, in decision block 450, whether the first memory region is in use by checking whether the first memory region is committed memory. If the first memory region is not committed memory, then it is not in use, and the computer program proceeds to decision block 440. Conversely, if the first memory region is committed memory, then the computer program determines, in decision block 430, whether the first memory region corresponds to a module that is mapped from the file system 140.

[0034] If the first memory region corresponds to a module that is mapped from the file system 140, then the computer program proceeds to decision block 440. If, on the other hand, the first memory region does not correspond to any module that is mapped from the file system 140, then the computer program determines, in decision block 460, whether the first memory region is a read/write/executable memory region or was initially allocated as a read/write/executable memory region. If the first memory region is not a read/write/executable memory region, then program proceeds to decision block 440. Conversely, if the first memory region is a read/write/executable memory region, then the computer program determines, in decision block 438, whether the first memory region contains library indicative coding.

[0035] If the first memory region contains library indicative coding, then the computer program generates a DLL injection detection alarm 470. Conversely, if the first memory region does not contain library indicative coding, then the computer program determines, in block 440, whether all the memory regions 160 listed in the process tracking table 401 have been analyzed. If there is at least one memory region listed in the process tracking table 401 that has not yet been analyzed, then the computer program selects the next memory region to be analyzed, restarting at process block 428. If all of the memory regions 160 listed in the process tracking table 401 have been analyzed, the process is complete (as represented by block 441).

[0036] Turning now to FIGS. 5a-c, another embodiment of a computer program for detection of memory injection attacks is illustrated. More specifically, FIG. 5a illustrates introduction of memory allocation and loaded module information retrieved from an operating executive 599 (e.g., from an operating executive, virtualization system, hypervisor or some combination thereof) for use in a comprehensive process tracking table 501 that facilitates memory injection attack detection, interdiction and/or mitigation solutions as well as application whitelist execution controls. Note that while whitelisting security solutions provide a useful descriptive and illustrative context for some embodiments, other embodiments in accordance with the present disclosure need not implement whitelisting solutions.

[0037] Using techniques illustrated in FIG. 5a, whitelisting security infrastructures in accordance with some embodiments of the present disclosure effectively cache whitelist information and protection attributes in association with a runtime set of identifiers (e.g., name/pathname, handle, dll and/or thread identifiers) associated with the code image 571 for which execution is initially attempted (201). In particular, entry 406 of whitelist 405 corresponds to execution (attempted at 201) of an image identified using file/pathname name (with confirmed hash and size attributes). The security infrastructure then leverages those identifiers to recognize the association of pertinent interposed-upon system calls with code image 571 and to propagate protection attributes cached for code image 571 to additional processes invoked 502, 503 along code trajectory 551. By accumulating the relevant identifiers and storing whitelist-sourced trust objects 512 in association therewith, process tracking tables 501 provide a useful kernel-resident data structure (that is not exposed to user code access) against which the whitelisting security infrastructure may efficiently check for protection attributes.

[0038] An initial succession 582, 583 of interposed-upon call flows 453 are illustrated in correspondence with attempts to execute further images 572, 573 along code trajectory 551 (via call/spawn/fork/exec 502, 503). Capture and recording of the dynamically created handles (e.g., FH1 and SH2) allows interposition mechanisms 580 of the whitelisting security infrastructure to associate the interposed-upon system calls with execution of code image 571 and to propagate protection attributes encoded in trust objects 512 to trust objects 522 maintained in association with handles, dlls and thread identifiers used by the operating system to identify a new process P2 (and its associated dlls and threads) that execute code image 572.

[0039] Likewise, in an execution sequence of code image 572 that seeks to initiate yet another process by (i) opening a file containing yet another code image 573, (ii) mapping the code image to memory and (iii) creating the new process P3, the capture and recording of runtime identifiers (e.g., file handles, section handles and/or other identifiers) associated with execution of code image 572 allows interposition mechanisms 580 of the whitelisting security infrastructure to recognize the system calls that constitute call/spawn/fork/exec 503 and to appropriately propagate whitelist-sourced protection attributes to the resulting process P3, its threads and dlls. For example, in the illustration of FIG. 6, an interposed upon 583 system call (e.g., an NTCreateProcess system call) is matched with trust objects 522 based on an identifier (e.g., section handle SH3) captured and tracked in the course of process P2. Based on that match contents of trust object(s) 522 are further propagated to process tracking table entries for process P3. For example a trust-changes type trust object associated with process P2 may allow the whitelist to be extended to include a trust-execute type trust object to be associated with process P3. The process tracking table(s) 501 associated with the above described whitelisting security infrastructure may also facilitate detection of memory injection attacks. Specifically, the process tracking table 501 may facilitate enumeration and/or analysis of memory regions 160, as described above with respect to FIGS. 3a-c and FIG. 4.

[0040] In the illustrated embodiment of FIG. 5a, process tracking tables 501 are maintained separately from (though generally in correspondence with) process tables maintained by an operating system, hypervisor or other execution environment. Interposition and process tracking tables 501 may operate by either hooking events in the operating system kernel without complicity or cooperation from the operating system, or by registering with the operating system to be notified when process are created, deleted, or modified. In other embodiments, state maintained in process tracking tables 501 (and indeed interpositioning) may be integrated with facilities of an operating system, hypervisor or execution environment. Indeed, in some embodiments, process tracking and/or interposition may be based on facilities or capabilities of a virtualization system.

[0041] FIG. 6 illustrates one embodiment of a three-tiered console/manager/client architecture to facilitate securing and managing individual computing platforms as part of an enterprise network. In one embodiment, the system includes a plurality of computing platforms, including end-user platforms (e.g., desktops, web servers, and/or Voice-Over-Internet Protocol (VOIP) servers), a manager appliance connected to the computing platforms, and a console appliance connected to the manager. In one embodiment, each computing platform has a respective security module (i.e., "client") residing therein that is in constant or almost constant communication, via a network, with the manager. The network may be any suitable network known to those having ordinary skill in the art, including wired and wireless networks. In the illustrated embodiment, the clients enforce the security policies (e.g., the memory injection detection and/or whitelist security policies disclosed herein) for the computing platforms while the manager monitors the operation of the clients and provides secure, centralized communication to the clients. In one embodiment, the console, which provides the only available access to the manager, allows an enterprise administrator to log on to the manager for purposes of monitoring the computing platforms and implementing policy changes (e.g. revised whitelists), software upgrades, security event reporting (e.g. memory injection alarms), and the like. In the illustrated embodiment, from the console, an administrator may view all information about the clients as well as issue commands to each client as needed.

[0042] Turning now to FIGS. 7a-d, various apparatuses associated with memory injection detection are illustrated. More specifically, FIG. 7a schematically illustrates one embodiment of the computer system 110 including the memory 150 and the file storage 140. As shown in FIG. 7b, the memory 150 may include loaded modules 170 and memory regions 160. A memory region 160 may comprise a number of discrete addresses in an address space of memory 150. As shown in FIG. 7c, for example, a memory region 160 may include any number of sequential addresses. Similarly, as shown in FIG. 7d, a loaded module 170 may comprise any number of discrete addresses in an address space of memory 150. As shown in FIG. 7d, for example, a loaded module 170 may include any number of sequential addresses. The addresses of a loaded module 170 may span the addresses of more than one memory region 160, and furthermore the addresses of a loaded module 170 may overlap the addresses of a memory region 160 (as shown in FIG. 7c).


Claims

1. A method comprising:

(a) enumerating (324, 326), based on a query (322) of an operating executive (599) of a computer system and sent in response to a trigger, a plurality of memory regions of an address space in memory of the computer system to define memory region address information, the memory region address information including a start address and an end address of each memory region from the plurality of memory regions in the address space, the trigger being the start of a socket operation; and

(b) scanning memory of the computer system for a memory injection, wherein the scanning step comprises:

(i) determining whether a first memory region from the plurality of memory regions corresponds to any loaded module from a plurality of loaded modules registered with the operating executive (599), wherein the determining step comprises:

(A) examining the plurality of loaded modules for loaded module address information including a start address and an end address of each loaded module from the plurality of loaded modules in the address space; and

(B) comparing (330) the memory region address information to the loaded module address information including comparing the start address and the end address of each loaded module from the plurality of loaded modules to the start address and the end address of the first memory region; and

(ii) wherein, when the first memory region does not correspond to any loaded module from the plurality of loaded modules, determining (338) whether the first memory region contains an executable, and , when the first memory region contains an executable, generating (337) a memory injection alarm.


 
2. The method of claim 1, wherein, when the first memory region corresponds to a loaded module from the plurality of loaded modules, determining (336) whether that loaded module is mapped from the file system of the computer system.
 
3. The method of claim 2, wherein, when the loaded module is not mapped from the file system of the computer system, determining whether the first memory region contains an executable.
 
4. The method of claim 2, wherein the memory injection alarm is a first memory injection alarm, and, when the loaded module is not mapped from the file system of the computer system, generating (335) a second memory injection alarm.
 
5. The method of any of the preceding claims, wherein the scanning step further comprises:

determining (450) whether the first memory region is in use by checking that it is committed memory; and

wherein, when the first memory region is in use, determining (430) whether the first memory region corresponds to any loaded module from the plurality of loaded modules.


 
6. The method of any of the preceding claims, wherein the scanning step further comprises:

determining (460) whether the first memory region is a read/write/executable memory region or was initially allocated as a read/write/executable memory region; and

wherein, when the first memory region is a read/write/executable memory region or was initially allocated as a read/write/executable memory region, determining (438) whether the first memory region contains an executable.


 
7. The method of any of the preceding claims, wherein the comparing step (330) is limited to address space regions having a trust-execute protection object.
 
8. The method of any of the preceding claims, further comprising:
enumerating (326), based on the query, the plurality of loaded modules to create the loaded module address information.
 
9. The method of claim 4, wherein the first memory region corresponds to a loaded module from the plurality of loaded modules when, based on the comparing step, that loaded module spans the first memory region, or partially overlaps the first memory region, and
the first memory region does not correspond to any loaded module from the plurality of loaded modules when, based on the comparing step, each loaded module from the plurality of loaded modules lies completely outside of the first memory region.
 
10. A system comprising:
instructions executable on a computer system, the instructions comprising:

(a) enumerating (324, 326), based on a query (322) of an operating executive (599) of a computer system sent in response to a trigger, a plurality of memory regions of an address space to define memory region address information, the memory region address information including a start address and an end address of each memory region from the plurality of memory regions in the address space, the trigger being the start of a socket operation; and

(b) scanning memory of the computer system for a memory injection, wherein the scanning step comprises:

(i) determining whether a first memory region from the plurality of memory regions corresponds to any loaded module from a plurality of loaded modules registered with the operating executive (599), wherein the determining step comprises:

(A) examining the plurality of loaded modules for loaded module address information including a start address and an end address of each loaded module from the plurality of loaded modules in the address space; and

(B) comparing (330) the memory region address information associated with the first memory region to the loaded module address information including comparing the start address and the end address in the address space of each loaded module from the plurality of modules to the start address and the end address of the first memory region; and

(ii) wherein, when the first memory region does not correspond to any loaded module from the plurality of loaded modules, determining (338) whether the first memory region contains an executable, and, when the first memory region contains an executable, generating (337) a memory injection alarm.


 
11. The system of claim 10, wherein the memory injection alarm is a first memory injection alarm, and the scanning step further comprises:
when the first memory region corresponds to a loaded module from the plurality of loaded modules, determining (336) whether that loaded module is mapped from the file system (140) of the computer system, and, when the loaded module is not mapped from the file system (140) of the computer system, generating (335) a second memory injection alarm.
 


Ansprüche

1. Verfahren, umfassend:

(a) Aufzählung (324, 326), die auf der Abfrage (322) einer Betriebsaufsicht (599) eines Computersystems basiert und als Reaktion auf einen Auslöser gesendet wird, einer Mehrzahl von Speicherbereichen eines Adressraums in dem Speicher des Computersystems, um Speicherbereichs-Adressinformationen zu definieren, wobei die Speicherbereichs-Adressinformationen eine Startadresse und eine Endadresse jedes Speicherbereichs aus der Mehrzahl von Speicherbereichen in dem Adressraum beinhalten, wobei der Auslöser der Start eines Socketvorgangs ist;

(b) Scannen des Speichers des Computersystems auf eine Speicherinjektion, wobei der Scan-Schritt umfasst:

(i) Bestimmen dessen, ob ein erster Speicherbereich aus der Mehrzahl von Speicherbereichen irgendeinem geladenen Modul aus einer Mehrzahl von geladenen Modulen, die bei der Betriebsaufsicht (599) registriert sind, entspricht, wobei der Bestimmungsschritt umfasst:

(A) Untersuchen der Mehrzahl von geladenen Modulen auf geladene Modul-Adressinformationen einschließlich einer Startadresse und einer Endadresse jedes geladenen Moduls aus der Mehrzahl von geladenen Modulen in dem Adressraum; und

(B) Vergleichen (330) der Speicherbereichs-Adressinformationen mit den geladenen Modul-Adressinformationen einschließlich Vergleichen der Startadresse und der Endadresse jedes geladenen Moduls aus der Mehrzahl von geladenen Modulen mit der Startadresse und der Endadresse des ersten Speicherbereichs; und

(ii) wobei, wenn der erste Speicherbereich keinem geladenen Modul aus der Mehrzahl von geladenen Modulen entspricht, Bestimmen (338) dessen, ob der erste Speicherbereich ein Executable enthält und, wenn der erste Speicherbereich ein Executable enthält, Generieren (337) eines Speicherinjektionsalarms.


 
2. Verfahren nach Anspruch 1, wobei, wenn der erste Speicherbereich einem geladenen Modul aus der Mehrzahl von geladenen Modulen entspricht, Bestimmen (336) dessen, ob jenes geladene Modul aus dem Dateisystem des Computersystems zugeordnet ist.
 
3. Verfahren nach Anspruch 2, wobei, wenn das geladene Modul nicht aus dem Dateisystem des Computersystems zugeordnet ist, Bestimmen dessen, ob der erste Speicherbereich ein Executable enthält.
 
4. Verfahren nach Anspruch 2, wobei der Speicherinjektionsalarm ein erster Speicherinjektionsalarm ist und, wenn das geladene Modul nicht aus dem Dateisystem des Computersystems zugeordnet ist, Generieren (335) eines zweiten Speicherinjektionsalarms.
 
5. Verfahren nach einem der vorhergehenden Ansprüche, wobei der Scan-Schritt ferner umfasst:

Bestimmen (450) dessen, ob der erste Speicherbereich in Gebrauch ist, indem geprüft wird, dass er zugesicherter Speicher ist; und

wobei, wenn der erste Speicherbereich in Gebrauch ist, Bestimmen (430) dessen, ob der erste Speicherbereich irgendeinem geladenen Modul aus der Mehrzahl von geladenen Modulen entspricht.


 
6. Verfahren nach einem der vorhergehenden Ansprüche, wobei der Scan-Schritt ferner umfasst:

Bestimmen (460) dessen, ob der erste Speicherbereich ein Lese-/Schreib-/Executable-Speicherbereich ist oder anfänglich als Lese-/Schreib-/Executable-Speicherbereich zugewiesen war; und

wobei, wenn der erste Speicherbereich ein Lese-/Schreib-/Executable-Speicherbereich ist oder anfänglich als Lese-/Schreib-/Executable-Speicherbereich zugewiesen war, Bestimmen (438) dessen, ob der erste Speicherbereich ein Executable enthält.


 
7. Verfahren nach einem der vorhergehenden Ansprüche, wobei der Vergleichsschritt (330) auf Adressraumbereiche mit einem "Trust-Execute"-Schutzobjekt begrenzt ist.
 
8. Verfahren nach einem der vorhergehenden Ansprüche, ferner umfassend:
Aufzählung (326), auf Basis der Abfrage, der Mehrzahl von geladenen Modulen, um die geladenen Modul-Adressinformationen zu erstellen.
 
9. Verfahren nach Anspruch 4, wobei der erste Speicherbereich einem geladenem Modul aus der Mehrzahl von geladenen Modulen entspricht, wenn, auf Basis des Vergleichsschritts, jenes geladene Modul den ersten Speicherbereich überspannt oder den ersten Speicherbereich teilweise überlappt, und
der erste Speicherbereich keinem geladenen Modul aus der Mehrzahl von geladenen Modulen entspricht, wenn, auf Basis des Vergleichsschritts, jedes geladene Modul aus der Mehrzahl von geladenen Modulen völlig außerhalb des ersten Speicherbereichs liegt.
 
10. System, umfassend:
Anweisungen, die auf einem Computersystem ausführbar sind, wobei die Anweisungen umfassen:

(a) Aufzählung (324, 326), die auf einer Abfrage (322) einer Betriebsaufsicht (599) eines Computersystems basiert, die als Reaktion auf einen Auslöser gesendet wird, einer Mehrzahl von Speicherbereichen eines Adressraums, um Speicherbereichs-Adressinformationen zu definieren, wobei die Speicherbereichs-Adressinformationen eine Startadresse und eine Endadresse jedes Speicherbereichs aus der Mehrzahl von Speicherbereichen in dem Adressraum beinhalten, wobei der Auslöser der Start eines Socketvorgangs ist;

(b) Scannen des Speichers des Computersystems auf eine Speicherinjektion, wobei der Scan-Schritt umfasst:

(i) Bestimmen dessen, ob ein erster Speicherbereich aus der Mehrzahl von Speicherbereichen irgendeinem geladenen Modul aus einer Mehrzahl von geladenen Modulen, die bei der Betriebsaufsicht (599) registriert sind, entspricht, wobei der Bestimmungsschritt umfasst:

(A) Untersuchen der Mehrzahl von geladenen Modulen auf geladene Modul-Adressinformationen einschließlich einer Startadresse und einer Endadresse jedes geladenen Moduls aus der Mehrzahl von geladenen Modulen in dem Adressraum; und

(B) Vergleichen (330) der Speicherbereichs-Adressinformationen, die mit dem ersten Speicherbereich assoziiert sind, mit den geladenen Modul-Adressinformationen einschließlich Vergleichen der Startadresse und der Endadresse in dem Adressraum jedes geladenen Moduls aus der Mehrzahl von geladenen Modulen mit der Startadresse und der Endadresse des ersten Speicherbereichs; und

(ii) wobei, wenn der erste Speicherbereich keinem geladenen Modul aus der Mehrzahl von geladenen Modulen entspricht, Bestimmen (338) dessen, ob der erste Speicherbereich ein Executable enthält und, wenn der erste Speicherbereich ein Executable enthält, Generieren (337) eines Speicherinjektionsalarms.


 
11. System nach Anspruch 10, wobei der Speicherinjektionsalarm ein erster Speicherinjektionsalarm ist und der Scan-Schritt ferner umfasst:
wenn der erste Speicherbereich einem geladenen Modul aus der Mehrzahl von geladenen Modulen entspricht, Bestimmen (336) dessen, ob jenes geladene Modul aus dem Dateisystem (140) des Computersystems zugeordnet ist und, wenn das geladene Modul nicht aus dem Dateisystem (140) des Computersystems zugeordnet ist, Generieren (335) eines zweiten Speicherinjektionsalarms.
 


Revendications

1. L'invention concerne un procédé comprenant :

(a) l'énumération (324, 326), sur la base d'une requête (322) d'un gestionnaire d'exploitation (599) d'un système informatique et envoyée en réponse à une sollicitation, d'une pluralité de régions de mémoire d'un espace d'adressage dans la mémoire du système informatique pour définir des informations d'adressage de région de mémoire, les informations de région de mémoire comprenant une adresse de début et une adresse de fin de chaque région de la pluralité de régions de mémoire dans l'espace d'adressage, la sollicitation étant le début d'une opération de prise ;

(b) le balayage de la mémoire du système informatique pour rechercher une injection de mémoire, dans laquelle l'étape de balayage comprend :

(i) la détermination d'une correspondance entre une première région de la pluralité de régions de mémoire et l'un quelconque d'une pluralité de modules chargés enregistrés avec le gestionnaire d'exploitation (599), l'étape de détermination comprenant :

(A) l'examen de la pluralité de modules chargés pour rechercher des informations d'adressage de module chargés comprenant une adresse de début et une adresse de fin de chacun des modules de la pluralité de modules chargés dans l'espace d'adressage ; et

(B) la comparaison (330) entre les informations d'adressage de la région de mémoire et les informations d'adressage de modules chargés comprenant la comparaison de l'adresse de début et de l'adresse de fin de chacun des modules de la pluralité de modules chargés avec l'adresse de début et l'adresse de fin de la première région de mémoire ; et

(ii) dans lequel, lorsque la première région de mémoire ne correspond à aucun des module de la pluralité de modules chargés, il est déterminé (338) si la première région de mémoire contient un exécutable, et, lorsque la première région de mémoire contient un exécutable, une alarme d'injection de mémoire est générée (337).


 
2. Procédé selon la revendication 1, dans lequel, lorsque la première région de mémoire correspond à l'un de la pluralité de modules chargés, il est déterminé (336) si ce module est mappé à partir du système de fichiers (140) du système informatique.
 
3. Procédé selon la revendication 2, dans lequel, lorsque le module chargé n'est pas mappé à partir d'un système de fichiers du système informatique, il est déterminé si la première région de mémoire contient un exécutable.
 
4. Procédé selon la revendication 2, dans lequel l'alarme d'injection de mémoire est une première alarme d'injection de mémoire, et, lorsque le module chargé n'est pas mappé à partir d'un système de fichiers du système informatique, une deuxième alarme d'injection de mémoire est générée (335).
 
5. Procédé selon l'une quelconque des revendications précédentes, dans lequel l'étape de balayage comprend en outre :

la détermination (450) de l'utilisation en cours de la première région de mémoire en vérifiant qu'elle est engagée ; et

dans lequel, lorsque la première région de mémoire est en cours d'utilisation, il est déterminé (430) si la première région de mémoire correspond à l'un quelconque de la pluralité de modules chargés.


 
6. Procédé selon l'une quelconque des revendications précédentes, dans lequel l'étape de balayage comprend en outre :

la détermination (460) du mode de la première région de mémoire, soit une région de mémoire lecture/écriture/exécutable, soit une région de mémoire initialement attribuée comme région de mémoire lecture/écriture/exécutable ; et

dans lequel, lorsque la première région de mémoire est une région de mémoire lecture/écriture/exécutable ou a été initialement attribuée en tant que région de mémoire lecture/écriture/exécutable, il est déterminé (438) si la première région de mémoire contient un exécutable.


 
7. La procédé selon l'une quelconque des revendications précédentes, dans lequel l'étape de comparaison (330) est limitée aux régions d'espace d'adressage ayant un objet de protection à exécution de confiance.
 
8. Procédé selon l'une quelconque des revendications précédentes, comprenant en outre :
l'énumération (326), sur la base de la requête, de la pluralité de modules chargés afin de générer des informations d'adressage de module chargées.
 
9. Le procédé selon la revendication 4, dans lequel la première région de mémoire correspond à un module chargé de la pluralité de modules chargés quand, sur la base de l'étape de comparaison, ce module chargé couvre la première région de mémoire, ou chevauche partiellement la première région de mémoire, et
la première région de mémoire ne correspond à aucun module chargé de la pluralité de modules chargés quand, sur la base de l'étape de comparaison, chaque module chargé de la pluralité de modules chargés se trouve entièrement en dehors de la première région de mémoire.
 
10. Procédé comprenant:
des instructions exécutables sur un système informatique, les instructions comprenant :

(a) l'énumération (324, 326), sur la base d'une requête (322) d'un gestionnaire d'exploitation (599) d'un système informatique envoyée en réponse à une sollicitation, d'une pluralité de régions de mémoire d'un espace d'adressage pour définir des informations d'adressage de région de mémoire, les informations de région de mémoire comprenant une adresse de début et une adresse de fin de chaque région de mémoire de la pluralité de régions de mémoire dans l'espace d'adressage, la sollicitation étant le début d'une opération de prise ;

(b) le balayage de la mémoire du système informatique pour rechercher une injection de mémoire, dans laquelle l'étape de balayage comprend :

(i) la détermination d'une correspondance entre une première région de la pluralité de régions de mémoire et l'un quelconque d'une pluralité de modules chargés enregistrés avec le gestionnaire d'exploitation, l'étape de détermination comprenant :

(A) l'examen de la pluralité de modules chargés pour rechercher des informations d'adressage de module chargés comprenant une adresse de début et une adresse de fin de chacun des modules de la pluralité de modules chargés dans l'espace d'adressage ; et

(B) la comparaison (330) entre les informations d'adressage associées à la première région de mémoire et les informations d'adressage de modules chargés comprenant la comparaison entre l'adresse de début et de l'adresse de fin dans l'espace d'adressage de chacun des modules de la pluralité de modules et l'adresse de début et l'adresse de fin de la première région de mémoire ; et

(ii) dans lequel, lorsque la première région de mémoire ne correspond à aucun des module de la pluralité de modules chargés, il est déterminé (338) si la première région de mémoire contient un exécutable, et, lorsque la première région de mémoire contient un exécutable, une alarme d'injection de mémoire est générée (337).


 
11. Procédé selon la revendication 10, dans lequel l'alarme d'injection de mémoire est une première alarme d'injection de mémoire, et l'étape de balayage comprend en outre :
lorsque la première région de mémoire correspond à un module chargé de la pluralité de modules chargés, il est déterminé (336) si ce module est mappé à partir du système de fichiers (140) du système informatique, et, lorsque le module chargé n'est pas mappé à partir du système de fichiers (140) du système informatique, une seconde alarme d'injection de mémoire est générée (335).
 




Drawing















































Cited references

REFERENCES CITED IN THE DESCRIPTION



This list of references cited by the applicant is for the reader's convenience only. It does not form part of the European patent document. Even though great care has been taken in compiling the references, errors or omissions cannot be excluded and the EPO disclaims all liability in this regard.

Patent documents cited in the description




Non-patent literature cited in the description