Patent Application
20130326619
This application claims priority to and the benefit of GB Application No. 1209463.7, filed May 29, 2012, the disclosure of which is incorporated herein by reference in its entirety.
This application relates generally to the control of applications running on a computer. In some known computer environments specific users are given limited rights to perform certain actions. For example, certain users may have basic rights, whereas other users may have administrator rights, allowing them to perform more complex or potentially dangerous actions, such as installing new applications or even running certain pre-installed applications.
Problems can exist in certain forms of managed environments, where a user is able to run an application which itself can incorporate what is effectively a further application in the form of a macro or embedded code, such as Visual Basic (VB) or PowerShell. This form of embedded program is common in applications such as Microsoft Excel®. In some known systems, a user who wishes to circumvent or frustrate certain security checks and audit features can run, using the Excel framework, an embedded macro or piece of code that is capable of making calls to the Operating System (OS), allowing the user possibly unlimited access to functions and processes, which would not normally be available to the user.
Accordingly, a need exists for systems and methods to identify such threats and to take steps to ensure that any potential vulnerabilities are dealt with accordingly.
In some embodiments, a method includes storing, at a first time, a copy of an executable process at a memory area if an initial thread of the executable process is defined in a suspended state such that the copy of the executable process is not executed at the memory area. The executable process can be maintained at a storage different from the memory area. The method also includes comparing, at a second time after the first time, a header of a section of the executable process with a header of a section of the copy of the executable process. The method further includes determining not to execute the executable process if the header of the section of the executable process is different from the header of the section of the copy of the executable process.
In some embodiments, a method include storing, at a first time, a copy of an executable process at a memory area if an initial thread of the executable process is defined in a suspended state. As a result, the copy of the executable process is not executable at the memory area. The executable process can be maintained at a storage different from the memory area. The method also includes comparing, at a second time after the first time, content of a header of a section of the executable process with content of a header of a section of the copy of the executable process. The method further includes determining not to execute the executable process if the content of the header of the section of the executable process is different from the content of the header of the section of the copy of the executable process.
In some embodiments, if the content of the header of the section of the executable process is identical to the content of the header of the section of the copy of the executable process, the method can include comparing a number of sections in the executable process with a number of sections in the copy of the executable process. In such embodiments, the method can include determining not to execute the executable process if the number of sections in the executable process is different from the number of sections in the copy of the executable process.
In some embodiments, if the number of sections in the executable process is equal to the number of sections in the copy of the executable process, the method can include comparing content of a set of headers (including the header of the section that is compared previously) of the executable process with content of a set of headers of the copy of the executable process. In such embodiments, the method can include determining not to execute the executable process if the content of the set of headers of the executable process is different from the content of the set of headers of the copy of the executable process.
In some embodiments, if the content of the set of headers of the executable process is identical to the content of the set of headers of the copy of the executable process, the method can include comparing content of the sections of the executable process with content of the sections of the copy of the executable process. In such embodiments, the method can include determining not to execute the executable process if the content of the sections of the executable process is different from the content of the sections of the copy of the executable process.
In some embodiments, an event can be triggered if the executable process is determined not to be executed. Such an event can be, for example, an alarm associated with a user or an administrator.
In some embodiments, a non-transitory processor-readable medium stores code representing instructions to be executed by a processor. The code stored in the medium can include code to cause the processor to duplicate an executable process to define a copy of the executable process if an initial thread of the executable process is defined in a suspended state. The executable process can be maintained at a storage location. The code can include code to cause the processor to store the copy of the executable process at a memory area different from the memory area such that the copy of the executable process is not executed at the memory area.
The code can include code to cause the processor to also compare content of a header of the executable process with content of a header of the copy of the executable process. The code can include code to cause the processor to further send a notification if the content of the header of the executable process is different from the content of the header of the copy of the executable process. In some embodiments, this notification can be sent to a user and/or network administrator. In some embodiments, as a result of sending the notification, the executable process will not be executed.
In some embodiments, an apparatus includes a first memory, a second memory separate from the first memory, a copy module and a comparison module operatively coupled to the first memory and the second memory. The first memory can be configured to store an executable process. The copy module can be configured to store, at a first time, a copy of the executable process within the second memory such that the copy of the executable process is not executed at the second memory. The comparison module can be configured to compare, at a second time after the first time, a number of sections of the executable process with a number of sections of the copy of the executable process. The comparison module can be configured to send a notification if the number of the sections of the executable process is different from the number of the sections of the copy of the executable process In some embodiments, this notification can be sent to a user and/or network administrator. In some embodiments, as a result of sending the notification, the executable process will not be executed.
As used herein, a “module” can be, for example, any assembly and/or set of operatively-coupled electrical components associated with performing a specific function, and can include, for example, a memory, a processor, electrical traces, optical connectors, software (stored and executing in hardware) and/or the like.
As used herein, the singular forms “a,” “an” and “the” include plural referents unless the context clearly dictates otherwise. Thus, for example, the term “a comparison module” is intended to mean a single module or multiple modules configured to perform one or multiple comparison functions described herein.
As shown in
Copy module 202 can be configured to, for example, duplicate an executable process to define a copy of the executable process. In some embodiments, copy module 202 can store the defined copy of the executable process at a memory location different from the memory location where the executable process is stored, such that the copy of the executable process is not executable. Comparison module 204 can be configured to compare data and/or information associated with multiple processes. For example, comparison module 204 can be configured to compare content of one or more headers, a number of sections, content of sections, etc., of multiple processes such as an executable process and a copy of the executable process. Functions of copy module 202 and comparison module 204 are described in further details below.
In some embodiments, processing component 22 can be configured to execute program code stored within storage component 24 such as program 30. In some embodiments, program 30 can be at least partially fixed and/or stored in storage component 24. While executing the program code (e.g., program 30), processing component 22 can be configured to process data, which can result in reading data from and/or writing data to storage component 24 and/or I/O component 26. Data can be further processed at storage component 24 and/or I/O component 26. Communications pathway 28 can provide a communications link between each of the components in computer system 20. I/O component 26 can include one or more human I/O devices (e.g., a screen, keypad, mouse, speaker, microphone, etc.), which enable a human user (e.g., user 12 in
In some embodiments, computer system 20 can include one or more general purpose computing devices that are capable of executing program code (e.g., program 30) installed within computer system 20. As used herein, it is understood that “program code” means any collection of instructions, in any language, code or notation, that can cause a computing device having an information processing capability to perform a particular action either directly or after any combination of the following: (a) conversion to another language, code or notation; (b) reproduction in a different material form; and/or (c) decompression. To this extent, program 30 can be embodied as any combination of system software and/or application software.
In some embodiments, program 30 can be implemented using a set of modules (not shown in
In some embodiments, computer system 200 can include multiple computing devices (not shown in
In some embodiments, when computer system 20 includes multiple computing devices, the computing devices can communicate over any suitable type of communications link(s) (e.g., communications pathway 28 in
In some embodiments, computer system 20 can obtain data from data files 40 using any suitable process and/or method. For example, computer system 20 can generate data files 40, retrieve data from data files 40, which may be stored in one or more data stores, receive data included in data files 40 from another system, and/or the like.
In some embodiments, if an administrator wishes to restrict a user from potentially embedding dangerous code in an application, one practical option is to disable certain script-based functions from the application. This has the adverse effect of barring certain useful and legitimate functions and features, as well as potentially illicit features.
In some embodiments, when a process is initiated and/or created, its initial thread can be scheduled to run immediately. In some other embodiments, the initial thread of a process can be initiated and/or created in a suspended state. However, a particular security vulnerability can occur if the initial thread is initiated and/or created in a suspended state. In this form, the code of the process exists in memory, but is not immediately executed. Instead, the code awaits a further trigger before executing. Once the code is loaded in memory, it is possible for the code to be modified and/or overwritten before the code is executed. Any code which is written over the legitimate code can potentially be used to circumvent security and/or other policy safeguards, since the code has not been subject to security and/or audit checks at the time of loading or creation.
As mentioned, it is possible to initiate and/or create the initial thread of a process in a suspended state. In some embodiments, a check can be made to determine if the initial thread of a process is initiated and/or created in a suspended state. If the initial thread of the process was initiated and/or created in a suspended state, a check can be performed (e.g., at processing component 22) to ensure that the code in memory (e.g., a memory location within storage component 24) is the code which was loaded by the program loader and has not been altered in some potentially damaging way after the code was loaded, but prior to running and/or executing. In some embodiments, an indication that the initial thread is initiated and/or created in a suspended state can be used to automatically trigger an alarm condition. In some embodiments, an administrator may optionally select an option to trigger an alarm when an initial thread of a process is initiated and/or created in a suspended state. In such embodiments, this allows the administrator to tailor a policy based on local issues since there are circumstances in which initiating a thread of a process in a suspended state is legitimate. If no alarm condition is defined as a result of testing for the creation of a suspended thread, then one or more of the following tests, below, can be performed.
There are a number of checks which can be performed (e.g., at comparison module 204) to determine if the code in memory (e.g., in a memory within storage component 24) is legitimate or not. First, the code can include a number of sections, as defined by the particular environment in which the code is intended to operate. For example, the code may reside in a single section, or it may reside in several different sections, some of which can include data sections, rather than executable code. A first simple check is to ensure that the expected number of sections is present and to trigger an alarm condition if an unexpected number of sections is detected. For example, if the code is expected to reside in a single section, but the code in memory actually exists in two or more sections, then this can be an indication that something is amiss, and an alarm condition can be triggered.
A more thorough test is to verify the contents of the memory which includes the mapped area of memory to ensure that the contents of the memory correspond to the expected contents. In some embodiments, such a test can be performed (e.g., by copy module 202) by reading the original executable process or image from storage, and mapping it into an area of memory as an image file. In some embodiments, for example, this can be done (e.g., at copy module 202) by writing code according to the Portable Executable (PE) specification or by use of the Win32 file mapping application programming interfaces (APIs). There are two separate areas of memory which, if everything is in order, should contain identical contents. The first is present in a suspended state and waiting to be executed. The second is in an isolated area of memory and exists to verify the code in the first area of memory.
For example, copy module 202 can be configured to duplicate the original code of the executable process to define a copy of code, and then store the copy of code in a different memory location at storage component 24 such that the copy of code is not executable. Comparison module 204 can then be configured to compare data and/or information (e.g., a number of sections, contents of sections, contents of header(s), etc.) associated with the copy of code with the corresponding data and/or information associated with the target code that is to be checked. The target code is not authenticated if the data and/or information of the two pieces of code does not match.
In some embodiments, a completely thorough test can be performed. In such embodiments, the two areas of memory can be compared word by word. This test can take a relatively long time to complete and, thus, may not be preferred in some situations. However, there may be circumstances when this is desirable as described in further detail herein.
In some embodiments, the section headers can be checked without comparing the two areas of memory word by word. Since section headers include information including a name of the section, a size of the section, a location in memory of the section and additional characteristics of the section, if the code has been altered in any way, then the section header will likely be different. As such, checking the section header can act as a proxy for checking the entire content of the section in question.
However, in certain circumstances, and to be absolutely sure that a section has not been modified, it may be desirable to further check the entire section and perform a byte-by-byte or bit-by-bit comparison. Such a check can impose a higher computational overhead on the system. In particular, it is conceivably possible, although difficult, to change a section such that the header appears to be correct but the section content has been altered.
Situations where a more comprehensive check could be necessary are to address known forms of compromise attack or if a specific section is known to be vulnerable for any reason.
In some embodiments, there are certain applications where the application itself alters the section headers itself in real-time. Examples of such applications include Self-extracting (packed) executables, which may sometimes modify sections in real-time. Other forms of applications, such as third-party monitoring applications (e.g. anti-virus (AV) software or de-bugging utilities) that rely on hooking can also modify section headers in real-time. Thus, such applications, even if legitimate, can cause an alarm condition to be triggered when verifying the section header. For such applications, an administrator can configure the computer system (e.g., computer system 20) such that only the first section header, which is predictable, is checked.
If an alarm condition is triggered as a result of the resident code failing any of the aforementioned tests, then an exit process can be called, with or without warning to the user, so that any vulnerabilities can be eliminated. If the process exits without warning, then the program can simply appear to cease execution. A message may or may not be sent to the user or an administrator, in accordance with certain preset security policies.
Alternatively, the process can exit with a warning message being sent to the user. In some embodiments, the warning message may be preset with a relatively bland warning, merely informing the user that a problem has occurred. In other embodiments, a more detailed message can be provided. The message may request that the user contacts an administrator to discuss the issue, which may allow the administrator to understand what the user was attempting and whether it was an attempt to circumvent security and/or audit controls.
At step 130, the content of the first section of the original executable process can be compared with the content of the first section in the copy of the original executable process. If the content of the first sections are found to be identical, then the normal execution proceeds at step 150. However, if the content of the first sections are found to differ, then this is an indication that the executable code has potentially been compromised and the executable process can be terminated at step 140. It is important to note that by use of this technique, the suspended thread will not be executed and thus, it is completely isolated while the check is performed.
In some embodiments, a notification can be sent instead of and/or in addition to the executable process being terminated and/or not being executed. In such embodiments, a notification can be sent to a user and/or a network administrator. Such a user and/or network administrator can then take action (e.g., terminate and/or cause the executable process to not execute). Such a notification can be any suitable message such as, for example, an email message, an alert via a monitoring program, a text alert, and/or the like.
In some embodiments, the method 200 illustrated in
Embodiments of the present invention allow an administrator to effectively control the execution of embedded code within a certain environment. In particular, an attempt to circumvent security and access policies by concealing inappropriate code in, for example, another application, can be detected and neutralized by means of embodiments described above.
Attention is directed to all papers and documents that are filed concurrently with or previous to this specification in connection with this application and which are open to public inspection with this specification, and the contents of all such papers and documents are incorporated herein by reference.
The features disclosed in this specification (including any accompanying claims, abstract and drawings), and/or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and/or steps are mutually exclusive.
Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features.
Some embodiments described herein relate to a computer storage product with a non-transitory computer-readable medium (also can be referred to as a non-transitory processor-readable medium) having instructions or computer code thereon for performing various computer-implemented operations. The computer-readable medium (or processor-readable medium) is non-transitory in the sense that it does not include transitory propagating signals per se (e.g., a propagating electromagnetic wave carrying information on a transmission medium such as space or a cable). The media and computer code (also can be referred to as code) may be those designed and constructed for the specific purpose or purposes. Examples of non-transitory computer-readable media include, but are not limited to: magnetic storage media such as hard disks, floppy disks, and magnetic tape; optical storage media such as Compact Disc/Digital Video Discs (CD/DVDs), Compact Disc-Read Only Memories (CD-ROMs), and holographic devices; magneto-optical storage media such as optical disks; carrier wave signal processing modules; and hardware devices that are specially configured to store and execute program code, such as Application-Specific Integrated Circuits (ASICs), Programmable Logic Devices (PLDs), Read-Only Memory (ROM) and Random-Access Memory (RAM) devices. Other embodiments described herein relate to a computer program product, which can include, for example, the instructions and/or computer code discussed herein
Examples of computer code include, but are not limited to, micro-code or micro-instructions, machine instructions, such as produced by a compiler, code used to produce a web service, and files containing higher-level instructions that are executed by a computer using an interpreter. For example, embodiments may be implemented using Java, C++, or other programming languages (e.g., object-oriented programming languages) and development tools. Additional examples of computer code include, but are not limited to, control signals, encrypted code, and compressed code.
While various embodiments have been described above, it should be understood that they have been presented by way of example only, not limitation, and various changes in form and details may be made. Where methods described above indicate certain events occurring in certain order, the ordering of certain events may be modified. Additionally, certain of the events may be performed concurrently in a parallel process when possible, as well as performed sequentially as described above. Any portion of the apparatus and/or methods described herein may be combined in any combination, except mutually exclusive combinations. The embodiments described herein can include various combinations and/or sub-combinations of the functions, components and/or features of the different embodiments described.
| Number | Date | Country | Kind |
|---|---|---|---|
| 1209463.7 | May 2012 | GB | national |
