BRPI0501650B1 - Method for applying a software patch to multiple instances of an executable module and computer readable storage memory - Google Patents

Description

Patent Descriptive Report for "METHOD FOR APPLYING A SOFTWARE PATCH TO MULTIPLE INSTRUCTIONS OF AN EXECUTABLE MODULE AND COMPUTER-READY STORAGE MEMORY".

Field of the Invention The present invention is directed to the update field of the operation of installed computer programs.

Background of the Invention [002] Patching is the process of modifying already installed programs, including application programs, utility programs, operating systems, and device driver * operating system components, etc. Patching can be useful for modifying programs for a variety of purposes, including correcting a programming error, reducing or eliminating a security risk, or improving the logic used by the modified program. Patching is typically initiated by the company or other organization. originally supplied the program to be fixed.

[003] Installed programs are predominantly made up of executable code modules. As an example, many programs designed to run on Microsoft Corp.'s WINDOWS XP operating system from Redmond, Washington are predominantly made up of executable code modules called “DLLs”. A popular conventional approach to the patch is to identify, among executable code modules making the installed program to be patched, the executable code module containing the program code that one wishes to modify with a patch; creating a new version of the identified executable code module in which the desired modification is made; and distributing the new version of the identified executable code module, along with an installer program, to users who may wish to apply the fix. Each user determines whether to apply the fix, and if so, runs the installer program, which replaces the original version of the identified executable code module with the new version of the identified executable code module.

Conventional approaches to correction have a number of significant disadvantages. These disadvantages often increase the burden associated with receive and apply fixes. In some cases, this increased load delays some users from applying some fixes, and even prevents some users from applying some fixes. Such delays and impediments to patching can in some cases have serious negative consequences for users, especially for patches designed to reduce or eliminate a security risk.

[005] A disadvantage of conventional correction approaches is related to common cases in which multiple corrections must be created and distributed to make a single modification to a single program. In some cases, the program to be patched has several different "flavors" of a particular executable code module, such as a different flavor for each operating system or operating system version on which the program is designed to run, and / or each natural language version of the program. Where the identified executable code module is such an executable code module, the patch creation and distribution process described above must be repeated for each flavor of the identified executable code module. The user must then select and apply the correction for the appropriate flavor of the identified executable code module. Selecting from the resulting large number of patches and selecting the appropriate set of patches to apply to each user computer system can be very cumbersome, so much so that this condition is sometimes referred to as the “hell of patches”. In some cases, an administrator must maintain a database of the invention identifying the set of executable module versions installed on each target system, which is used to select appropriate conventional fixes for each target system.

Another disadvantage of conventional approaches to correction is related to the large size of distributed corrections. It is not uncommon for executable code modules to be sized in megabytes, which in turn cause a single fix to be of comparable size, making it uncomfortable to distribute and store, or even impossible to distribute and store, for some users. . This problem can be multiplied for corrections that have multiple flavors. Additionally, because each conventional fix typically includes an integer surrogate executable module, applying conventional fixes can contribute to the code modification problem.

[007] An additional disadvantage of conventional correction approaches is that some users need to test corrections before applying them to production computer systems. In some cases, installing a patch on a computer system can have adverse results, such as the new version of the identified executable code module contained in the patch introducing a new programming error, or where it causes unpredictable new interaction with another program. running on the computer system against which it is applied. Consequently, often before applying a correction against a production system whose data and operation are important to sustain, the user first applies the correction against a test system to assess whether the correction is safe to apply to the production system. Such a separate patch test adds to the load associated with the patch. Additionally, where a conventional fix creates a problem - such as an application compatibility issue or a newly exploited vulnerability - at a time substantially after a fix is applied, it may be difficult to trace such issues back to the fix.

[008] An additional disadvantage of conventional fix approaches is related to the installer operation included in the fix. Often, in order to replace an executable code module that is part of the runtime program, the installer must first finish running that program. Also, in some cases, such replacement may cause substantial interruptions in the use of the patched computer system.

Another disadvantage of conventional approaches to correction involves attempting to correct an executable module for which a "private fix", also called a "hot fix", has previously been issued to an appropriate subset of the patches. clients for this executable module. In such cases, because of difficulties encountered in distributing conventional fixes that replace different new versions of the executable code module depending on each user depending on whether the user has applied the hot fix, it is typical that instead of distributing a single conventional fix that replaces a new single version of the executable module without regard to whether the user applied the quick fix. If this new version incorporates quick fix, the fix imposes quick fix on customers who do not intend to receive it. If, on the other hand, this new version does not incorporate quick fix, it neglects customers who want to get quick fix from quick fix.

Another disadvantage of conventional patching approaches involves the fact that installers for software products that have a particular executable module, such as a particular dynamic link library, often “hide” that executable module by storing it in a non-default location in the target computer system file system. Consequently, it is sometimes difficult or impossible to determine if a particular target system contains a copy of an executable module to be patched, and if so, where it resides in the target computer system file system. Also, some software products maintain a "catalog" of executable module versions that were installed by their installers. A software product may rely on the correction of an indication in the version catalog of a particular executable module. Such trust is destroyed where a conventional fix replaces the executable module version identified in the catalog with a new executable module version without updating the catalog.

Another disadvantage of conventional fix approaches is that they are impossible to apply before the executable module to be fixed is installed on the target computer system. As a result, if the executable module to be patched is installed on the target computer system after a conventional fix for that executable module is received, it is unreasonable that the patch will be applied to the executable module.

Another disadvantage of conventional correction approaches is that they can typically only be applied by a user logged on to the target computer system using an administrative account having liberal modification permissions. Connecting to an administrative account for this purpose can make the target computer system vulnerable to viruses present in the target computer system by seeking to modify aspects of the target computer system and requesting liberal permissions to do so.

Another disadvantage of conventional fix approaches is that conventional fixes can be difficult or impossible to disable by requesting steps such as reverting the replacement of an executable module, or reverting one or more modifications to the system registry. [0014] Therefore, a new correction approach that overcomes some or all of the disadvantages of conventional correction approaches discussed above would have significant utility. BriefDescriptosDrawings Figure 1 illustrates an example of a suitable computing system environment in which the feature can be deployed.

[0016] Figure 2 is a data flow diagram showing a typical data exchange between computing systems according to the feature.

Figure 3 is a flow chart showing steps typically performed by the feature to receive and process a new correction.

Figure 4 is a data structure diagram showing a typical example fix table of those used by the feature.

[0019] Figure 5 is a flow chart showing steps typically performed by the feature to update configuration instructions for a particular fix.

[0020] Figure 6 is a flow chart showing steps typically performed by the feature of performing parameter validation specified by a correction.

Detailed Description of the Invention A software feature for correcting installed computer program code ("the feature") is provided. In some embodiments, the feature adds parameter testing and test results dealing with installed functions. In other embodiments, the feature adds several other types of functionality to installed functions, in some cases at arbitrary positions in the installed function execution streams.

In some embodiments, for each correction, the resource distributes to each computing system to be corrected - for example, each "target computer system" - the specification of a point at which to perform a test, the identification of the test to perform, and how to act in response to one or more different test results. In some embodiments, the feature provides a standard set of parameter validation and other tests that can be specified in corrections. For example, a correction might specify that, for a particular function, if a particular function parameter does not have a certain value, the function call must fail before its substantive execution begins. Another fix may specify that for a particular function, if a particular parameter has a length exceeding a specified maximum length, the parameter must be truncated to the specified maximum length before execution of the function is allowed to proceed. Many security prowess rely on getting functions to be called with parameter values that, while they were not locked in the original version of a function code, causes the function to create or take advantage of an unsafe condition. In many cases, such exploits can be prevented by using such corrections to prevent the function from executing with such parameter values. In some embodiments, corrections specify the testing of values other than function parameters, such as values read from a file or entered by the user.

In some embodiments, an automated remediation agent automatically receives each correction, validates it, and stores it in a correction table for possible application. In some embodiments, each patch is applied to any instances of the executable module to be patched that have already been loaded on the target computer system when the patch is received. This approach is referred to here as "quick fix", and enables fixes to become effective immediately upon receipt, and does not require the feature to be able to determine where the executable module to be patched is stored on disk. In some embodiments, each received patch is applied to the executable module disk image to be patched, such that when the disk image is loaded at future times, the loaded disk image includes the patch. This approach is referred to here as “cold correction”, and allows corrections to be persistent across multiple sessions. In some modes, the feature performs both quick fix and cold fix. In some embodiments, each patch is applied to the executable module to be patched each time the executable module to be patched is loaded by the operating system loader. This approximation is referred to here as “charge time correction”. In some embodiments, each correction is applied to the executable module to be corrected each time the function to be corrected is called. This approach is referred to here as “call intercept correction”. Load time correction and call trap correction both (1) do not require the ability to determine where the executable module to be patched is stored on disk, (2) readily facilitate the reversibility of a particular patch, and ( 3) Do not require modification of the executable module disk image.

In some embodiments, the feature allows a user or administrator to configure the operation of patches that have been applied. As an example, such a setting may include, for a particular applied correction: if the test specified by the correction is performed when the execution reaches the specified point for the correction; whether handling of the test result specified by the correction is performed or ignored; and / or whether the performance of the test and / or its result is accessed, displayed in a warning message, etc. In these modalities, the feature allows corrections to be tested on production computer systems by initially enabling access and disabling the handling of the result. In these embodiments, the feature additionally allows patch operation to be accessed in a “verbose” mode after enabling its result handling to assist in identifying instances in which the patch is creating a problem, such as an application compatibility issue or another IT problem. These modalities also allow a fix to be quickly disabled after it is applied if the fix is found to be creating problems. Some modes of the feature also allow the fix to be quickly disabled by simply deleting the fix from the received patch set and stored on the target computer system.

In some embodiments, the feature uses a “triggered data” correction approximation, where corrections contain no code but no data, such as a small human-readable text or XML document, which specifies a point at which perform a test, identify the test to perform, and how to act in response to one or more different test results. In such embodiments, a remediation agent receives triggered data corrections, and adds the tests and test handling specified by the corrections. In some embodiments, the feature uses a “code fired” correction approximation, and each correction contains a short program to be added to the executable module to be corrected that it performs the test itself by calling the default function parameters test functions. , and that he himself performs the test treatment.

Using triggered data correction or triggered code correction, it is sometimes possible to address all flavors of an executable module to be corrected with a single correction.

In some embodiments, the feature signs each correction to demonstrate both that (1) the correction is from an approved source, and (2) the content of the correction has not been modified since the time the correction was created by the source. approved.

In some embodiments, the feature distributes each patch to every target computer system, and a patch agent on the target computer system automatically determines which patches to apply to the target computer system, and how they are to be applied. , based on the characteristics of the target computer system. This helps users and administrators of many of the loads conventionally associated with selection and application corrections, and the burden of maintaining a current and accurate database of the invention. For example, these features may include which version of the executable module to be patched is installed on the target computer system. In such embodiments, the feature can overcome the kind of problems typically caused by quick fixes by distributing fixes that specify different handling for quick and not quickly fixed flavors of a particular executable module, obviating any need to or sacrificing quick fix for an executable module. particular or make the quick fix ubiquitous when correcting this executable module.

In some embodiments, the patch agent stores each patch received on the target system, without regard to whether the executable module to be patched by a particular patch is installed on the target system when the patch is received. Because the feature in many cases applies patches in response to loading an executable module to be patched or calling a function to be patched, the feature can apply a patch to an executable module that was installed on the target system after the patch was patched. received on the target system. Also, patches can survive the uninstall and subsequent reinstallation of the executable module to be patched.

In some embodiments, the patching agent is deployed to an operating system service. In these modalities, the feature agrees with the remediation agent for any permissions requested to apply a remediation. These modalities reduce the security risk typically imposed when conventional fixes are applied, as they obviate any need for a user to connect to the target computer system using an administrative account having broad modify permissions, and thereby give any viruses. Present in the target computer system a great opportunity to modify sensitive aspects of the target computer system.

The fixes used by the feature are typically relatively small, and thus impose modest feature requests for transmission and storage. Also, because the fixes used by the feature tend to modify the behavior of patched software in a smaller number of well-defined modes, the feature helps reduce the code modification problem.

[0031] Figure 1 illustrates an example of a suitable computing system environment 100 in which the feature can be deployed. The computing system environment 100 is only an example of a suitable computing environment and is not intended to suggest any limitations as to the scope of feature use or functionality. Nor should computing environment 100 be construed as having any dependency or requirement on any or all of the components illustrated in the exemplary operating environment 100.

[0032] The feature is operational with numerous other computer system environments or general purpose or special purpose configurations. Examples of well-known computing systems, environments and / or configurations that may be suitable for use with the feature include, but are not limited to: personal computers, server computers, portable or laptop devices, tablet devices. ), multiprocessor systems, microprocessor based systems, TV internet connection devices, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of above systems or devices, and the like.

The feature can be described in the general context of computer executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, and so on, which perform particular tasks or implement particular abstract data types. The feature can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are connected through a communications network. In a distributed computing environment, program modules may be located on local and / or remote computer storage media including memory storage devices.

Referring to Figure 1, an exemplary system for implementing the feature includes a general purpose computing device in the form of a computer 110. Computer components 110 may include, but are not limited to, a processing unit 120, a system memory 130, and a system bus 121 that couples various system components including system memory to the processing unit 120. The system bus 121 can be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industrial Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA bus (EISA), VESA Electronic Video Standards Association local bus, and Interconnected Peripheral Component (PCI) bus also known as Mezzanine bus.

Computer 110 typically includes a variety of computer readable media. Computer readable media may be any available media accessible by computer 110 and include both volatile and non-volatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes volatile, non-volatile, removable and non-removable media implemented in any method or technology for storing information as well as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, fast memory or other memory technology, CD-ROM, digital versatile discs (DVD) or other optical disc storage, magnetic cassettes, magnetic tape. , magnetic disk storage or other magnetic storage devices, or any other means that may be used to store the desired information and which may be accessed by the computer 110. The media typically incorporates computer readable instructions, data structures data, program modules or other data in a modulated data signal as well as a carrier wave or other transport mechanism and include any means of delivering information. The term "modulated data signal" means a signal that has one or more of its characteristics adjusted or altered in such a way as to encode information in the signal. By way of example, and not limitation, the media includes wired media as well as a wired network or direct wired connection, and wireless as well as acoustic, RF, infrared and other wireless media. Combinations of which any of the above should also be included within the scope of computer readable media.

System memory 130 includes computer storage media in the form of volatile and / or non-volatile memory as well as read-only memory (ROM) 131 and random access memory (RAM) 132. A basic input system Output 133 (BIOS), containing the basic routines that help transfer information between elements in computer 110, such as during startup, is typically stored in ROM 131. RAM 132 typically contains data and / or program modules that are immediately accessible for and / or presently to be operated by processing unit 120. By way of example, and not limitation, Figure 1 illustrates operating system 134, application programs 135, other program modules 136, and program data 137.

Computer 110 may also include other removable / non-removable, volatile / non-volatile computer storage media. By way of example only, Figure 1 illustrates hard disk drive 141 that reads or writes to non-removable, nonvolatile magnetic media, a magnetic disk drive 151 that reads or writes to a removable, nonvolatile magnetic disk 152, and an optical disk drive 155 that reads or writes to a nonvolatile removable optical disk 156 such as a CD ROM or other optical medium. Other removable / non-removable, volatile / non-volatile computer storage media that may be used in the exemplary operating environment include, but are not limited to, magnetic cassette tapes, fast memory cards, versatile digital discs, digital video tape. , Solid state RAM, solid state ROM, and the like. Hard disk drive 141 is typically connected to system bus 121 via a non-removable memory interface such as interface 140, and magnetic disk drive 151 and optical disk drive 155 are typically connected to system bus 121. by a removable memory interface, such as interface 150.

The drives and their associated computer storage media, discussed above and illustrated in Figure 1, provide for the storage of computer readable instructions, data structures, program modules, and other data for computer 110. In Figure 1, for example, hard disk drive 141 is illustrated as a storage operating system 144, application programs 145, other program modules 146, and program data 147. Note that these components may be both equal and different from operating system 134, application programs 135, other program modules 136, and program data 137. Operating system 144, application programs 145, other program modules 146, and program data 147 are given different numbers here to illustrate that at a minimum, They are different copies. A user may enter commands and information into computer 110 through input devices such as a data card, or electronic digitizer 164, a microphone 163, a keyboard 162, and a pointing device 161, commonly referred to as a mouse, trackball. or touch table. Other input devices not shown in Figure 1 may include a steering lever, game pad, satellite antenna, digitizer, or the like. These and other input devices are often connected to processing unit 120 via an input interface 160 which is coupled to the system bus, but may be connected by other interface and bus structures such as a parallel port, game port. or a universal serial bus (USB). A monitor 191 or other type of display device is also connected to system bus 121 via an interface as well as a video interface 190. Monitor 191 may also be integrated with a touch screen panel or the like. Note that the touchscreen monitor and / or panel may be physically attached to a housing in which the computing device 110 is incorporated, such as a data card type personal computer. In addition, computers such as computing device 110 may also include other peripheral output devices such as speakers 195 and printer 196, which may be connected via a peripheral output interface 194 or the like.

Computer 110 can operate in a network environment using logical connections to one or more remote computers, such as remote device 180. Remote device 180 can be a personal computer, a server, a router, a network PC , an even device or other common network node, and typically includes many or all of the elements described with respect to computer 110, although only one memory storage device 181 has been illustrated in Figure 1. The logical connections described in Figure 1 include a local area network (LAN) 171 and a wide area network (WAN) 173, but may also include other networks. Such network environments are common in offices, large enterprise computer networks, intranets, and the Internet. For example, in the present resource, computer system 110 may comprise source mechanism from which data is being migrated, and remote computer 180 may comprise destination mechanism. Note however that source and destination mechanisms need not be connected by a network or any other devices, but instead data can be migrated via any means capable of being written by the source platform and read by the target platform or platforms.

When using a LAN network environment, computer 110 is connected to LAN 171 via a network interface or adapter 170. When using a WAN network environment, computer 110 typically includes a modem 172 or other devices to establish WAN 173, such as the Internet. Modem 172, which may be internal or external, may be connected to system bus 121 via user input interface 160 or another appropriate mechanism. In a networked environment, program modules represented with respect to computer 110, or parts thereof, may be stored in the remote memory storage device. By way of example, and not limitation, Figure 1 illustrates remote application programs 185 as residing in memory device 181. It will be appreciated that the network connections shown are exemplary and other devices for establishing a communications link between computers may be provided. used.

While various features and data are shown in Figure 1 as residing in particular computer systems that are arranged in a particular manner, those skilled in the art will appreciate that such features and data may be distributed in various ways through computer systems in particular. Different arrangements. While computer systems configured as described above are typically used to support feature operation, one of skill in the art will appreciate that the feature may be implemented using devices of various types and configurations, and having various components.

Figure 2 is a data flow diagram showing a typical data exchange between computer systems according to the feature. The computer systems shown in Figure 2 (computer systems 210, 220, 221, 222, 230, 231, and 232) typically have some or all of the components shown and discussed in conjunction with Figure 1. On the patch distribution server. , the feature generates one or more corrections. These patches 201 are sent from a patch distribution server to one or more administration servers, such as administration servers 220 and 230. Each administration server, on the other hand, sends the patches to one or more target computer systems, such as target computer systems 221, 222, 231, and 232. In some embodiments (not shown), the patch distribution server sends patches directly to one or more target computer systems, or via a more indirect route than through a single administration server. Corrections received on a target computer system are processed on a target computer system as described in more detail below. An administration server may also send patch configuration commands 202 to one or more target computer systems, which apply patch configuration commands to reconfigure the operation of particular patches. As discussed in more detail below, a fix can be completely disabled; If a fix is not disabled, notification of its operation and its test result handling can each be independently enabled or disabled. When notification of your operation is enabled, notifications can be viewed or stored locally on the target computer system, or can be sent as notifications to an appropriate administration server.

[0043] Figure 3 is a flow chart showing steps typically performed by the feature to receive and process a new correction. At step 301, the feature receives a fix. The correction received in step 301 can be either a triggered data correction or a triggered code correction. An exemplary correction of triggered data is shown in Table 1 below. 1 <Softpatch Patch = “Q382429”> 2 <AffectedApplication AffectedExe = “sqlservr.exe”> 3 <AffectedVersion Version = “9. *”> 4 <AffectedModules Name = “SQLSORT.DLL”> 5 <Version “8.0. *, 9. * ”> 6 <Function Name =“ SsrpEnumCore ”Address =“ 0x0802E76B ”7 Param =“ 2 ”Paramtype =“ LPSTR ”> 8 <Filter MaxByteLength =“ 60 ”/> 9 <Resolution ActionType =“ BOOL ”Action = “FALSE” /> 10 </Function> 11 </Version> 12 <Version “10. *, ll. *”> 13 <Function Name = “SsrpEnumCore” Address = “0x0802D283” 14 Param = “2” Paramtype = “ LPSTR ”> 15 <Filter MaxByteLength =“ 128 ”/> 16 <Resolution ActionType =“ BOOL ”Action =“ FALSE ”/> 17 </Function> 18 </Version> 19 </AfFectedModules> 20 </AffectedVersion> 21 < / AffectedApplication> 22 23 <Signature Hash = “MD5” Signature = “C509-64AA-9161-8C52-24 9F6D-BF5A-AEF2-ECEl-0038-34Dl” /> 25 </Softpatch> TABLE 1 [0044] The Line 1 contains a unique identifier for the correction. Line 2 identifies the application affected by the patch. Line 3 identifies the version of the application affected by the fix. Line 4 is the executable module affected by the fix. Line 5 identifies two versions of the affected executable module - versions 8.O. * and 9 * - for which correction directions are provided. Lines 6-10 contain correction directions for these two versions of the executable module. Lines 6-7 identify the function to be corrected, its address in the executable module, its parameter to be tested by the correction, and the type of parameter to be tested. Line 8 indicates that the parameter identified on lines 6-7 should be tested to determine if its length exceeds 60 bytes. Line 9 indicates that the function call should fail if the test succeeds. Line 12 identifies two more versions of the affected executable module - versions 10. * and 11. * - for which correction directions are provided. Lines 13-17 contain correction directions for these two versions of the executable module. Lines 13-14 identify the function to be corrected, its address in the executable module, its parameter to be tested by the correction, and the type of parameter to be tested. It can be seen that the address of the function to be corrected in the executable module identified on lines 13-14 for versions 10. * and 11. * is different from the address of the function to be corrected identified on lines 6-7 for versions 8. O. * and 9. *. Line 15 indicates that the parameter identified on lines 13-14 should be tested to determine if the length exceeds 128 bytes. Line 16 indicates that calling the function should fail if the test succeeds. The remediation can specify a variety of result-handling action types, including corrected function call failure, raising an exception, terminating the process in which the corrected executable module is running, or correcting the offending value (such as by truncating a very long series). Lines 23-25 contain a signature for the patch that both identifies the source of the patch and verifies that the patch has not changed since it left its source.

Table 2 below contains a triggered code version of the fix shown in Table 1 above. 1 00411A7E push 3Ch 2 00411A80 mov eax, dword ptr [str] 3 00411A83 push eax 4 00411A84 call ValidateStringLength (411082h) 5 00411A89 add esp, 8 7 00411A8F test ecx, jx 8 0011A foo + 2 (411 AD2h) 10 00411A9A xor eax, eax 11 00411A9C ret TABLE 2 [0046] Lines 1-3 push parameters to the test function on the stack. Line 4 calls the test function. Lines 5-8 branch the return code to the test function. If the test function succeeds, line 9 skips back to begin execution of the corrected function body. If the test function fails, lines 10-11 push a stack failure result code and return from the corrected function to color of the corrected function. For readability, Table 2 omits certain details present in some triggered code fixes, including a verifiable signature, instructions that test for the current values of the patch configuration flags, and instructions reallocated from the beginning of the code to the function. corrected.

In some embodiments, fixes of both types may contain additional information, including, for each or more versions of the executable module to be patched, a file signature that can be used to validate that a particular instance of the executable module is an appropriate copy of this version. Such a file signature can be, for example, a size or checksum for the entire executable module version, or code expected to occur at a particular point in the executable module, such as the offset at which the executable module is to be corrected.

At step 302, if the fix is signed with a valid signature, then the feature continues at step 303, also the feature continues at step 301 to receive the next fix. At step 303, the feature adds the fix to a local fix table. At step 304, the feature initializes the initial patch configuration, such as by sending it to a default configuration.

Figure 4 is a data structure diagram showing an exemplary patch table of those used by the feature. Correction table 400 contains rows, such as rows 401 and 402, each divided into the following columns: a correction identifier column 411, containing the correction identifier extracted from the correction; an executable module column 412 containing information identifying the executable module to be corrected, such as its name; a column of executable module versions 413 identifying all versions of the executable module identified in column 412 to which the fix applies; an enabled test performance column 414 containing the current configuration value for whether the test specified by the correction should be performed each time the corrected function is called; an enabled test performance notification column 415 containing the current configuration value for whether a notification should be generated each time the patch test is run; an enabled test result notification column 416 containing the current configuration value for whether notification should be generated each time the correction test succeeds; an enabled test result treatment column 417, containing the current configuration value for whether correction result treatment should be implemented when the correction test fails; and a correction column 418 that contains an indicator for the correction itself, specifying a test and test result treatment to be performed each time the test fails. In some embodiments, instead of containing an indicator for the correction as shown, the correction column 418 contains each correction directly. A particular patch table can contain or point to patches of various types, such as all triggered code fixes, all triggered data fixes, or a combination of triggered code fixes and triggered data fixes.

In step 305, once the feature has added the received fix to the fix table and initialized its settings, the fix is available to be automatically applied by the feature to the executable module. At step 305, the feature can use a variety of approximations to apply the fix, including those described in the embedded application by reference, as well as real-time function call interception, and / or rewrite code from (1) executable modules already loaded, (2) one or more executable module disk images, or (3) instances of executable modules loaded by the operating system loader. After step 305, the feature continues at step 301 to receive the next fix.

[0051] Figure 5 is a flowchart showing steps typically performed by the feature to update configuration instructions for a particular fix. At step 501, the feature receives configuration instructions for a particular fix, such as from an administrator. In some embodiments, such configuration instructions may be generated by administrators using group policies. At step 502, the feature updates the correction that is set in the correction table according to the instructions received. After step 502, the feature continues at step 501 to receive the next setup instructions.

[0052] Figure 6 is a flow diagram showing steps typically performed by the feature to perform parameter validation specified by the correction. At step 601, a corrected function is called. At step 602, if the test is enabled for the correction that affects the called function, then the feature continues at step 603, also the feature continues at step 601 to process the next call for a corrected function. At step 603, if test performance notification is enabled for remediation, then the feature continues at step 604, so the feature continues at step 605. At step 604, the feature generates a notification that the test has run. Steps 604, 608, and 610 may involve displaying and storing an indication on the target computer system that the test has been met, and / or transmitting such an indication to a remote computer system for viewing or connecting there.

At step 605, the feature runs the validation test specified by the fix. In some embodiments, step 605 involves calling one of a group of standard routines used by the test facility. At step 606, if the test performed at step 605 is satisfied, then the feature continues at step 601, also the feature continues at step 607. At step 607, if test result notification is enabled for correction, then the feature continues at step 608, the feature also continues at step 609. At step 608, the feature generates a notification that the test has not been met. At step 609, if test result handling is enabled for the fix, then the feature continues at step 610, so the feature continues at step 601. At step 601, the feature performs the test result handling specified by the fix. After step 601, the feature continues at step 601.

It will be appreciated by those skilled in the art that the feature described above can be directly adapted or extended in various ways. For example, the feature can be used to apply a variety of different patch types in a variety of ways to a variety of executable module locations of a variety of types for a variety of purposes. In addition, while fixes are described here as containing value validation tests that indicate a problem when they fail, the feature can also be implemented using value invalidity tests that indicate a problem when they succeed. In some modalities, each test is accompanied by an indication of whether its success or failure indicates a problem. While the foregoing description refers to preferred embodiments, the scope of the invention is defined solely by the following claims and the elements cited therein.

Claims (26)

Method in a computer system having a processor, nonvolatile memory and volatile memory, the method of applying a software patch to multiple instances of an executable module comprising: using an automated patching agent; receive the software patch; in response to receiving the software patch without user intervention: characterized by the fact that it further comprises: detecting, by the computing system, a first load that has transferred a first instance of an executable module to which the received software patch belongs to from nonvolatile memory to volatile memory; In response to first load detection, the computer system applies the software patch received on the first instance of the executable module to volatile memory to modify a portion of the first instance of the executable module, so that the behavior of the first instance of the module executable is modified; detect, by the computing system, a second load that has transferred a second instance of the executable module from nonvolatile memory to volatile memory; and in response to detection of the second load, the computer system applies the software patch received on the second instance of the executable module to volatile memory to modify a portion of the second instance of the executable module, so that the behavior of the second instance of the executable module. executable module to be modified. Method according to claim 1, characterized in that the executable module is an independently executable module. Method according to claim 1, characterized in that the executable module is a library. Method according to claim 1, characterized in that the executable module is a script. Method according to claim 1, characterized in that the executable module is a managed code module. Method according to claim 1, characterized in that the two software patches are received belonging to the same executable module, and both received software patches are applied to modify the behavior of the first executable module. Method according to claim 6, characterized in that the two patches received belong to different locations in the first instance of the executable module. Method according to claim 6, characterized in that the two patches received belong to the same locations in the first instance of the executable module. Method according to claim 8, characterized in that the patches received are applied such that both behavior modifications specified by the patches are displayed by the first corrected instance of the executable module. Method according to claim 8, characterized in that the received patches are applied such that only the behavior modification of a dominant of the two received software patches is displayed by the first instance of the executable module. Method according to claim 10, characterized in that the received dominant software patch contains an explicit indication that it is to master one or more software patches. Method according to claim 1, characterized in that the first instance of the executable module exhibits the modified behavior at a time after the received software patch is applied. Method according to claim 1, characterized in that it further comprises using the automated patching agent by applying the software patch received on a disk image to the executable module. Method according to claim 1, characterized in that the first instance of the executable module to which the software patch belongs is identified from a plurality of instances of the executable module to which the software patch belongs, and in which The received software patch is applied using module specific instance information for the first instance of the executable module contained in the received patch. A method according to claim 14, characterized in that the plurality of instances of the executable module is each a different version of the same executable module. Method according to claim 14, characterized in that the module-specific instance information for the first executable module instance contained in the received patch specifies an offset within the first identified executable module instance in which it modifies the behavior. of the first instance of the executable module. Method according to claim 16, characterized in that the module-specific instance information for the first instance of the executable module contained in the received patch still specifies the contents of the first instance of the executable module that is expected to occur. appear at a specified offset before the received software patch is applied. Method according to claim 1, characterized in that the received software patch contains code specifying how to modify the behavior of the first instance of the executable module. Method according to claim 1, characterized in that the received software patch contains data specifying how to modify the behavior of the first instance of the executable module. Method according to claim 1, characterized in that the received software patch specifies to modify the behavior of the first instance of the executable module to add a test and test result handling logic to a designated part of the first instance. of the executable module. Method according to claim 1, characterized in that the received software patch specifies to modify the behavior of the first instance of the executable module to add parameter validation functionality to a function assigned within the first instance of the executable module. Method according to claim 1, characterized in that the received software patch specifies to modify the behavior of the first instance of the executable module to add parameter validation functionality to a function assigned within the first instance of the executable module to identify a default parameter validation function that is to be called as part of the execution of the assigned function. Method according to claim 1, characterized in that the modified behavior of the first instance of the executable module can be enabled or disabled using a patch configuration interface. Method according to claim 1, characterized in that access to the modified behavior of the first instance of the executable module can be enabled or disabled using a patch configuration interface. A method according to claim 1, characterized in that the software patch is received by allowing the software patch to be copied to a predetermined location, and wherein the identification and application are performed automatically in response to the software patch being copied to the predetermined location. 26. Computer readable storage memory whose contents make a computing system a computing system having nonvolatile memory and volatile memory for performing a method of applying a software patch to a currently loaded executable module instance, comprising: using a automated patching agent; receive the software patch; in response to receiving the software patch, detecting by the computer system a first load that has transferred a first instance of an executable module to which the received software patch belongs from nonvolatile memory to volatile memory; characterized by the fact that it further comprises: in response to first load detection, the computer system applies the software patch received on the first instance of the executable module to volatile memory to modify a portion of the first instance of the executable module so as to that the behavior of the first instance of the executable module be modified; detect, by the computing system, a second load that has transferred a second instance of the executable module from nonvolatile memory to volatile memory; and in response to detection of the second load, the computer system applies the software patch received on the second instance of the executable module to volatile memory to modify a portion of the second instance of the executable module, so that the behavior of the second instance of the executable module. executable module to be modified.