• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    the present invention relates to a computer processing node that is configured to perform a flow control integrity (cfi) method in a protected process that operates at the processing node. the cfi method includes intercepting a system call that originated from the execution of the protected process running in the runtime environment. a fast path that operates within a computer system kernel accesses, from a kernel memory, a processor tracking package that corresponds to the system call. the fast path attempts to match the processor tracking package to a control program flow (edge) entry within a control flow chart definition with a credit label (cfg) having an associated credit value . the credit value represents a degree to which the control program flow is reliable. subsequently, the method additionally includes conditionally invoking, after correspondence, a slow packet for further processing of the processor tracking packet if the associated credit value does not meet a specified threshold, and otherwise provide an indication for allow the system call to run.
    公开号:BR112019016151A2
    申请号:R112019016151-1
    申请日:2018-02-03
    公开日:2020-03-24
    发明作者:Liu Yutao；Chen Haibo；Shi Peitão；Wang Xinran
    申请人:Huawei Technologies Co., Ltd.；
    IPC主号:
    专利说明:

    Descriptive Report of the Invention Patent for APPLICATION BASED ON TRACKING THE CONTROL FLOW INTEGRITY PROCESSOR OF A COMPUTER SYSTEM.
    Cross Reference to Related Orders [0001] This order claims benefits to US N Q interim order. 62 / 455,523, filed on February 6, 2017 and to US Order N Q. 15 / 887,468, filed on February 2, 2018, which are expressly incorporated herein by reference in their entirety, including any references contained therein. Patent Application Field [0002] This patent application generally relates to the field of real-time / online cyber defense systems embedded in computer systems. More particularly, the patent application is directed to a computer system that includes flow control integrity monitoring (CFI) capability that is based on online analysis of a processor tracking output provided by a processor tracking functionality implemented by hardware (for example, Intel Processor Tracking).
    Background [0003] A wide variety of cyber defense approaches have been implemented to combat cyber attacks. In response to cyber defenses aimed at preventing code injection, cyber attackers adapted their approach to exploiting / reusing existing program code. Rather than adding new code to programs, attackers use existing code unintentionally through sophisticated call sequences. For example, return-oriented programming and its variants exploit weaknesses in existing program code through execution
    Petition 870190087026, of 9/5/2019, p. 4/54
    2/38 arbitrary existing code. Control flow integrity (CFI) has emerged as a tool / property that uses the known / established control flow pattern of calls between computer code modules to identify and combat cyber attacks based on code reuse, recognizing / rejecting attempts to perform an irregular control flow between computer code modules.
    [0004] Control flow integrity is not a new concept for cyber defense developers. However, the adoption of CFI-based cyber defenses has been hampered by the high overhead of computing resources generally associated with the realization of CFI-based cyber defenses. The high overhead and associated performance degradation make this approach impractical in an online / real-time processing environment. In order to make CFI-based cyber defense capabilities effective in an active processing environment, it was believed that there should be a balance between: accuracy (that is, the application needs to be sufficiently granular to eliminate the largest possible attack surface) ; efficiency (that is, the imposed runtime overhead should be small and transparency (that is, the approach should be transparent to applications, easily deployable on existing operating systems and hardware, and generally compatible with existing security mechanisms).
    [0005] The realization of CFI through hardware-based processor traces is seen as having significant promise. Several hardware flow control tracking mechanisms exist today. Each form of hardware-based CFI implementations represents a different set of tradeoffs between accuracy, tracking overhead,
    Petition 870190087026, of 9/5/2019, p. 5/54
    3/38 coding, and filtering mechanisms available. A CFI implementation of the Branch Trace Store (BTS) captures each transfer of control event (for example, call, return and all types of hops) as a separate registration instance in a memory-resident BTS buffer. Each resulting record contains the addresses of a source and a destination for the branching instruction. Thus, there is no need to decode the records. However, BTS has a very high processing overhead during tracking and is inflexible due to the lack of event filtering mechanisms. A CFI implementation of the Last Branch Record (LBR) supports event filtering (for example, filtering conditional branches). However, LBR records only 16 or 32 pairs of more recent branches (source and destination) in a record stack. Although LBR incurs very low tracking overhead, it can hardly provide accurate protection due to the limited history of branch pairs available for analysis at any point in time [0006] Due to its ability to dynamically track flow of control, BTS and LBR can support counterattack defenses similar to Return Oriented Programming. However, BTS and LBR require a trade-off between incurring high overheads (eg, BTS) or sacrificing a resulting level of security due to inaccurate layout (eg, LBR).
    [0007] INTEL introduced the processor tracking capabilities on INTEL's Intel Core M and 5- generation processors. Each of these processors includes CPU cores with their own IPT hardware that generates tracking information for programs running in the form of packets. The processor trace configuration operation is limited to privileged agents (for example, the operating system) using certain MSRs (model-specific registers). The tracked packets are written to the memory buffer
    Petition 870190087026, of 9/5/2019, p. 6/54
    4/38 preconfigured in a compressed format to minimize output bandwidth and reduce tracking overhead. A software decoder decodes processor tracking packages based on a predefined format. A control agent provides extra information, including program binaries and some runtime data, to accurately reconstruct the program flow. Aggressive tracking compression makes it easier to collect more control flow tracking information, including: control flow, execution modes and intervals - all while there is far less tracking overhead than BTS. However, the high degree of encoding incurs a cost in the form of orders of magnitude of decoding speed slower than screening.
    [0008] With reference to Table 1 below, an example of a set of 9 execution control flows (Execution Flow) and corresponding IPT tracking packages (if registered) are provided.
    N s . Execution flow Tracked packages 1 0x8fa jg 0x8fe // obtained TNT (1) 2 0x9fe jmpg *% rax //% rax = 0x905 TIP (0x905) 3 0x905 callq fun14 0x90a mov -0x18 (% rbp),% rax fun1:5 0x940 ...6 0x970 cmp% rax,% rax7 0x974 jc 0x983 // not obtained TNT (0) 8 0x979 jmpq 0xe109 0xe10 leaveq; retq TIP (0x90a) TABLE 1
    Petition 870190087026, of 9/5/2019, p. 7/54
    5/38 [0009] In the above example of Processor trace generation based on IPT, a processor trace package is only registered when a change of control flow that is not statically known (for example, conditional) occurs. Processor trace packets are not recorded when a processor performs a non-conditional forward branch. See Table 1, execution control flows 3 and 8. In the case of a registered conditional tracking package, the branch is compressed to a single bit that identifies whether the condition has been reached which resulted in the conditional branch flow being obtained. See Table 1, execution control flows 1 (branch obtained) and 7 (branch not obtained). Another flow of control will generate the target addresses for branches, exceptions and indirect interruptions. See Table 1, execution control flows 2 and 9 (TIP packets). In another example of control flow processor tracking packages are recorded which contain the source addresses for asynchronous event execution control flows (for example, FUP tracking packages).
    [0010] Table 2, provided below, lists the types of change of flow instructions (CoFI) corresponding to the processor tracking output provided by IPT.
    CoFi Type Scenarios Output Direct unconditional branching JMP and CALL (direct) No exit Conditional branching Jcc, J * CXZ, LOOP TNT Indirect branching JMP and CALL (indirect)Next Ret RET TIP Distant transfers Interruptions, catches, etc. TIP / FUP
    Table 2
    Petition 870190087026, of 9/5/2019, p. 8/54
    6/38 [0011] Using the processor tracking packet generation rules based on IPT, there is less than 1 bit of information recorded for each average reformed instruction. In addition, the IPT outbound logging configuration scheme supports event filtering based on the current privilege level (CPL). For example, log generation can be configured using a CR3 value, which represents the base record of the page directory, or certain variations of the instruction pointer (IP) - both of which can be used to pre-filter (and discard) ) processor tracking packages.
    [0012] The relatively fast processor tracking generation mechanism provided by IPT has a higher cost associated with decoding registered processor tracking packages. The highly coded (but compact) processor tracking packages processed by IPT are incomplete. Therefore, a decoder of processor tracking packages, during decoding, associates the registered processor packages with the corresponding binaries when it is desired / necessary to reconstruct the program flow that resulted in a processor tracking package (problematic). For example, when rebuilding a processor tracking package execution control flow, an implementation of an IPT decoder library uses the abstraction instruction flow layer, which analyzes the program's binary instruction by instruction and combines the packets tracked with the analyzed binary instructions for the entire decoding.
    [0013] The INTEL processor tracking package generation mechanism exhibits several beneficial features, including: accurate tracking, low tracking overhead and filtering
    Petition 870190087026, of 9/5/2019, p. 9/54
    7/38 events. However, ο IPT also has undesirable characteristics, including incomplete generation of processor tracking packets and resulting slow decoding. As a consequence, the output of IPT alone is useful for offline analysis, such as performance profile, tuning and software debugging. IPT's approach to processor tracking compensates for undesirable slow decoding with respect to the desirable fast generation of processor tracking packages. IPT, in its current implementation of monitoring / analysis of execution control flows, relies on offline reconstruction to obtain complete control flow information resulting from executed code blocks.
    Patent Application Summary [0014] Patent application modalities provide a method and a computer system that includes a hardware processor (for example, an INTEL processor that includes IPT functional hardware) and computer-readable non-transitory media that includes instructions that facilitate the realization of the method. The modalities provide a technical solution to reduce the degree to which kernel resources are needed to perform the flow control integrity (CFI) application in a protected process running in a computer system runtime environment.
    [0015] According to a first aspect, a modality provides a method of applying CFI performed in a protected process running in a runtime environment of a computer system. The method comprises:
    intercept a system call that originated from the execution of the protected process running in the runtime environment;
    access from a kernel memory, by a quick path within a computer system kernel, a package of
    Petition 870190087026, of 9/5/2019, p. 10/54
    8/38 processor tracking that corresponds to the system call; match, by the fast path, the processor tracking package to a program control flow (edge) entry within a control flow graph definition with a credit value (CFG) having an associated credit value that represents a degree to which the control program flow is reliable; and conditionally invoke, after correspondence, a slow packet for further processing of the processor's tracking packet if the associated credit value does not meet a specified threshold, and otherwise provide an indication to allow the call to run of system.
    [0016] In a first implementation of the first aspect, the associated credit amount is determined by a fuzzing operation carried out in the protected process during a configuration procedure to execute the CFG.
    [0017] According to a particular modality of the first implementation of the first aspect, the fuzzing operation is performed using random data entry.
    [0018] In a second implementation of the first aspect, the indication to allow execution is provided to a corresponding system call manager.
    [0019] In a third implementation of the first aspect, the processor tracking package is an INTEL processor tracking package.
    [0020] In a fourth implementation of the first aspect, the program flow entry corresponds to an execution flow between a block of first code and a block of second code of the protected process.
    [0021] According to a particular modality of the fourth implementation of the first aspect, the input of program flow within
    Petition 870190087026, of 9/5/2019, p. 11/54
    9/38 of the CFG definition labeled by credit corresponds to a flow of conditional control.
    [0022] In a fifth implementation of the first aspect, the credit-labeled CFG definition is derived from a conservative CFG that contains: entries that represent conditional control flows, and entries that represent non-conditional control flows.
    [0023] According to a second aspect, a modality provides a computer processing node configured to perform a flow control integrity (CFI) method, the computer processing node which comprises:
    processing hardware; and a non-transitory, computer-readable media that includes computer-executable instructions that, when executed by the processing hardware, facilitate the computer-processing node to perform the CFI method which comprises:
    intercept a system call that originated from the execution of the protected process running in the runtime environment;
    access from a kernel memory, by a quick path within a computer system kernel, a processor tracking package that corresponds to the system call;
    match, by the fast path, the processor tracking package to a program control flow (edge) entry within a control flow graph definition with a credit value (CFG) having an associated credit value that represents a degree to which the control program flow is reliable; and conditionally invoke, after correspondence, a slow packet for further processing of the processor tracking packet if the associated credit amount does not match
    Petition 870190087026, of 9/5/2019, p. 12/54
    10/38 a specified threshold, and otherwise provide an indication to allow the execution of the system call.
    [0024] In a first implementation of the second aspect, the associated credit amount is determined by a fuzzing operation carried out in the protected process during a configuration procedure to execute the CFG.
    [0025] According to a particular modality of the first implementation of the second aspect, the fuzzing operation is performed using random data entry.
    [0026] In a second implementation of the second aspect, the indication to allow execution is provided to a corresponding system call manager.
    [0027] In a third implementation of the second aspect, the processor tracking package is an INTEL processor tracking package.
    [0028] In a fourth implementation of the second aspect, the program flow entry corresponds to an execution flow between a block of first code and a block of second code of the protected process.
    [0029] According to a particular modality of the fourth implementation of the second aspect, the program flow entry within the CFG definition labeled by credit corresponds to a flow of conditional control.
    [0030] In a fifth implementation of the second aspect, the CFG definition labeled by credit is derived from a conservative CFG containing: entries that represent flows of conditional control, and entries that represent flows of non-conditional control. Brief Description Of The Drawings [0031] Although the appended claims set out the characteristics of this patent application in particular, the application
    Petition 870190087026, of 9/5/2019, p. 13/54
    11/38 patent and its advantages are better understood from the detailed description below, taken in conjunction with the attached drawings, in which:
    [0032] Figure 1 illustratively depicts a combination of structural / functional components of a general computer processing architecture that incorporates an illustrative CFI application mechanism;
    [0033] Figure 2 is a flow chart that summarizes the operations of an illustrative method to generate a definition of flow control chart (CFG) generated before the online operation of the CFI application mechanism for a particular computer executable program; [0034] Figures 3A, 3B and 3C depict illustratively examples of CFG definition states associated with the output processed by each of the three stages / operations of the method summarized in Figure 2;
    [0035] Figure 4 is an illustrative example of conservative CFG for the reconstruction of ITC CFG; and [0036] Figure 5 is a flow chart that summarizes the operations of an example of a hybrid control flow integrity application mechanism performed according to the CFG definition presented by the summary method with reference to Figure 2 and Figures 3A , 3B and 3C.
    Detailed Drawings Description [0037] The INTEL Processor Tracking (IPT) feature of the INTEL processor hardware provides detailed processor tracking records with minimal resource consumption and / or processor slowness. However, IPT represents a significant challenge to be used as an online detection mechanism, as the runtime processor traces processed by IPT are highly compressed. Decode the records of
    Petition 870190087026, of 9/5/2019, p. 14/54
    12/38 compressed tracking is generally orders of magnitude slower than producing processor tracking records. A CFI enforcement mechanism is described, by way of example, that combines offline control flow chart (CFG) construction and online control flow monitoring of a stream of processor tracking packets (for example, IPT packets) to apply CFI in an online computing environment. In the illustrative examples, a CFG record format conforms to a processor tracking packet format processed by the processor hardware (eg, IPT packet format) that allows direct comparison between individual processor tracking packets and CFG records .
    [0038] Thus, the described CFI application mechanism, described by way of example here, is closely integrated with the processing hardware and operating system architecture of a computing system. The resulting CFI application mechanism simultaneously addresses existing needs for online CFI application for high levels of accuracy, efficiency and transparency. The CFI enforcement mechanism described here retrieves and uses processor tracking packages generated by processor hardware (for example, Intel Processor Trace (IPT) packages) generated by processor hardware. In an online processing environment, processor tracking packages are retrieved and compared to a control flow chart (CFG) containing a relevant pre-configured set of allowed / expected calls between blocks of program code to detect control flows unexpected abnormalities. The CFG is generated offline based on a static (offline) analysis that is augmented by a dynamic analysis (for example, fuzzing) of the program code of interest. Subsequently in an am
    Petition 870190087026, of 9/5/2019, p. 15/54
    13/38 online environment, corrective measures are taken to avoid damage resulting from the detection of an abnormal / unexpected control flow between the program's computing blocks based on a comparison of the processor tracking packages and the pre-configured CFG (described in details below). The accuracy in the CFI application mechanism described here comes from monitoring all processor tracking packets processed by the processor. As the processor trace generation functionality is implemented in the processor hardware, processing the processor trace records is very efficient, as it adds very little overhead during the execution time of a program of interest. The CFI application system described here also exhibits transparency, as no binary instrumentation is required and the system can be readily implemented on commodity hardware processors that have the ability to process processor tracking records at program execution time. .
    [0039] In addition, the CFI application mechanism described here solves the problem of high decoding overhead, at least initially avoiding dynamically decoding processor tracks. Instead, a control flow chart (CFG) definition, to which the compressed IPT output can be directly compared, is configured offline. The CFG definition contains a set of borders that connect the code blocks. The CFG definition borders contain control flow descriptions corresponding to the expected control flows (represented visually in the form of borders - that is, lines connecting blocks of code - of a graphical representation / representation of a CFG) between blocks of code. a particular program or related programs. Each definition of
    Petition 870190087026, of 9/5/2019, p. 16/54
    14/38 edge represented in the preconfigured CFG definition includes an indication, for each corresponding control flow, of a credit that represents a degree to which the flow is credible when found in an online processor tracking record processed by IPT. Thus, a manageable set of valid edges of the configured CFG definition can be processed and stored in a format that can be compared directly at run time with compressed processor trace records generated by the processor hardware (for example, IPT trace records ).
    [0040] Initially, attention is directed to Figure 1 which illustrates, illustratively, a combination of functional hardware and operating system components (processor cores, kernel operations, user operations) configured to execute the application mechanism of Illustrative CFI in an exemplary computer processing architecture. During configuration, a protected process 100, including a protected executable binary 102 and a set of shared libraries 104, is analyzed by a static binary analysis stage 106 to generate an ITC-CFG definition. See Figure 3B described below. The ITC-CFG definition specifies a set of borders that represent all indirect (conditional) flows between the executable blocks of the protected process 100.
    [0041] Continuing with reference to Figure 1, a fuzzing training module 108 applies a generated set of input values (according to fuzzing training objectives) to the protected executable binary 102 and the set of shared libraries 104 to present credit tags (credibility level) for the set of control flows (edges) defined in the ITC-CFG processed by static binary analysis 106. As an example, trained edges (high
    Petition 870190087026, of 9/5/2019, p. 17/54
    15/38 credibility) are labeled with high credit values (credibility) and associated with information obtained or not obtained (TNT). Control flows that have rarely or never been performed during fuzzing training are labeled with low credit values (credibility). After completing the configuration of a CFG definition, the edges marked with ITC-CFG credit are stored as an ITC-CFG definition with credit identification 110.
    [0042] The compact nature of the 110 ITC-CFG definition identified with resulting credit facilitates runtime comparisons with the flow of processor tracking packages generated by a set of 112 processing cores operating in the kernel. For example, a kernel module 112 runs the CFI application based on the ITC-CFG definition labeled credit 110. More particularly, kernel module 112, by way of example, configures a set of CPU cores 114 for generate a stream of processor tracking packets based on a set of program block calls generated during the operation of the protected process 100 that have been intercepted. For example, process call filtering is performed by selectively activating the operation of kernel module 112 according to the CR3 values provided to processor core set 114 during system startup to run the CFI application during the execution of the protected process 100. The resulting processor tracking packets provided by the processor core set 114 at run time are sent to a pre-configured buffer (FIFO) in memory 116 for CFI application processing by the 112 kernel.
    [0043] During the execution time of the protected process 100, according to the preconfigured call filtering criterion described
    Petition 870190087026, of 9/5/2019, p. 18/54
    16/38 above, processor core set 114 begins to generate processor tracking packets which are then stored in the configured buffer space of memory 116. In an illustrative example, a system call interceptor 115 (syscall) is triggered to initiate the flow check on the resulting processor / buffer tracking packets, which corresponds to security-sensitive system calls, stored by the processor core set 114 in the pre-configured buffer space of memory 116.
    [0044] During a control flow integrity check by a flow checker 117 of kernel module 112 in a processor trace packet record previously stored in memory 116, a fast path module processing operation in the processor tracking package retrieved from memory 116 takes precedence over a slow path module 119. In general, the fast path module 118 performs a quick comparison with reliable edges (with high labeled credit value) of the ICT-CFG credit definition 110 to potentially clean up recovered processor tracking from being associated with malicious (not present in definition 110 ITC CFG with credit label) or suspicious (low credit value). In an illustrative example, the suspicious processor tracking / code triggers further processing by the relatively slow check performed by the slow path module 119. The operation of the core module 112 is described here below with reference to Figure 4.
    [0045] Returning to Figure 2, an example of offline configuration of the CFG definition is summarized. In the particular example of offline preconfiguration of the CFG definition for applying CFI online, for 200 a conservative CFG definition is generated / acquired that contains all the potential borders between program code blocks (blocks). A simple illustrative example of conservative CFG processed during
    Petition 870190087026, of 9/5/2019, p. 19/54
    17/38
    200 is depicted illustratively in Figure 3A. The conservative CFG configuration is later converted during 210 into a CFG definition of connected indirect targets (ITC) that contains a set of indirect (conditional) edge records in accordance with a processor tracking packet format processed by the IPT feature of INTEL processors. . Then, a coverage-oriented fuzzing operation (applying a set of random entries and observing the resulting call flow) is performed in the program code for 220 to establish and assign credit values (credibility) and branch information to the edges of the ITC CFG definition processed during 210. Each of the CFG definition configuration operations described above is described below with reference to Figures 2, 3A, 3B and 3C.
    [0046] Continuing with reference to Figure 2, during 200 the static binary analysis is performed on the protected process 100 to process the conservative definition of CFG. In an exemplificative modality during the generation of conservative CFG definition, approaches based on existing binaries are used to disassemble and analyze the protected executable binary 102 and the set of shared libraries 104. The conservative CFG is conservative in the sense that all edges of Possible outputs for indeterminate indirect branches can be more than necessary and result in excessive false positives in which legitimate control flows are identified, during the runtime verification of the IPT processor tracking packets, as potentially malicious and prevented from being performed during the runtime check. During 200, the modules of the protected executable binary and the set of shared libraries 104 are analyzed independently to construct the intramodule CFG edges. Subsequently, the CFG edges
    Petition 870190087026, of 9/5/2019, p. 20/54
    18/38 intermodules are constructed using a procedure connection table (PLT) exposed by a dynamic connection mechanism. Different modules can only be connected by indirect hops in the PLT, as well as the corresponding return instructions from receivers to callers. In addition, during 200, the edges between the particular basic blocks are consequently added to the conservative definition of CFG. To deal with the global symbol interposition problem where a symbol can exist in different modules, the information fields (for example, DT NEEDED) in the binaries are used to find a previous library and link a symbol to the specific address. Another type of branching between modules is due to the VDSO (dynamic-linked-shared-object) mechanism, which is used to speed up the so-called syscall. For example, gettimeofday () usually results in a VDSO function call instead of a library call. The functions in the VDSO segments take precedence over libraries.
    [0047] During 200, when generating intramodule CFG edges, each direct call / jump instruction has an exact output destination and each conditional branch has two possible targets. For indirect calls, destinations that use TYPEARMOR usage and activation analysis are restricted and the return instructions are connected to the valid return addresses just after the call sites, in the same way as call / return correspondence. If the above approach is not successful in defining a CFG edge, then analysis of the underlying binary structure is used to conservatively resolve indirect jumps.
    [0048] Another issue arising from the generation of the conservative definition of CFG for the protected 100 process is the handling of the final call optimization. A final call is usually issued at the end of a function (for example, fun_b). The final call reuses the
    Petition 870190087026, of 9/5/2019, p. 21/54
    19/38 current stack frame and uses a jump command instead of a call to a target function (fun_c) and pretending to be called by the caller (fun_a) of the current function (fun_b). In this case, the return instruction from fun_c must return to fun_a, even if there is no connection from fun_a to fun_c. The process for generating a corresponding border in the conservative CFG definition detects and handles final calls by emulating the execution of the target function. During emulation, branching instructions are followed sequentially and all jump instructions between procedures directed to function inputs are collected. In addition, the return instructions for these functions are connected to the return address after the initial call site. The sequential tracking and recording of jumps continues until a specific stop condition is found.
    [0049] An example of the conservative CFG is shown in Figure 3A for purposes of comparison with the reduced set of blocks and edges of a corresponding ITC CFG definition presented during 210, described in detail here below. As shown in the illustrative example provided in Figure 3A, the basic blocks are connected to each other by direct or indirect branches as edges. In the illustrated example, each edge defined associates an output address of a source block (for example, BB-4) and an input address of a destination block (for example, BB-7).
    [0050] Continuing with reference to Figure 2, during analysis 210 of the conservative CFG definition, the ITC CFG definition contains a set of records having a format that is compatible (for example, facilitates the direct comparison of fields within) with the packages tracking processes processed by the 114 processor core set. The CFG definition generated during 200 is incompatible coded (compressed) processor traits generated by the functionality incorporated by INTEL's IPT processor. During 210, the output of
    Petition 870190087026, of 9/5/2019, p. 22/54
    20/38 conservative CFG definition processed during 200 is further processed to generate a set of defined edges that are compatible with the output of INTEL's IPT functionality that processes processor tracking packets for indirect branches only. INTEL's current implementation of IPT generates the respective packages for a specific type of flow change instruction (CoFI). Only two types of processor tracking packets generated by IPT support verification based on CFI enforcement: (1) a TNT processor tracking packet indicating whether a conditional branch is taken and (2) a TIP packet registering a destination address of an indirect branch.
    [0051] In an illustrative example, during the generation of the ITC CFG, only the TIP processor tracking packages are supported to: (1) prevent the path explosion and (2) support fast online search of a relatively small set / readily traceable from ITC-CFG edge definition records. All edges are collapsed which have direct types so that the target blocks of the indirect branches are connected to each other, and each edge associates the entry address of a basic block of indirect destination with the entry address of another basic block of indirect destination.
    [0052] Attention is drawn to Figure 3B which represents the ITC CFG definition processed during 210 processing the conservative input CFG definition (Figure 3A). For the sake of simplicity, the blocks within the protected process 100 are identified as BBn with n corresponding to the umpteenth basic block referenced in Figures 3A, 3B and 3C. In the illustrative example, Figure 3A includes not only direct edges, but also indirect edges. Processing the conservative CFG during 210 to process IPT-compliant edge definitions (represented in Figure 3B) involves only
    Petition 870190087026, of 9/5/2019, p. 23/54
    21/38 consider basic blocks that are targets of at least one indirect edge. See, for example, BB-2 (the basic target block of the indirect edge that arrives from BB-1). On the other hand, BB-4 is not the target of any indirect edges. Thus, the basic blocks (BB) numbered 2, 3, 5, 7, 9, 10 in Figure 3A are present in the ITC-CFG definition of Figure 3B. These blocks are referred to here as basic indirect target blocks (IT-BBs).
    [0053] During edge reconnection between basic source / destination blocks, each edge is associated again from an IT-BB to a nearest IT-BBs if there is an indirect edge in the path on the O-CFG. For example, in O-CFG from BB-3 to BB-9, there is an indirect edge from BB-6 to BB-9, so in the ITC-CFG definition example in Figure 3B, there is a connected end of BB-3 to BB-9. Although there is no indirect advantage in the path from BB-3 to BB-10 in OCFG, BB-3 is not connected to BB-10 in ITC-CFG. Thus, if there is no indirect branch from one IT-BB to another ITBB, no TIP packets will be generated by the IPT during the execution time, and there should be no connection between the two IT-BBs, even if they are both IT-BB BBs. and connected by direct edges. In addition, as TIP packets reveal a destination memory address of an indirect branch, the edges of the ITC-CFG definition (processed during 210 processing of the 210 conservative CFG output) connect the input addresses of the IT-BBs to each other. others, instead of connecting the output of one to the input of another, as shown in Figure 3A. For example, there are 6 IT-BBs (out of the 10 basic building blocks of the conservative CFG) left in the ITC-CFG definition in Figure 3B. It is important to note that the edges of the ITC-CFG definition in Figure 3B are reconnected so that the flow of the TIP packet generated by the IPT at run time can be searched directly at the edges defined in the ITC-CFG definition processed during 210.
    Petition 870190087026, of 9/5/2019, p. 24/54
    22/38 [0054] For the correction of the ITC-CFG definition generated during 210, suppose that in a randomly selected time the entry address of BB-x is registered, then BB-x must be one of the IT-BBs, otherwise there is no indirect branching towards it, so no TIP packets should be tracked according to the IPT tracking scheme. Now suppose that in the next next hour another BB-y entry address is registered, then we must prove that there is an edge that connects from BB-x to BB-y on the ITC-CFG. By reduction, if there is no edge from BB-x to BB-y in the ITC-CFG, which means that there is no indirect branching edge in the path from BB-x to BB-y in the O-CFG. So, BB-y should not be run or tracked. Therefore, for any two consecutive TIP packets tracked by the IPT, there must be an edge in the ITC-CFG to represent this flow of control, otherwise, some anomalies have occurred.
    [0055] During 220, dynamic fuzzing training (for example, providing random call data for function calls and observing resulting call patterns) are used to label the edges of the ITC-CFG definition processed during 210 by assigning a credit value (credibility) and TNT information for each ITC-CFG edge within the ITC-CFG definition. While the ITCCFG allows for direct search of IPT traces, which addresses processing speed issues needed to perform CFI enforcement online, there are still two security issues that arise from the ITC CFG during 210: coarse-grained CFI and loss of accuracy. With regard to coarse-grained CFI, there are still large amounts of false negatives (failure to identify the execution of malicious code) during the verification of the runtime flow, resulting from the application of coarse-grained CFI. In addition, the application of coarse-grained CFI resulting from consistent definitions
    Petition 870190087026, of 9/5/2019, p. 25/54
    23/38 CFG servers can lead to superfluous legal targets for each branch, resulting in ignored protection and undetected malicious attacks.
    [0056] Regarding the loss of precision, the ITC CFG definition processed during 210 may weaken the security provided by the conservative CFG due to the increase in the CFG. This problem can be illustrated using a metric, summarized in equation (1) below, called the average allowed indirect targets (EIA):
    A., am - 5 rn n '(equation 1) where n is the number of indirect branching instructions, Ti is the set of targets allowed for the indirect branching instruction i th .
    [0057] Intuitively, a smaller AIA represents a more precise CFG definition. As such, AIA can be one of the most appropriate metrics for measuring the strength of the CFI application, especially when protected software involves a large code base. Consider an example of conservative CFG reconstruction for ITC shown in Figure 4. In conservative CFG, AIA is 2. In ITC-CFG, AIA is 3, which means that the ITC CFG definition is less accurate than the original. In this example, the number of targets allowed for BB-2 and BB-3 changes from 2 to 3 after the reconstruction of the conservative CFG to process the ITC CFG. This derogation of precision is due to the absence of direct branch information that can fork the flow of control. The only possible direct branches capable of forking the execution flow are the conditional branches, the Obtained or Not Obtained (TNT) branches from BB-1 to BB-2 or BB-3 in this specific example. The ITC CFG definition removes these edges to prevent the path from exploding. This drawback of the ITC CFG configuration is
    Petition 870190087026, of 9/5/2019, p. 26/54
    24/38 corrected during 220 by applying a fuzzing analysis to the ITC CFG processed during 210. Fortunately, this information from TNT is tracked by the IPT, which can be used to strengthen the ITCCFG during the training phase.
    [0058] During 220 the training phase (fuzzing) is performed to generate a set of credit label values (credibility) and additional TNT information that are added to the edge records defined in the ITC CFG during 210. The decision to label whether or not an edge with a high credit value (credibility) depends on whether a processor tracking package corresponding to the edge was found during fuzzing training. Considering obtaining high coverage to minimize the need for context-sensitive heavy analysis, a set of coverage-like coverage-oriented inputs is generated for dynamic training during 220.
    [0059] Fuzzing training is an effective approach to identify vulnerabilities in protected processes in the real world. Fuzzing involves generating as much randomly selected data as possible. The randomly selected data is then used as an input to train protected processes - a brute force approach to identify possible process flow paths between basic blocks and to trigger possible security problems. Fuzzing is used in the illustrative example, instead of other dynamic techniques (for example, symbolic execution), because it is simple and practical to deploy. However, other forms of dynamic training to assign credit values (credibility) to ITC's CFG edge records are contemplated in alternative modalities.
    [0060] As an example, fuzzing training includes the following three steps:
    Petition 870190087026, of 9/5/2019, p. 27/54
    25/38
    Step 1: the trained application runs on QEMU, an open source hosted hypervisor that performs hardware virtualization, with the instrumentation logic implemented on top of it in user emulation mode. Instrumentation is responsible for discovering any new state transitions caused by the input.
    Step 2: some initial test cases are provided and stored in a queue. Test cases in the queue are searched one by one and mutated to generate new test cases using a balanced range of diffusion strategies. The resulting test cases are sequentially fed to the protected process software running in QEMU. If any mutated test case results in a new state transition, as noted by QEMU, it will be added to the queue for the subsequent mutation. This phase will generate test cases that can trigger different path explorations.
    Step 3: The test cases generated in step 2 are collected and used as inputs to feed the trained application running on the real hardware, take advantage of the IPT to track its execution flow and, finally, label the edges in the processed ITC CFG definition during 220 with high credit values (indicating reliable edges) based on processor tracking data processed during fuzzing analysis.
    [0061] Marking edges with credit values during 220 can be varied for different needs. For example, it is possible to use more than two levels of credit values to label the edges by assigning various values based on the number of times the specific edges were found during the training phase. In a simpler case, a binary-based labeling scheme is used where each edge is assigned a high credit value or a low credit value. Figure 3C represents, illustratively, the
    Petition 870190087026, of 9/5/2019, p. 28/54
    26/38 ITC CFG definition edges labeled as a result of training (broadcast) for 220. In the particular illustrative example, all edges, except BB-2 to BB-7 in the ITC CFG definition, are labeled with high credit values, and the TNT packet sequences obtained during the training phase are associated with the corresponding edges. This TNT information is important in that, with the direct fork information, a CFI application operation described below can prevent attackers from derogating from ο ΑΙΑ. The attribution of a credit value (credibility) resulting from the formation of the protected process to identify and remove unused indirect edges resulting from processing during 210, overcomes the potential problem of the increase in the EIA resulting from the reconstruction of the conservative CFG represented in Figure 4.
    [0062] It is important to note that fuzzing training is just one of several potential operations that can be used to assign a credit value to individual edges of the ITC CFG definition processed during 210. All of these alternatives are contemplated according to various implementations of the CFI application mechanism and method described here.
    [0063] Having described an exemplary architecture and configuration of the CFI application mechanism and method, attention is directed to Figure 5 which summarizes the runtime operation of the configured CFI application mechanism (kernel module 112) described here . In general, the CFI application method performed during the online operation of the computer system running code 100 of interest to the protected process incorporates a hybrid CFI verification mechanism containing a relatively fast (primary) path through the fast path module 118 that tries to match each record received from a processor tracking packet (for example,
    Petition 870190087026, of 9/5/2019, p. 29/54
    27/38 example, IPT) retrieved from memory 116 (buffer) to a corresponding trusted edge represented in the ITC CFG definition of credit identification 110. If a match is found between an IPT tracking record and a trusted edge record in the ITC CFG definition 110, then the processor trace is clean (that is, it does not pose a security threat). However, if no match is found between the IPT processor tracking package and a reliable ITC CFG edge record, a suspicious / abnormal processor trace (program flow between two blocks) was found. In response to the failure during the operation of the fast path module 118 to find a match, the operation of the CFI application is shifted to the relatively slow (secondary) path in the event that a corresponding ITC CFG record with a low credit value is combined with runtime processor tracking.
    [0064] A large majority of the runtime processor tracking packets are initially rejected or cleared by the operation of the fast path module 118. A processor tracking packet is rejected if the processor tracking packet is not match no edge in the definition of ITC CFG with credit identification. On the other hand, a processor tracking packet is cleared by the fast path module 118 if the tracking packet matches a trusted margin contained in the ITC CFG definition of credit identification 110. Only processor tracking packets that match a record non-credible edge (low credit value), in the ITC CGF 110 definition labeled credit, are subject to accurate / complete processor tracking processing with heavy overhead by the 119 slow path module.
    [0065] If properly trained, ITC-based processing
    Petition 870190087026, of 9/5/2019, p. 30/54
    28/38
    Credit-labeled CFG offsets processor packet processing from processor to slow path module 119 for an extremely small fraction of the provided processor tracking records. This conditional execution of the slow CFI enforcement mechanism, which is limited to operating on processor tracking packages combined during fast path processing for low credibility edges in the ITC CFG credit definition 110, provides an efficient CFI enforcement mechanism and accurate to detect reuse of code attacks on a computer system using the 100 protected process.
    [0066] With specific reference to Figure 1, the hybrid processing of processor tracking packets retrieved from memory 116 by flow checker 117 is described here below with reference to the summarized steps in Figure 5. In the illustrative example, the application of CFI depends kernel module 112 to protect the computer system during operation of protected process 100. As illustrated in Figure 1, kernel module 112 generally performs: (1) configuring processor core set 114 (for example, IPT) to generate processor trace packets during the protected process execution flow 100, (2) intercept specific security-sensitive system calls to trigger subsequent processor trace packet processing operations and (3) verification of the tracked execution flow on fast and / or slow paths.
    [0067] The operations summarized in Figure 5 refer to the operation of the kernel module 112 through interaction with the other identified components of the system represented in Figure 1. Prior to the operation of the steps summarized in Figure 5, the set of processor cores 114 , which operate under the kernel module 112 configuration commands, initiates and maintains the trace control flow
    Petition 870190087026, of 9/5/2019, p. 31/54
    29/38 of the protected process 110. The operation of the processor core set 114, in relation to the generation of processor tracking packet comprises the following two basic steps:
    Step 1: Enable controls for generating packages. There are a variety of controls for determining whether branch packets can be generated. Controls are enabled and configured, for example, by a collection of records specific to the IA32_RTIT_ * family model (MSRs). In the illustrative example, one of the most important is the MSR record IA32_RTIT_CTL, which is the main control and enabling MSR for generating tracking packages. The 112 kernel module sets the TraceEn and BranchEn bits to enable the CoFI-based processor tracking packet generated by the 114 processor core set. This register also clears the OS bit and sets the User bit to exclusively track the flow control at the user level. Meanwhile, the register also sets the CR3Filter bit to activate the CR3 filtering mechanism and sets the MSR IA32_RTIT_CR3_MATCH to the CR3 of the protected process. Finally, this register clears the FabricEn bit to send the tracking output directly to memory 116 and sets the ToPA bit to activate a Physical Address Table (ToPA) output scheme. Other bits of the MSR IA32_RTIT_CTL are left by default.
    Step 2: Configure memory regions for tracking output. In the illustrative example, INTEL's IPT tracking output can be configured to operate according to one of two output schemes: (1) a single contiguous region of physical address space or (2) a collection of regions of varying size of physical memory that are linked by pointer tables. In a particular example, kernel module 112 uses the last scheme that is referred to above as the Physical Address Table (ToPA) and stores the trace output in a ToPA with two regions.
    Petition 870190087026, of 9/5/2019, p. 32/54
    30/38 [0068] The selection of appropriate trigger points for flow verification determines the punctuality and performance of the protection provided by the operation of the 112 kernel module. An intuitive approach is triggered in the PMI (Performance Monitoring Interrupt) and in the verification of all packages in the interrupted region. This approach ensures that the entire flow of execution of the protected process 110 is verified. However, it can introduce significant overhead. Therefore, in an illustrative example, kernel module 112 performs flow verification at specified security sensitive endpoints. Although such endpoints are configurable, the 112 kernel module predefines some standards to provide reasonable security guarantees.
    [0069] As an example, the predefined endpoints mainly consist of the specific security syscalls specified, for example, execve, mmap, mprotect. As an example, during step 500 of the kernel module 112 runtime operation summarized in Figure 5, the system call interceptor 115 of kernel module 112 intercepts a temporarily sensitive security system call (syscall) by modifying the syscall table and installing an alternate syscall handler for each intercepted syscall. Whenever such a syscall is invoked, the newly installed handler first checks whether it is called by the protected process 100 using information such as CR3, process name or process ID. If the answer is yes, the verification starts, otherwise, it simply forwards (passes) the execution of the system call to the corresponding original syscall handler for regular processing. The intercepted security-sensitive syscalls can originate from the protected executable binary 102 or the set of shared libraries 104. Therefore, the system call interceptor 115 is responsible for verifying the flow
    Petition 870190087026, of 9/5/2019, p. 33/54
    31/38 execution of executable and shared libraries.
    [0070] If the flow check has failed, the kernel module sends a SIGKILL signal to the process and reports the detection of a control flow violation to administrators or users.
    [0071] During 510, the fast path module 118 is invoked to process the intercepted system call by performing a matching operation between the corresponding processor tracking packet retrieved from memory 116 and the ITC CFG definition credit-labeled edges with credit identification. The fast path module 118 checks the processor tracking packet corresponding to the intercepted system call based on a comparison of the processor tracking packet to the credit labeled edge records of the ITC CFG credit definition 110. The path module fast 118 initially fast decodes the scanned packet stored in the ToPA region of memory 116. In this phase, the hard path module 118 only analyzes the processor scan packets (based on the IPT formats) and extracts the TIP and TNT packets, without refer to binaries with the abstraction instruction flow layer. With the aid of packet flow limit (PSB) packets, which serve as synchronization points for the decoder, this process can be carried out in parallel to further speed up decoding. On the other hand, it is not necessary to decode the entire ToPA buffer. Instead, the fast path module 118 checks only a specified number of TIP packets. And, in consideration of the protection against attacks that hack in one module and invoke a system call in another, the 112 kernel module is decoded to store TIP packets spanning memory regions of multiple modules, and where at least one of them is inside. protected process 100.
    [0072] After acquiring collected indirect destination addresses
    Petition 870190087026, of 9/5/2019, p. 34/54
    32/38 at runtime corresponding to the intercepted system call, the fast path module 118 attempts to compare the addresses with the addresses of the edge registers in the ITC credit definition 110 credit. Specifically, the kernel module 112 maintains an array of data structures for source nodes on the edges represented in ITC CFG 110 with a credit label. Each edge source node has an associated count field that indicates a number of its output edges and a pointer pointing to the beginning of the edge array of its destination addresses. For example, all matrices are ordered according to addresses, so that a binary search can be used during correspondence by the fast path module 118 to reduce the length of time. To further speed up the matching process, kernel module 112 reserves separate memory dedicated to storing source nodes and their border connected targets with high credits and TNT information, and uses it as a cache for quick matching by the path module 118 during 510. During the shortcut check, for each address registered in the TIP packet, the shortcut module 118 first checks the same by searching the matrix of origin nodes and then checks if its successor address can be found in the matrix of its destination addresses. Upon completion (successful or unsuccessful) of the matching attempt by the fast path module 118 for 510, the control changes to 520.
    [0073] During 520, if one of the two address checks fails to match the processor tracking packet addresses and the edge addresses in the ITC CFG 110 labeled with credit, then the corresponding attempt of the path module fast 118 fails, a code attack reuse has been detected and the control passes to 530 where an alarm is generated for
    Petition 870190087026, of 9/5/2019, p. 35/54
    33/38 call the corresponding system call handler to invoke further processing of the rejected intercepted system call to prevent the malicious system call from executing.
    [0074] If, on the other hand, a corresponding edge entry is found in ITC CFG 110 with credit identification, the control changes to 540. At 540, the fast path module 118 accesses the credit value associated with the edge entry corresponding. If the credit value reaches a threshold value to indicate a match between the processor's tracking packet and a reliable margin, the control changes to 550, where shortcut module 118 issues a response to the corresponding system call handler, indicating that the system call can be performed.
    [0075] Otherwise, if the processor's tracking package is matched for 540 to an edge that has a credit value that does not meet a credibility limit, the control will change to 560.
    [0076] During 560, the operation of the slow path module 119 is invoked in the system call corresponding to an edge record, in the ITC CFG definition with credit label 110, determined to have a low credit value for 540. A flow verification is routed to the slow path engine. As an example, in addition to the TIP and TNT packets used by the fast path module 118 during fast matching, the inputs for the slow path module 119 include the protected process binaries 100. For example, the analysis carried out by slow path module 119 is INTEL's reference implementation of the IPT decoder library, which uses an abstraction instruction flow layer, analyzes the instruction binaries per instruction and combines the tracked packets for complete decoding. In the illustrative example, whenever the slow path check is triggered, kernel module 112
    Petition 870190087026, of 9/5/2019, p. 36/54
    34/38 issues a call to the upper architecture for a user-level process waiting to end the task.
    [0077] A wide variety of slow path processing operations on the suspected so-called malicious system indicated during 540 is contemplated based on a variety of policies and levels of protection desired for a particular system. The policies imposed on the slow path module 119 can be very precise, since the kernel module 112 can capture the entire execution flow and still perform a context sensitive analysis. At a very basic level, the kernel module 112 ensures that the intercepted system call process tracking packages conform to the conservative CFG-based implementation of the CFI application with the low-granular front edge analysis. In addition, for trailing edge analysis, a shadow stack is maintained using the abstraction instruction flow layer and compared with the tracked packets to enforce a single target directive for the return branches.
    [0078] Although the illustrative examples provided are described with reference to a specific processor environment that includes an INTEL Skylake processor including integrated IPT functionality, the hybrid processing described is applicable to a wide variety of processor tracking providers. In the IPT processing environment, processor tracking records associated with critical system calls are analyzed / compared during the CFI check. The CFI application mechanism described here can be used to transparently defend against control flow hijacking attacks against ROP. It is important to note that the hybrid approach combined with the well-formulated ITC CFG definition preconfiguration allows the application of CFI with only a small reduction in performance. In addition
    Petition 870190087026, of 9/5/2019, p. 37/54
    35/38 hybrid CFI application can exhibit more overhead reductions when adding hardware extensions, such as a hardware-assisted fast decoder.
    [0079] So, in summary, the hybrid CFI application mechanism, which includes a pre-configured ITC-CFG definition for fast path matching of reliable processor traces and CFG edges, provides a fully transparent mechanism for applying CFI, including the detection of CFI violations during the online operation of a program that comprises a limited number of reliable calls between blocks of code. The ITC CFG is initially processed by adapting a complete CFG definition to an output form processed by the processor tracking generator (for example, ITC). Accuracy and efficiency are enhanced by the dynamic training of an ITC CFG initially processed with random data entry during an ITC CFG fuzzing training that allows the identification and labeling (with credits and branch-taking information) of reliable edges (flows of program control between code blocks of one or more programs) represented in the pre-configured ITC CFG definition.
    [0080] A person skilled in the art should understand that the modalities of the present invention can be provided as a method, a system, or a computer program product. Therefore, the present invention can use a form of only hardware embodiments, only software modalities, or modalities with a combination of software and hardware. In addition, the present invention may use a form of computer program product that is implemented in one or more storage media usable by computer (including, but not limited to, disk memory, CD-ROM, optical memory and that include computer-usable program code.
    Petition 870190087026, of 9/5/2019, p. 38/54
    Examples are described with reference to the flowcharts and / or block diagrams of the method, the device (system) and the computer program product according to the modalities of the present invention. It should be understood that computer program instructions can be used to implement each process and / or each block in flowcharts and / or block diagrams and a combination of a process and / or a block in flowcharts and / or block diagrams. These computer program instructions can be provided for a general purpose computer, a dedicated computer, an embedded processor, or a processor of any other programmable data processing device to generate a machine, so that instructions executed by a computer or an processor of any other programmable data processing device generate an apparatus to implement a specific function in one or more processes in flowcharts and / or in one or more blocks in block diagrams.
    [0082] Said computer program instructions can also be stored in a computer-readable memory that can instruct the computer or any other programmable data processing device to function in a specific way, so that the instructions stored in the memory generated by computer generate an artifact that includes an instructional apparatus. The instruction apparatus implements a specific function in one or more processes in the flowcharts and / or in one or more blocks in the block diagrams.
    [0083] Said computer program instructions can also be loaded on a computer or other programmable data processing device, so that a series of operations and steps are performed on the computer or on another programmable device, thus generating processing implemented by
    Petition 870190087026, of 9/5/2019, p. 39/54
    37/38 computer. Therefore, instructions executed on the computer or other programmable device provide steps to implement a specific function in one or more processes in flowcharts and / or in one or more blocks in block diagrams.
    [0084] All references, including publications, patent applications and patents, cited here, are hereby incorporated by reference to the same extent as if each reference were individually and specifically indicated to be incorporated by reference and have been established in their entirety here.
    [0085] The use of the terms a and a and similar referents in the context of the description of the patent application (especially in the context of the following claims) should be interpreted to cover both the singular and the plural, unless otherwise indicated here or clearly indicated otherwise. otherwise by context. The terms comprising, having, including and containing must be interpreted as open terms (that is, including, but not limited to), unless otherwise stated. The recitation of ranges of values here is merely intended to serve as an abbreviated method of referring individually to each separate value within the range, unless otherwise indicated in this document, and each separate value is incorporated into the specification as if it were individually. described here. All methods described herein may be performed in any suitable order, unless otherwise indicated in this document or otherwise clearly contradicted by the context. The use of any and all examples, or exemplary language (for example, as provided here), is only intended to better illuminate the patent application and does not represent a limitation on the scope of the patent application, unless otherwise stated. No language in the specification should be interpreted as indicating any unclaimed element as essential to the practice of the patent application.
    Petition 870190087026, of 9/5/2019, p. 40/54
    38/38 [0086] Exemplary modalities are described and known here by the inventors for the realization of the patent application. Variations in these modalities may become evident to those skilled in the art when reading the previous description. The inventors expect those skilled in the art to use said variations as appropriate, and the inventors want the patent application to be practiced differently than specifically described herein. Accordingly, this patent application includes all modifications and equivalents of the matter recited in the attached claims, as permitted by applicable law. In addition, any combination of the elements described above in all its possible variations is covered by the patent application, unless otherwise indicated here or clearly indicated to the contrary by context.
    权利要求:
    Claims (16)
    [1]
    1. Control flow integrity (CFI) application method performed in a protected process running in a computer system runtime environment, the method characterized by the fact that it comprises:
    intercept a system call that originated from the execution of the protected process running in the runtime environment;
    access from a kernel memory, by a quick path within a computer system kernel, a processor tracking package that corresponds to the system call;
    match the processor tracking package to a program control flow (edge) entry within a control flow chart definition with a credit label (CFG) having an associated credit value that represents a degree to which the control program flow is reliable; and invoking, after correspondence, a slow packet for further processing of the processor's tracking packet if the associated credit value does not meet a specified threshold, and otherwise provide an indication to allow the system call to execute.
    [2]
    2. CFI application method, according to claim 1, characterized by the fact that the associated credit value is determined by a fuzzing operation carried out in the protected process during a configuration procedure to execute the CFG.
    [3]
    3. CFI application method, according to claim 2, characterized by the fact that the fuzzing operation is performed using random data entry.
    Petition 870190087026, of 9/5/2019, p. 42/54
    2/4
    [4]
    4. CFI application method, according to claim 1, characterized by the fact that the indication to allow the execution is provided to a corresponding system call manager.
    [5]
    5. CFI application method, according to claim 1, characterized by the fact that the processor tracking package is an INTEL processor tracking package.
    [6]
    6. CFI application method, according to claim 1, characterized by the fact that the program flow input corresponds to an execution flow between a block of first code and a block of second code of the protected process.
    [7]
    7. CFI application method, according to claim 6, characterized by the fact that the program flow entry within the CFG definition labeled by credit corresponds to a conditional control flow.
    [8]
    8. CFI application method, according to claim 1, characterized by the fact that the CFG definition labeled by credit is derived from a conservative CFG that contains:
    entries that represent conditional control flows, and entries that represent unconditional control flows.
    [9]
    9. Computer processing node configured to perform a flow control integrity (CFI) method, the computer processing node, characterized by the fact that it comprises:
    processing hardware; and a non-transitory, computer-readable media that includes computer-executable instructions that, when executed by the processing hardware, facilitate the computer-processing node to perform the CFI method which comprises:
    Petition 870190087026, of 9/5/2019, p. 43/54
    3/4 intercept a system call that originated from the execution of the protected process running in the runtime environment;
    access from a kernel memory, by a quick path within a computer system kernel, a processor tracking package that corresponds to the system call;
    match the processor tracking package to a program control flow (edge) entry within a control flow chart definition with a credit label (CFG) having an associated credit value that represents a degree to which the control program flow is reliable; and invoking, after correspondence, a slow packet for further processing of the processor's tracking packet if the associated credit value does not meet a specified threshold, and otherwise provide an indication to allow the system call to execute.
    [10]
    10. Computer processing node, according to claim 9, characterized by the fact that the associated credit amount is determined by a fuzzing operation carried out in the protected process during a configuration procedure to execute the CFG.
    [11]
    11. Computer processing node, according to claim 10, characterized by the fact that the fuzzing operation is performed using random data entry.
    [12]
    12. Computer processing node, according to claim 9, characterized by the fact that the indication to allow execution is provided to a corresponding system call manager.
    Petition 870190087026, of 9/5/2019, p. 44/54
    4/4
    [13]
    13. Computer processing node according to claim 9, characterized by the fact that the processor tracking packet is an INTEL processor tracking packet.
    [14]
    14. Computer processing node according to claim 9, characterized by the fact that the program flow input corresponds to an execution flow between a block of first code and a block of second code of the protected process.
    [15]
    15. Computer processing node, according to claim 14, characterized by the fact that the program flow entry within the CFG definition labeled by credit corresponds to a conditional control flow.
    [16]
    16. Computer processing node, according to claim 9, characterized by the fact that the credit-labeled CFG definition is derived from a conservative CFG that contains:
    entries that represent conditional control flows, and entries that represent unconditional control flows.
    类似技术:
    公开号 | 公开日 | 专利标题
    BR112019016151A2|2020-03-24|APPLICATION BASED ON TRACKING THE CONTROL FLOW INTEGRITY PROCESSOR OF A COMPUTER SYSTEM
    JP2020095753A|2020-06-18|Automated runtime detection of malware
    US10055585B2|2018-08-21|Hardware and software execution profiling
    US9063899B2|2015-06-23|Security in virtualized computer programs
    US9411743B2|2016-08-09|Detecting memory corruption
    KR20190035686A|2019-04-03|System and method for correcting memory corruption in computer applications
    Sun et al.2020|OAT: Attesting operation integrity of embedded devices
    Xuan et al.2009|Toward revealing kernel malware behavior in virtual execution environments
    US10474813B1|2019-11-12|Code injection technique for remediation at an endpoint of a network
    Geden et al.2019|Hardware-assisted remote runtime attestation for critical embedded systems
    Breitenbacher et al.2019|Hades-iot: A practical host-based anomaly detection system for iot devices |
    Payne2010|Improving host-based computer security using secure active monitoring and memory analysis
    US11263295B2|2022-03-01|Systems and methods for intrusion detection and prevention using software patching and honeypots
    US11093605B2|2021-08-17|Monitoring real-time processor instruction stream execution
    US20210026947A1|2021-01-28|Intrusion detection and prevention for unknown software vulnerabilities using live patching
    Wang et al.2015|Exploring efficient and robust virtual machine introspection techniques
    Piromsopa et al.2011|Survey of protections from buffer-overflow attacks
    Zhang et al.2018|A survey on security of cloud environment: threats, solutions, and innovation
    Ramaswamy2009|Autoscopy: Detecting pattern-searching rootkits via control flow tracing
    Harrison2014|Odinn: An in-vivo hypervisor-based intrusion detection system for the cloud
    Srinivasan et al.2011|Software based remote attestation for os kernel and user applications
    Tsantekidis et al.2020|Software System Exploration Using Library Call Analysis
    Chandramohan2018|Scalable analysis for malware and vulnerability detection in binaries
    Bushouse2018|Cloud-Ready Hypervisor-Based Security
    Breitenbacher et al.2021|HADES-IoT: A Practical and Effective Host-Based Anomaly Detection System for IoT Devices |
    同族专利:
    公开号 | 公开日
    CN110268411A|2019-09-20|
    US10896253B2|2021-01-19|
    KR102306568B1|2021-09-30|
    WO2018141279A1|2018-08-09|
    EP3571622A1|2019-11-27|
    KR20190109524A|2019-09-25|
    EP3571622A4|2020-02-19|
    US20180225446A1|2018-08-09|
    CN110268411B|2021-04-20|
    EP3571622B1|2021-04-07|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    US6047124A|1997-10-31|2000-04-04|Sun Microsystems, Inc.|System and method for tracing device drivers using a computer|
    US20040128539A1|2002-12-30|2004-07-01|Intel Corporation|Method and apparatus for denial of service attack preemption|
    US7130786B2|2004-02-12|2006-10-31|Computer Associates Think, Inc.|Using kernel level simulation techniques to improve application program robustness|
    US7343521B2|2004-05-28|2008-03-11|International Business Machines Corporation|Method and apparatus to preserve trace data|
    US7577992B2|2005-01-14|2009-08-18|Microsoft Corporation|Software security based on control flow integrity|
    EP1870829B1|2006-06-23|2014-12-03|Microsoft Corporation|Securing software by enforcing data flow integrity|
    US8136091B2|2007-01-31|2012-03-13|Microsoft Corporation|Architectural support for software-based protection|
    CN102073816A|2010-12-31|2011-05-25|兰雨晴|Behavior-based software trusted measurement system and method|
    US20130024676A1|2011-07-19|2013-01-24|Glew Andrew F|Control flow integrity|
    US9021589B2|2012-06-05|2015-04-28|Los Alamos National Security, Llc|Integrating multiple data sources for malware classification|
    US9063721B2|2012-09-14|2015-06-23|The Research Foundation For The State University Of New York|Continuous run-time validation of program execution: a practical approach|
    US9740868B2|2012-09-27|2017-08-22|International Business Machines Corporation|Customizing a security report using static analysis|
    US9262163B2|2012-12-29|2016-02-16|Intel Corporation|Real time instruction trace processors, methods, and systems|
    US9471461B2|2013-03-27|2016-10-18|Nec Corporation|Guarding a monitoring scope and interpreting partial control flow context|
    US9390260B2|2014-06-09|2016-07-12|Lehigh University|Methods for enforcing control flow of a computer program|
    CN104134038B|2014-07-31|2016-11-23|浪潮电子信息产业股份有限公司|A kind of secure and trusted running protection method based on virtual platform|
    US9767272B2|2014-10-20|2017-09-19|Intel Corporation|Attack Protection for valid gadget control transfers|
    US10007784B2|2015-03-27|2018-06-26|Intel Corporation|Technologies for control flow exploit mitigation using processor trace|
    EP3121749B1|2015-07-22|2019-06-26|Nxp B.V.|Method and apparatus for ensuring control flow integrity|
    CN105868626B|2016-03-25|2018-10-02|中国人民解放军信息工程大学|The method of monitoring software business conduct based on control stream coarseness integrality|
    US10248424B2|2016-10-01|2019-04-02|Intel Corporation|Control flow integrity|
    US10896253B2|2017-02-06|2021-01-19|Huawei Technologies Co., Ltd.|Processor trace-based enforcement of control flow integrity of a computer system|
    US10372902B2|2017-03-06|2019-08-06|Intel Corporation|Control flow integrity|
    AU2018200523A1|2017-03-09|2018-09-27|Accenture Global Solutions Limited|Smart advisory for distributed and composite testing teams based on production data and analytics|
    US10628286B1|2018-10-18|2020-04-21|Denso International America, Inc.|Systems and methods for dynamically identifying program control flow and instrumenting source code|
    US20190163900A1|2018-11-16|2019-05-30|Intel Corporation|Methods, systems, articles of manufacture and apparatus to detect process hijacking|US9501382B2|2013-06-25|2016-11-22|Purdue Research Foundation|Systems and methods of detecting power bugs|
    US10896253B2|2017-02-06|2021-01-19|Huawei Technologies Co., Ltd.|Processor trace-based enforcement of control flow integrity of a computer system|
    US10372902B2|2017-03-06|2019-08-06|Intel Corporation|Control flow integrity|
    JP6885226B2|2017-07-03|2021-06-09|株式会社デンソー|Electronic control device|
    US10984096B2|2018-03-28|2021-04-20|Intel Corporation|Systems, methods, and apparatus for detecting control flow attacks|
    CN109308415B|2018-09-21|2021-11-19|四川大学|Binary-oriented guidance quality fuzzy test method and system|
    WO2020261365A1|2019-06-25|2020-12-30|日本電気株式会社|Semiconductor device, control flow inspection method, non-transitory computer-readable medium, and electronic apparatus|
    US11016773B2|2019-09-27|2021-05-25|Intel Corporation|Processor trace extensions to facilitate real-time security monitoring|
    CN111078435A|2019-12-18|2020-04-28|支付宝信息技术有限公司|Service processing method and device and electronic equipment|
    KR102325291B1|2019-12-27|2021-11-12|주식회사 안랩|Method, device, computer-readable storage medium and computer program for tracking task|
    CN113569244B|2021-09-18|2021-12-03|成都数默科技有限公司|Memory malicious code detection method based on processor tracking|
    法律状态:
    2021-10-13| B350| Update of information on the portal [chapter 15.35 patent gazette]|
    优先权:
    申请号 | 申请日 | 专利标题
    US201762455523P| true| 2017-02-06|2017-02-06|
    US62/455,523|2017-02-06|
    US15/887,468|US10896253B2|2017-02-06|2018-02-02|Processor trace-based enforcement of control flow integrity of a computer system|
    US15/887,468|2018-02-02|
    PCT/CN2018/075189|WO2018141279A1|2017-02-06|2018-02-03|Processor trace-based enforcement of control flow integrity of computer system|
    [返回顶部]