Preventing unauthorized loading of late binding code into a process

Description

TECHNICAL FIELD

This invention pertains generally to computer operating system internals, and more specifically to preventing unauthorized loading of late binding code into process address space.

BACKGROUND

It is important to protect software processes from having unknown late binding objects (e.g., dynamic link libraries) loaded into their address space. For example, various 32 bit versions of Microsoft Windows® such as Windows NT® include a registry key that lists dynamic link libraries (dll's) to load into a process's address space when the process is loaded into memory. In such versions of Windows®, user32.dll reads this registry key at process load time, and loads the dll's listed therein into the process's address space.

Although such functionality can be useful under some circumstances, it creates a security hole, as it allows unknown and hence possibly malicious dll's to be loaded into the address space of any process. What is needed are computer implemented methods, computer readable media and computer systems for preventing unauthorized loading of late binding code into a process. Because it can be desirable to load some late binding code (e.g., trusted dll's) into the a process's address space, computer implemented methods, computer readable media and computer systems that allow selective loading of permitted late binding code would be beneficial.

DISCLOSURE OF INVENTION

Computer-implemented methods, computer systems and computer-readable media enable the prevention of unauthorized loading of late binding code into a process. In one embodiment, a late binding code manager detects attempts to load late binding code into a process's address space. The late binding code manager determines whether detected attempts are permitted. Responsive to the results of a determination as to whether an attempt to load late binding code into a process's address space is permitted, the late binding code manager executes at least one additional step affecting the loading of the late binding code into the process's address space. Such a step can comprise permitting, blocking or modifying the attempt to load the late binding code.

The features and advantages described in this disclosure and in the following detailed description are not all-inclusive, and particularly, many additional features and advantages will be apparent to one of ordinary skill in the relevant art in view of the drawings, specification, and claims hereof. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter, resort to the claims being necessary to determine such inventive subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating a high level overview of a system for practicing some embodiments of the present invention.

FIG. 2 is a flowchart illustrating steps for preventing the unauthorized loading of late binding code, according to some embodiments of the present invention.

FIG. 3 is a flowchart illustrating steps for allowing the authorized loading of late binding code, according to some embodiments of the present invention.

The Figures depict embodiments of the present invention for purposes of illustration only. One skilled in the art will readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles of the invention described herein.

DETAILED DESCRIPTION

FIG. 1 illustrates a high level overview of a system 100 for practicing some embodiments of the present invention. A late binding code manager 101 prevents unauthorized loading of late binding code 103. It is to be understood that although the late binding code manager 101 is illustrated as a single entity, as the term is used herein a late binding code manager 101 refers to a collection of functionalities which can be implemented as software, hardware, firmware or any combination of these. Where a late binding code manager 101 is implemented as software, it can be implemented as a standalone program, but can also be implemented in other ways, for example as part of a larger program, as a plurality of separate programs, as one or more device drivers or as one or more statically or dynamically linked libraries.

This specification describes performing some embodiments of the present invention within the context of a current Microsoft Windows NT® configuration (including versions of Windows based on NT, such as XP, 2000 and 2003). Thus, the names of system components and system functions used herein are those of the current version of Windows NT®. Of course, the present invention is not tied to Windows NT®, or to these names specifically, and in various embodiments of the present invention the described components can have other names as desired. For example, user32.dll 109 might have a different name in future or different versions of Windows, all of which would be within the scope of the present invention.

As illustrated in FIG. 1, the late binding code manager 101 detects an attempt to load late binding code 103 into a process's 105 address space 107. More specifically, in the example embodiment illustrated in FIG. 1, the late binding code manager 101 detects that user32.dll 109 is attempting to load late binding code 103 in the form of at least one dll 103 into a process's 105 address space 107 by accessing a specific key 111 in the registry 113 which lists the dll's 103 to insert into a process's 105 address space 107 at load time. As explained above, this feature of Windows® creates a security hole.

In the embodiment illustrated in FIG. 1, the late binding code manager 101 monitors access of the registry 113 key 111 to detect attempts to load late binding code 103 into a process's 105 address space 107. Upon detecting access of the registry 113 key 111 that enumerates late binding code 103 to load into a process's 105 address space 107, the late binding code manager 101 determines whether the attempt to load the late binding code 103 is permitted, as discussed in detail below. The implementation mechanics of monitoring access of the registry key 111 will be readily apparent to those of ordinary skill in the relevant art in light of this specification. For example, access to the key 111 can be monitored by wrapping and intercepting the system functions that access the registry, and watching for attempts to access the specific key 111 that is of interest.

In some embodiments, the late binding code manager 101 specifically monitors access by user32.dll 109 to the registry 113 key 111 that enumerates late binding code 103 to load into a process's 105 address space 107, as user32.dll 109 is the code that currently loads the dll's 103 listed in the key 111 at process 105 load time. In other embodiments, the late binding code manager 101 monitors access to the registry 113 key 111 by other programs, or all access thereto as desired.

In some embodiments of the invention, the late binding code manager 101 detects attempts to load late binding code 103 other than dll's 103 (e.g., .COM objects, etc.) into process 105 address space. Additionally, in some embodiments of the invention, the late binding code manager 101 detects attempts to load late binding code 103 into process 105 address space 107 in ways other than by monitoring access to a registry 113 key 111, for example in systems where a list of such late binding code 103 is stored elsewhere, such as a system table or other data structure.

Once the late binding code manager 101 detects and attempt to load late binding code 103 into process 105 address space 107, the late binding code manager 101 determines whether the attempt is permitted. In some embodiments, the late binding code manager 101 makes this determination simply on the basis of the process 105 which is the target of the late binding code 103 injection. In such embodiments, all attempts by any program to load late binding code 103 into any process 105 that is designated as being protected are not permitted. Which processes 105 to protect is a variable design parameter, configurable, for example, by a system administrator. In other embodiments, only attempts to load late binding code 103 into a protected process 105 by user32.dll 109 (or alternatively other specific system resource(s)) are forbidden.

In yet other embodiments, permission can be a function of the late binding code 103 which is the subject of the loading attempt. For example, the late binding code manager can examine the individual dll's 103 (or other type of late binding code 103 module) listed in the registry 113 key 111 (or listed elsewhere), and determine whether specific dll's 103 are permitted to be loaded into the address space 107 of protected (or specific protected) processes 105. For example, it can be permitted to load dll's 103 that are on a white list (or alternatively not on a black list), or not permitted to load dll's 103 that are on a black list (or not on a white list). Of course, other criteria are possible as well, for example whether the dll 103 is digitally signed and/or originates from a trusted source.

Responsive to the results of the determination as to whether the attempt to load late binding code 103 into the process's 105 address space 107 is permitted, the late binding code manager 101 executes at least one additional step affecting loading of late binding code 103 into the process's 105 address space 107.

Turning now to FIG. 2, steps are illustrated for determining that the attempt to load late binding code 103 is not permitted, and for responding to that determination, according to some embodiments of the present invention. The late binding code manager 101 detects 201 an attempt to load late binding code 103 (e.g., a list of dll's 103 enumerated in the registry 113 key 111 described above) into a process's 105 address space 107. In some embodiments, the late binding code manager 101 checks the dll's 103 to be loaded against a black list of prohibited dll's 103, and determines 203 that at least one of the dll's 103 to be loaded is on the black list. In some embodiments, the late binding code manager 101 prevents 211 the loading of the blacklisted dll's 103 and allows 309 the loading of dll's 103 listed in the registry 113 key 111 that are not on the black list. In other embodiments, if even one of the dll's 103 listed in the registry 113 key 111 is blacklisted, the late binding code manager 101 prevents 211 the loading of all dll's 103 into the process's 105 address space 107.

In some embodiments, the late binding code manager 101 checks the dll's 103 to be loaded against a white list of trusted dll's 103, and determines 205 that at least one of the dll's 103 to be loaded is not on the white list. In some embodiments, the late binding code manager 101 prevents 211 the loading of the dll's 103 that are not on the white list, and allows 309 the loading of dll's 103 listed in the registry 113 key 111 that are on the white list. In other embodiments, if even one of the dll's 103 listed in the registry 113 key 111 is not on the white list, the late binding code manager 101 prevents 211 the loading of all dll's 103 into the process's 105 address space 107.

In some embodiments, the late binding code manager 101 checks whether the dll's 103 to be loaded are digitally signed, and determines 207 that at least one of the dll's 103 to be loaded is not. In some embodiments, the late binding code manager 101 prevents 211 the loading of the dll's 103 that are not digitally signed, and allows 309 the loading of dll's 103 listed in the registry 113 key 111 that are digitally signed. In other embodiments, if even one of the dll's 103 listed in the registry 113 key 111 is not digitally signed, the late binding code manager 101 prevents 211 the loading of all dll's 103 into the process's 105 address space 107.

In some embodiments, the late binding code manager 101 checks whether the dll's 103 to be loaded originate from a trusted source, and determines 209 that at least one of the dll's 103 to be loaded does not. In some embodiments, the late binding code manager 101 prevents 211 the loading of the dll's 103 that do not originate from a trusted source, and allows 309 the loading of dll's 103 listed in the registry 113 key 111 that do. In other embodiments, if even one of the dll's 103 listed in the registry 113 key 111 does not originate from a trusted source, the late binding code manager 101 prevents 211 the loading of all dll's 103 into the process's 105 address space 107.

FIG. 3 illustrates steps for determining that the attempt to load late binding code 103 is permitted, and for responding to that determination, according to some embodiments of the present invention. The late binding code manager 101 detects 201 an attempt to load late binding code 103 into a process's 105 address space 107. In some embodiments, the late binding code manager 101 checks the dll's 103 (or other late binding code modules 103) to be loaded against a white list of trusted dll's 103, and determines 301 that at least one of the dll's 103 to be loaded is on the white list. In some embodiments, the late binding code manager 101 allows 309 the loading of the white listed dll's 103 and prevents 211 the loading of dll's 103 listed in the registry 113 key 111 that are not on the white list. In other embodiments, if even one of the dll's 103 listed in the registry 113 key 111 is not on the white list, the late binding code manager 101 prevents 211 the loading of all dll's 103 into the process's 105 address space 107.

In some embodiments, the late binding code manager 101 checks the dll's 103 to be loaded against a black list of prohibited dll's 103, and determines 303 that at least one of the dll's 103 to be loaded is not on the black list. In some embodiments, the late binding code manager 101 allows 309 the loading of the dll's 103 that are not on the black list, and prevents 211 the loading of dll's 103 listed in the registry 113 key 111 that are on the black list. In other embodiments, if even one of the dll's 103 listed in the registry 113 key 111 is blacklisted, the late binding code manager 101 prevents 211 the loading of all dll's 103 into the process's 105 address space 107.

In some embodiments, the late binding code manager 101 checks whether the dll's 103 to be loaded are digitally signed, and determines 305 that at least one of the dll's 103 to be loaded is. In some embodiments, the late binding code manager 101 allows 309 the loading of all dll's 103 that are digitally signed, and prevents 211 the loading of dll's 103 listed in the registry 113 key 111 that are not digitally signed. In other embodiments, if even one of the dll's 103 listed in the registry 113 key 111 is not digitally signed, the late binding code manager 101 prevents 211 the loading of all dll's 103 into the process's 105 address space 107.

In some embodiments, the late binding code manager 101 checks whether the dll's 103 to be loaded originate from a trusted source, and determines 307 that at least one of the dll's 103 to be loaded does. In some embodiments, the late binding code manager 101 allows 309 the loading of all dll's 103 that do originate from a trusted source, and prevents 211 the loading of dll's 103 listed in the registry 113 key 111 that do not. In other embodiments, if even one of the dll's 103 listed in the registry 113 key 111 does not originate from a trusted source, the late binding code manager 101 prevents 211 the loading of all dll's 103 into the process's 105 address space 107.

As will be understood by those familiar with the art, the invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Likewise, the particular naming and division of the modules, managers, functions, layers, features, attributes, methodologies and other aspects are not mandatory or significant, and the mechanisms that implement the invention or its features may have different names, divisions and/or formats. Furthermore, as will be apparent to one of ordinary skill in the relevant art, the modules, managers, functions, layers, features, attributes, methodologies and other aspects of the invention can be implemented as software, hardware, firmware or any combination of the three. Of course, wherever a component of the present invention is implemented as software, the component can be implemented as a script, as a standalone program, as part of a larger program, as a plurality of separate scripts and/or programs, as a statically or dynamically linked library, as a kernel loadable module, as a device driver, and/or in every and any other way known now or in the future to those of skill in the art of computer programming. Additionally, the present invention is in no way limited to implementation in any specific programming language, or for any specific operating system or environment. Accordingly, the disclosure of the present invention is intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.