WO2007092524A2 - Systèmes, procédés et supports servant à rétablir l'état d'éléments de données contrôlés dans une application - Google Patents

Systèmes, procédés et supports servant à rétablir l'état d'éléments de données contrôlés dans une application Download PDF

Info

Publication number
WO2007092524A2
WO2007092524A2 PCT/US2007/003308 US2007003308W WO2007092524A2 WO 2007092524 A2 WO2007092524 A2 WO 2007092524A2 US 2007003308 W US2007003308 W US 2007003308W WO 2007092524 A2 WO2007092524 A2 WO 2007092524A2
Authority
WO
WIPO (PCT)
Prior art keywords
procedure
state
repair
data item
valid
Prior art date
Application number
PCT/US2007/003308
Other languages
English (en)
Other versions
WO2007092524A3 (fr
Inventor
Angelos D. Keromytis
Michael E. Locasto
Original Assignee
The Trustees Of Columbia University In The City Of New York
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by The Trustees Of Columbia University In The City Of New York filed Critical The Trustees Of Columbia University In The City Of New York
Publication of WO2007092524A2 publication Critical patent/WO2007092524A2/fr
Publication of WO2007092524A3 publication Critical patent/WO2007092524A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/362—Software debugging
    • G06F11/366—Software debugging using diagnostics

Definitions

  • the disclosed subject matter relates to systems, methods, and media for repairing the state of constrained data items in an application.
  • FIG. 7 illustrates a function, "check_credentials" 720, that can determine access control rights for a client.
  • a login function 710 calls function 720, at 711, and stores the result in the variable authenticated 712.
  • authenticated 712 has a non zero value, the user is be granted access, at 713. If authenticated 712 has a value of zero, however, the user is denied access, at 714. If a fault occurs in the check_credentials function 720, a non-zero value may be inadvertently (or maliciously) returned, at 723, causing a possibly unauthorized user to gain access to a system. Furthermore, recovery systems, for example, systems that are blind to program semantics, may attempt to fix an error in function 720 by returning a non-zero error code, such as, for • example, a negative one. Such attempts at security can turn a denial of service attack against function 720 into a possibly much- more-dangerous valid login session.
  • the Clark- Wilson model discusses a data type called a Constrained Data Item (CDI) that can have a logical relation constraining its value range.
  • CDI Constrained Data Item
  • the Clark- Wilson model also discusses two procedures that can operate on a CDI. The first, a Transformation Procedure (TP), is a transaction that can transition a system from one valid state to another valid state. A TP can process sets of CDIs on behalf of a particular authenticated user. The second, an Integrity Validation Procedure (IVP), can be used to measure whether a CDI conforms to an integrity specification.
  • TP Transformation Procedure
  • IVP Integrity Validation Procedure
  • the Clark- Wilson model also includes a collection of nine rules that relate to enforcement (E) and certification (C) of users, IVPs, TPs, CDIs, and UDIs.
  • E enforcement
  • C certification
  • a system implementing the Clark- Wilson Model attempts to make sure these rules are complied with. For reference, the rules are summarized below:
  • TPs are certified valid.
  • the security officer specifies a "relation" which defines that execution.
  • a relation is of the form: (TPi, (CDI ? , CDI b , CDI C ,. .)) > where the list of CDIs defines a particular set of arguments for which the TP has been certified;
  • El The system maintains the list of relations specified in rule C2, and ensures that the only manipulation of any CDI is by a TP, where the TP is operating on the CDI as specified in some relation;
  • E2 The system maintains a list of relations of the form: (USERID, TPi, (CDI a , CDI b , CDI 0 ,...)), which relates a user, a TP, and the CDIs a TP can reference;
  • E3 (Authentication) The system authenticates the identity of each user attempting to execute a TP;
  • E4 (Separation of Duty) Only the agent permitted to certify entities can change the list of such entities associated with other entities: specifically, that associated with a TP. An agent that can certify an entity cannot have any execute rights with respect to that entity.
  • not all data is constrained like the GDIs of Clark-Wilson.
  • Such data e.g., from a user, an adversary, or the environment
  • UDI Unconstrained Data Item
  • a TP taking a UDI as an input can attempt to ensure that it transforms all possible values of a UDI to a CDI.
  • Many system vulnerabilities can arise from the operation of an incorrect TP on a UDI, or data derived from a UDI.
  • a TP typically moves the system from a valid state another valid state, it may fail for a number of reasons (e.g., incorrect specification, attack, hardware faults, software faults, etc.).
  • One reason for using an IVP is to detect and/or record a failure of an application to move between valid states.
  • the Clark-Wilson model does not address returning a system to a valid state or formalizing procedures that restore integrity.
  • methods for repairing the state of at least one constrained data item in an application include: executing a first procedure that alters the state of the at least one constrained data item, wherein the first procedure is executed in a supervision environment; determining whether the state of the at least one constrained data item is valid using a second procedure; if the state is not valid, attempting to repair the state using a third procedure; and determining whether the state is repaired using a fourth procedure, wherein the at least one constrained data item is associated with each of the first procedure, the second procedure, the third procedure, and the fourth procedure.
  • computer-readable media containing computer- executable instructions that, when executed by a processor, cause the processor to perform -methods for repairing the state of at least one constrained data item in an application.
  • the methods include: executing a first procedure that alters the state of the at least one constrained data item, wherein the first procedure is executed in a supervision environment; determining whether the state of the at least one constrained data item is valid using a second procedure; if the state is not valid, attempting to repair the state using a third procedure; and determining whether the state is repaired using a fourth procedure, wherein the at least one constrained data item is associated with each of the first procedure, the second procedure, the third procedure, and the fourth procedure.
  • systems for repairing the state of at least one constrained data item in an application including an interface in communication with a network; a memory; and a processor in communication with the memory and the interface; wherein the processor executes a first procedure that alters the state of the at least one constrained data item, wherein the first procedure is executed in a supervision environment; determines whether the state of the at least one constrained data item is valid using a second procedure; if the state is not valid, attempts to repair the state using a third procedure; and determines whether the state is repaired using a fourth procedure, wherein the at least one constrained data item is associated with each of the first procedure, the second procedure, the third procedure, and the fourth procedure.
  • FIG. 1 is a simplified illustration of a method for repairing the state of an application in accordance with some embodiments of the disclosed subject matter.
  • FIG. 2 is a simplified illustration of a method for repairing the state of an application by various entities in accordance with some embodiments of the disclosed subject matter.
  • FIG. 3 is an illustration of code defining a correcting assert context in accordance with some embodiments of the disclosed subject matter.
  • FIG. 4 is an illustration of code for building a correcting assert in accordance with some embodiments of the disclosed subject matter.
  • FIG. 5 is a simplified illustration of a method for repairing the state of an application in accordance with some embodiments of the disclosed subject matter.
  • FIG. 6 is an illustration of code for repairing the state of an application in accordance with some embodiments of the disclosed subject matter.
  • FIG. 7 is an illustration of code for authenticating a user that can be protected in accordance with some embodiments of the disclosed subject matter.
  • Some embodiments of the disclosed subject matter can detect and/or repair software faults.
  • program state can be, for example, returned to a previous state, returned to a known valid state, ignored, and/or reported.
  • system state changes it can be determined if the new state is valid. If the new state is not valid, the state can be repaired and the repair can be validated.
  • forensic information can be provided in order to, for example, avoid or inhibit faults and/or to recover execution after a fault.
  • FIG. 1 A method for repairing the state of an application in accordance with some embodiments is illustrated in FIG. 1. As shown, during the execution of a program, the program's state can change, at 110. These changes may be, for example, the result of normal program execution or the result of a fault. The method can then determine whether a change of state was valid, at 120. If the change of state was valid, the program can continue, at 150. However, if the change was not valid, an attempt to repair the state can be performed, at 130. It can be determined whether the repair was successful, at 140.
  • a test to determine whether a repair was successful can include, for example, one or more tests of whether the state of the application is valid, whether the state is the most appropriate state, whether the state is included in a list of states, and/or whether the state is equal to the state before the fault. If the repair was successful, the program can resume execution, at 150. If not, other actions can be taken, at 160, such as, for example, further attempts at repair, or termination of program execution.
  • Some embodiments can enforce a separation of duty among various tasks. For example, in some embodiments, policy specification can be separate from policy enforcement. As a further example, some attacks may alter program state before being detected and, if an integrity repair system is intertwined with a system being protected, the repair system itself may be damaged or corrupted. Accordingly, some embodiments, as illustrated and discussed in connection with FIG. 2, can reduce and/or eliminate the effects of an attack on one part of a system from affecting other parts of the system, the repair model, and/or the attack prevention and/or repair system.
  • FIG. 2 illustrates a protected program 210 and a monitor and repair system 220, which can include, for example, a monitor 221 to monitor the program 210, and a repair system 222 to repair the program 210 if a fault is detected.
  • a fault may occur, at 231. This fault can be detected by monitor 221, at 232.
  • the monitor 221 can be run, for example, by a system administrator or system security officer.
  • a first user 223 can be alerted of the fault, and can attempt to repair the fault, at 233.
  • a second user, 224 can validate, at 234, that the repair was appropriately performed and the program 210 can return to normal execution, at 235.
  • the responsibility of monitoring, repairing, and validating the repair can be spread among various entities (e.g., users, administrator, applications, systems, etc.) such that if any one user is compromised, or otherwise at fault, the fault can be inhibited from spreading.
  • entities e.g., users, administrator, applications, systems, etc.
  • the second user 224 can determine, at 234, that the repair, at 233, was not appropriate.
  • the first and/or second user can be actual users, or, for example systems and/or applications.
  • the first user 223 can be an application repair program.
  • the provided repairs can be considered temporary constraints on program behavior and/or emergency fixes that await a traditional and/or a permanent patch from the vendor. Some embodiments can alert, for example, a user, or system manager, of the fault so that a fix or patch can be applied to the system.
  • the repairs offered by the disclosed subject matter can be considered, and relied on, as the final and/or long-term solution to a fault, a series of faults, and/or repetitions of the same fault.
  • some embodiments can change the semantics of, for example, an assert statement (i.e., a statement that causes an application to terminate if a given condition is false). For example, if the condition in an assert fails, some embodiments can adjust the values of the relevant program state to be in a condition that makes the asserted expression true.
  • an assert statement i.e., a statement that causes an application to terminate if a given condition is false.
  • some embodiments can adjust the values of the relevant program state to be in a condition that makes the asserted expression true.
  • a number of reaction strategies are possible.
  • some embodiments can fix the fault (e.g., repair and/or adjust the expression variables), return (e.g., return from a function with an error code), break (e.g., break from the current scope), and/or continue (e.g., ignore the error and move on).
  • additional strategies can be defined, for example, by defining repair code and linking it with program constraints.
  • Some embodiments can create named assertions which can be referred to as correcting assert contexts ("cassert contexts").
  • FIG. 3 illustrates an example of a cassert context, at 310.
  • this cassert context can compare two variables (i.e., "_a__” and "_b_”)-
  • the reaction strategy set, at 312, is to fix the condition if it fails.
  • An instance of the cassert context is declared, at 320, and variables "a" and "b” are declared, at 321.
  • "a,” with a value of 7, is greater than "b,” with a value of 2.
  • a traditional assert, testing the condition "a ⁇ b,” as at 334 would fail and cause a program to terminate.
  • the assert, at 334 can succeed because the condition and program state can be fixed, at 333.
  • FIG. 4 illustrates two examples of building casserts and a corresponding expression according to some embodiments of the disclosed subject matter, such as, for example, the expression "a ⁇ b.”
  • some embodiments can build an expression by passing the expression as a string, at 410.
  • Some embodiments can build an expression by calling a series of functions that define various parts of the expression, as illustrated starting at 420.
  • An expression can be executed with a repair strategy by, for example, calling the correcting assert, at 430. Some embodiments can also call the traditional assert, at 440 or 450, which would succeed if the assert expression corrected at 430. [0028J Some embodiments can provide a recovery model as part of a formal model of integrity repair. This model can, for example, interact with parts of the Clark-Wilson model. Policies can be generated to solve various constraints and provide manual and/or automatic policy creation.
  • transformation procedures TPs
  • TPs can be implemented as functions that operate on data structures. TPs can be, for example, micr- ooperations, instructions, basic blocks, functions, modules, etc.
  • integrity validation procedures IVPs
  • Some embodiments can provide procedures, and policy members to repair a system after a fault, such as, for example, repair procedures (RP) and repair validation procedures (RVP). Some embodiments can use these procedures to create a recovery policy that can, for example, specify how to return a system to a valid state. For example, some embodiments can describe what changes to a system must occur for a set of IVPs to measure a set of CDIs and return "valid.”
  • RP repair procedures
  • RVP repair validation procedures
  • a Constrained Data Item can include, for example, various data items within a system to which a repair and/or integrity model can be applied.
  • Constrained Data Items can include the value of a variable or set of variables, the contents of a data structure, the state of an application, the state of part of an application, the state of a group of applications, the state of part of a group of applications, the return value of a function, a stack-resident return address, and/or one or more relationships among variables and/or data items, etc.
  • Some embodiments provide integrity repair model rules that can supply repair and repair validation procedures. These rules are only examples. Additional rules and/or . variations on these rules can additionally or alternatively be used in various embodiments.
  • C6 RPs and RVPs are certified to be valid. For RPs, certification indicates that it returns a given set of CDIs to a valid state. For RVPs, certification can mirror that of rule Cl. For each RP and RVP and each set of CDI that they can manipulate, the security officer specifies a "relation" which defines that execution. A relation is of the form: (RPi V RVPi, (CDI 3 , CDI b , CDIc, (7)), where the list of CDIs defines a particular set of arguments for which the RP or RVP has been certified.
  • E5 The system maintains a list of relations of the form: (USERlD, RPi, (CDI 3 , CD I b , CDI c ,...)) which relates a user, an RP, and the CDIs that the RP can adjust back to a satisfactory value assignment.
  • E6 The system maintains a list of relations of the form: (USERID, RVPi, (CDI 3 , CDI b , CDI 0 ,...)) which relates a user, a RVP, and the CDIs that the RVP can measure to make sure they have a satisfactory value assignment.
  • E5 and E6 The list of relations in E5 and E6 is certified to meet the separation of duty requirements.
  • an RVP can be implemented and certified by a user, other than the user that certified the corresponding IVP and RP. This separation of duty can be useful if, for example, either of these procedures is maliciously and/or incorrectly certified.
  • this rule can be combined with rule C3 of Clark- Wilson.
  • the repair procedures and repair validation procedures can be used in various ways. For example, an embodiment of the application repair procedures and repair validation procedures is illustrated in FIG. 5. As shown, a TP can first change the state of a CDI, at 510. An IVP can then determine whether the change of state was valid, at 520. If the change of state was valid, the program can continue, at 550. However, if the change was not valid, an RP can attempt to repair the state, at 530. The RP that performs the repair can be selected, for example, based on which CDI has been determined to have an invalid state and/or based on a return value from the IVP, at 520. An RVP can determine whether the repair was successful, at 540. If the repair was successful, the program can resume execution, at 550. If not, other actions can be taken, at 560, such as, for example, further attempts at repair, or termination of program execution.
  • FIG. 6 illustrates a sample inline reference monitor 600 that can be passed a TP 601 and a set of constrained data items 602 on which the TP 601 can operate.
  • the monitor 600 can access, at 603, an IVP 604 that can determine, at 605, whether the CDIs 602 are in a valid state after TP 601 operates on them. If the state or states are valid, the monitor 600, can return, at 606, and normal execution can continue. However, if a state is not valid, the monitor 600 can access an RP 607, at 608, and a RVP 609, at 610, and attempt to repair the set of CDIs 602, at 61 1.
  • the monitor 600 can determine, at 612, using RVP 609, whether the set of constrained data items 602 was appropriately repaired. If the repair is validated, the monitor 600, can return, at 606, and normal execution can continue. However, if the repair is not validated, the monitor can take other action, such as, aborting the program, at 613.
  • variables such as "authenticated,” “uname,” and “cred_OK” can be CDIs.
  • the "login,” “strcpy,” and “check_credentials” functions can be TPs. Because manipulation of uname can overwrite a stack return address, any standard detection mechanism for this type of exploit can serve as an IVP for uname.
  • an RP can set an appropriate value (e.g., FALSE or reject) for the CDIs authenticated and cred_OK.
  • an RVP can be invoked to test the results of this repair.
  • the RP can help ensure that the value of the CDIs are not merely set to a satisfying or legal value, but rather to an appropriate value (possibly, the most-appropriate) based on system state (e.g., the current system state, a desired system state, etc.).
  • Some embodiments do not constrain a relationship between RPs and TPs. Instead there can be an indirect mapping between an RP and a TP through CDIs that the RP and TP are associated with. Accordingly, in some embodiments, an implementation choice can be made as to for which TPs an IVP and/or RP should be invoked.
  • an IVP can be a stack canary that measures the integrity of the stack return address. If the IVP detects an inappropriate value for the canary, various RPs can be called to address the situation. Repair actions can include, for example, resetting the canary to its old value, setting the canary to the jump address of an exception handler, setting the canary to zero, etc.
  • Repair actions can also include repairing CDIs other than a CDI for which a fault was detected.
  • such repairs can repair structures other than the canary, such as, for example, a local variable, a memory artifact on the stack, the heap, or even a value inside another processor's address space.
  • Some embodiments can offer a range of options regarding when and/or if to monitor various TPs. Strategies can range from random selection to full coverage (e.g., invoking an IVP after each TP). Other enforcement choices can include, for example, selection based on proximity of a TP to input handling routines or the error history of a TP and/or the protected application. RVPs can also be associated with a set of CDIs and can check the validity of CDIs after an application of an RP.
  • Some embodiments of the disclosed subject matter can include lists of relations that constrain the values of CDIs.
  • the constraining relation on a CDI can be arbitrarily complex.
  • Constraints can be expressed in various ways, for example, as Boolean formulas or as Turing Machine descriptions. Some embodiments may consider only Boolean formulas because, for example, they are typically powerful enough to express data structure constraints. Some embodiments support manual synthesis and certification of repair procedures, such as, for example, the repair procedures for the Boolean formulas. Alternatively or additionally, automatic synthesis of RPs from Boolean-expression IVPs can be provided.
  • an IVP can provide a Boolean condition that can be violated, and self-healing can be accomplished by finding a satisfiable assignment for that Boolean condition, possibly in addition to other recovery actions (e.g., user and/or administrator specified). Accordingly, synthesizing a list of recovery procedures from the list of constraints on each IVP can be achievable.
  • Boolean formulas contain atoms that can be, for example, unary, binary, or ternary operators and their operands, which can include, for example, function calls. Atoms can express, for example, logical, relational, or arithmetic operations. Many software applications do not use complicated expressions, thus the time for determining a satisfiable assignment of values to expression atoms may be relatively short. Finding appropriate values for atoms can be driven by the definition of the constraints on the relevant constrained data items. In finding these values, some embodiments of the disclosed subject matter can follow heuristics while some embodiments, where, for example, the repair procedure is manually specified, can follow human and/or external advice.
  • Some embodiments can use a managed runtime platform, such as, for example, Java Virtual Machine bytecode or a pure binary platform, such as, for example, x86 machine code.
  • Policy specification and enforcement code can be inserted into program binaries to avoid, for example, inserting calls to policy routines in the protected application and/or having to recompile the protected application.
  • Binary code injection can be done, for example, by using a Java implementation and the BCEL4 Java bytecode parsing library and the Java Instrumentation Framework introduced in Java 5.
  • Binary code injection can also be done using x86 machine code with, for example, the PIN dynamic binary rewriting platform.
  • BCEL4 the Java Instrumentation Framework, and the PIN dynamic library are merely examples.
  • the repair algorithm and/or repair code can be manually specified, for example, by a system administrator, user, or the author of the protected application.
  • the repair algorithm and/or repair code can be automatically supplied by, for example, calls to a library inserted by a programmer and/or compiler. Any appropriate language and/or architecture can be used, such as, for example, xS6, PowerPC, C/C++/C#, Perl, and/or Java byte-code.
  • mapping constraints to source-level objects assists in maintaining application semantics.
  • debug information can be retrieved from a program binary and this debug information can be used to map machine- level constructs (e.g., registers, memory, and machine instructions) to source-level names for data-types and/or variables. These source-level names can then be used by some embodiments to, for example, monitor and/or alter the values of parts of an application and/or GDIs.
  • machine- level constructs e.g., registers, memory, and machine instructions
  • An additional stage of compilation that uses a source code transformer, such as, for example, ANother Tool for Language Recognition (Antl), available from antlr.org can be added.
  • the additional stage of compilation can transform the source code of an application at locations where monitor and/or repair code is to be added. For example, it can be used to transform traditional asserts to casserts.
  • flags for enabling and disabling the operation of various embodiments can be provided. These flags can be controlled by a user, or, for example, driven by events such as alerts from a network intrusion detection system or a host- based monitor that can identify potentially vulnerable portions of execution. In this way, the monitor and/or repair systems can be turned on and off during execution.
  • Default repair policies can be written and distributed, for example, by application vendors, stakeholders, and/or competitors. A user can be presented with a menu option that presents recommended actions along with other, possibly more risky, repair behaviors (e.g., a repair choice may be the most comprehensive, but if some memory areas have been corrupted, it may only succeed with, for example, a 45% chance).
  • Some embodiments can use a repair quality scale as measured by repair validation procedures.
  • An RVP can return an indication of repair quality so that the strength of the repair can be determined by other systems. For example, if a constraint satisfaction procedure is stopped short of completion because it is taking too much time, it may return a solution to a constraint that is not the best it could have returned had it completed running. By providing an indication that a constraint satisfaction procedure was cut short, it can be known that a repair may not have been the best repair available.
  • Some embodiments of the disclosed subject matter can be used to repair faults in software such as, for example, Firefox 1.5.
  • Speculation program execution can be, for example, executing at least a portion of the program in a supervision environment, such as, for example, a protected environment, a sandbox, an emulator, a simulator,, a virtual environment, etc.
  • This execution can be done, for example, before that portion of the program would normally be executed, instead of executing that portion of the program, or with capability to roll back execution after execution of that portion of the program) to, for example, inhibit the condition in a traditional assert statement from executing and possibly altering program state.
  • a TP at 510 of FIG. 5
  • an IVP at 520
  • an RP at 530
  • an RVP at 540
  • an expression can be corrected before it reaches the traditional assert or other program boundary and can allow the traditional assert or boundary to retain its operational semantics.
  • calls to a traditional assert macro can evaluate an expression.
  • the assert itself only checks the final value of this expression.
  • an expression execution can be speculatively executed (e.g., by a TP, at 510) and side effects that may arise can be undone. This can be done, for example, by executing in a sandbox when an instrumented assert context is evaluated. If the expression in the assert fails, recovery actions can take place and side effects resulting from the expression can be undone. If the expression succeeds,- any new state generated by the execution of execution and/or TP can be, for example, transferred to the application.
  • Some embodiments can evaluate a program expression at runtime, run a satisfiability algorithm to adjust program state, and correct an expression (e.g., from a programmer inserted assert) if the expression is not satisfied.
  • a satisfiability algorithm can use brute force generation to generate a truth table for the expression.
  • a set of satisfiable assignments can be collected from the truth table and one of the sets can be selected. The selected set of assignments can be selected using various methods, for example, the set of satisfiable assignments producing the value closest to the current value of the expression can be selected.
  • Some embodiments can obtain the atoms making up the expression, run a satisfiability algorithm, and adjust the values of the atoms so that the expression can satisfy its condition.
  • the atoms of the expression can be captured and stored in a data structure capable of storing and describing program expressions. This data structure can be generated and populated by, for example, the programmer, an administrator, a user, and/or a compiler.
  • a pre-processing phase can parse the expression (e.g., the expression passed to an assert) and can store relevant information. Alternatively, this pre-processing can be done manually.
  • the treatment of the atoms and/or the expression can be adjusted depending on, for example, the type of atoms and/or operands in the expression.
  • atom operands include function calls
  • some embodiments can checkpoint program state and can return the program to the saved state if a fault occurs.
  • Valid values for atom operands can be learned by, for example, observing previous executions of the programs instance, past program instances, or remote instances (e.g., input from an application community).
  • the locations in an application to insert function calls to various embodiments of the disclosed subject matter can be determined using various techniques.
  • the technique selected can range from complete instrumentation to selective, retroactive insertion. In some cases, this range reflects a tradeoff between the level of protection for a system and the impact on system performance caused by that protection.
  • IVP invocation can occur, for example, after every machine instruction, after every basic block, after some specific class of machine instructions (e.g., control-flow transfer, arithmetic, logic, floating point, etc.), etc. Policy checks can also be inserted at locations at higher levels of abstraction.
  • the Java policy access control mechanism can rely on calls to Java's access controller (part of Java that can deny access to various portions of code and/or application programming interface) being interwoven with the standard classes of the Java library.
  • Java's access controller part of Java that can deny access to various portions of code and/or application programming interface
  • a flexible insertion approach can be used where, for example, only the TP specified in the policy is instrumented with calls to its appropriate IVP.
  • Some embodiments can insert calls to an inline reference monitor at, for example, asserts and/or boundaries (e.g., function exits, function entry, jumps, conditionals, etc.).
  • a reference monitor can assess the state of an application with respect to policy, and can repair that state (e.g., invoke appropriate RPs and RVPs) if the policy is violated (e.g., if an IVP returns "invalid").
  • calls to reference monitors such as, for example, that illustrated in FIG. 6, or calls to correcting asserts, such as, for example, the call 333 of FIG. 3 can be inserted at various locations in an application's execution.
  • the values of IVPs, RPs, and/or RVPs can be dynamically determined, for example, by the instrumentation engine from the policy.
  • a policy can be specified as, for example, an XML file or as a flat file, depending on the architecture, and can contain CDI definitions and lists of relations such as those specified, for example, in Rules E2, E5, and E6. IfIVPs, RPs, and/or RVPs are not already part of the codebase, they can be dynamically inserted. In some embodiments, existing application code can be used to provide RPs rather than synthesizing them from the corresponding IVPs.
  • Some embodiments can respond to and repair TPs containing both known and unknown vulnerabilities.
  • the collection of TPs can be specified manually or automatically.
  • Manual specification e.g., by program authors, system administrators, and/or end-users, etc.
  • Automatically identifying transformation procedures can be orders of magnitude faster, especially if a TP is identified in response to an exploit attempt.
  • An automatic process may need some initial classification or training, but, as with static analysis that identifies vulnerabilities in the first place, still lacks completeness.
  • a system can synthesize fingerprints code sequences at these points and identify other locations in the program that match the fingerprint. These locations can be candidates for instrumentation.
  • the enforcement mechanism can remember a snapshot of the application environment when attacks occur and can use that snapshot for examination by a detection mechanism, such as an IVP. Some embodiments can learn when conditions are ripe for an attack and the re-creation of those conditions can trigger an enforcement mechanism.

Abstract

L'invention concerne des systèmes, des procédés et des supports servant à rétablir l'état d'éléments de données contrôlés dans une application. Dans quelques modes de réalisation, des procédés destinés à rétablir l'état d'un élément de données contrôlé dans une application consistent à: exécuter, dans un environnement de surveillance, une première procédure modifiant l'état du ou des éléments de données contrôlés; déterminer par une deuxième procédure si l'état du ou des éléments de données contrôlés est valable; si l'état n'est pas valable, essayer de le rétablir par une troisième procédure; et déterminer par une quatrième procédure si l'état est rétabli, ledit ou lesdits éléments de données contrôlés étant associé(s) à chacune desdites première, deuxième, troisième et quatrième procédures.
PCT/US2007/003308 2006-02-07 2007-02-07 Systèmes, procédés et supports servant à rétablir l'état d'éléments de données contrôlés dans une application WO2007092524A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US76599706P 2006-02-07 2006-02-07
US60/765,997 2006-02-07

Publications (2)

Publication Number Publication Date
WO2007092524A2 true WO2007092524A2 (fr) 2007-08-16
WO2007092524A3 WO2007092524A3 (fr) 2008-08-28

Family

ID=38345786

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2007/003308 WO2007092524A2 (fr) 2006-02-07 2007-02-07 Systèmes, procédés et supports servant à rétablir l'état d'éléments de données contrôlés dans une application

Country Status (1)

Country Link
WO (1) WO2007092524A2 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8924782B2 (en) 2007-01-26 2014-12-30 The Trustees Of Columbia University In The City Of New York Systems, methods, and media for recovering an application from a fault or attack
US20160378987A1 (en) * 2015-06-29 2016-12-29 International Business Machines Corporation Self-repair and distributed-repair of applications
US10761970B2 (en) 2017-10-20 2020-09-01 International Business Machines Corporation Computerized method and systems for performing deferred safety check operations

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040153823A1 (en) * 2003-01-17 2004-08-05 Zubair Ansari System and method for active diagnosis and self healing of software systems
US20050086562A1 (en) * 2003-10-21 2005-04-21 Demsky Brian C. Specification based detection and repair of errors in data structures

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040153823A1 (en) * 2003-01-17 2004-08-05 Zubair Ansari System and method for active diagnosis and self healing of software systems
US20050086562A1 (en) * 2003-10-21 2005-04-21 Demsky Brian C. Specification based detection and repair of errors in data structures

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8924782B2 (en) 2007-01-26 2014-12-30 The Trustees Of Columbia University In The City Of New York Systems, methods, and media for recovering an application from a fault or attack
US9218254B2 (en) 2007-01-26 2015-12-22 The Trustees Of Columbia University In The City Of New York Systems, methods, and media for recovering an application from a fault or attack
US20160378987A1 (en) * 2015-06-29 2016-12-29 International Business Machines Corporation Self-repair and distributed-repair of applications
US9684788B2 (en) * 2015-06-29 2017-06-20 International Business Machines Corporation Self-repair and distributed-repair of applications
US10761970B2 (en) 2017-10-20 2020-09-01 International Business Machines Corporation Computerized method and systems for performing deferred safety check operations

Also Published As

Publication number Publication date
WO2007092524A3 (fr) 2008-08-28

Similar Documents

Publication Publication Date Title
Cheng et al. Orpheus: Enforcing cyber-physical execution semantics to defend against data-oriented attacks
US9218254B2 (en) Systems, methods, and media for recovering an application from a fault or attack
Huang et al. Securing web application code by static analysis and runtime protection
Kruegel et al. Automating mimicry attacks using static binary analysis
Sekar et al. On preventing intrusions by process behavior monitoring
Schoepe et al. Explicit secrecy: A policy for taint tracking
Altekar et al. OPUS: Online Patches and Updates for Security.
US7437718B2 (en) Reviewing the security of trusted software components
Sekar et al. Model-Carrying Code (MCC) a new paradigm for mobile-code security
US20060129880A1 (en) Method and system for injecting faults into a software application
Gauthier et al. Fast detection of access control vulnerabilities in php applications
Ernst et al. Boolean formulas for the static identification of injection attacks in Java
Kupsch et al. Manual vs. automated vulnerability assessment: A case study
Homaei et al. Athena: A framework to automatically generate security test oracle via extracting policies from source code and intended software behaviour
Hawkins et al. BlackBox: Lightweight security monitoring for COTS binaries
CN113779578A (zh) 移动端应用的智能混淆方法和系统
WO2007092524A2 (fr) Systèmes, procédés et supports servant à rétablir l'état d'éléments de données contrôlés dans une application
Laranjeiro et al. A learning-based approach to secure web services from SQL/XPath Injection attacks
Bond et al. Efficient, context-sensitive detection of real-world semantic attacks
Thober et al. Jmf: Java measurement framework: Language-supported runtime integrity measurement
Jones et al. Enforcing IRM security policies: Two case studies
Dharsee et al. A software solution for hardware vulnerabilities
Abbadini et al. Lightweight cloud application sandboxing
Malek et al. Security and software engineering
Inoue et al. Inferring Java Security Policies Through Dynamic Sandboxing.

Legal Events

Date Code Title Description
NENP Non-entry into the national phase in:

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 07763590

Country of ref document: EP

Kind code of ref document: A2