Inter-module Control Flow Policy for Call-Oriented Attack Mitigation

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Advanced code-reuse attacks, such as call-oriented programming, can bypass traditional control-flow integrity defenses, posing a challenge in detecting and mitigating indirect control flow transfers to valid function entry points.

Innovation Solution

A computing device with hardware real-time instruction tracing (RTIT) support generates trace data to identify indirect branch targets and applies an inter-module control transfer policy, allowing or denying transfers based on predefined rules, thereby detecting and preventing advanced code-reuse attacks without modifying existing application binaries.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If traditional control-flow integrity defenses are used, then basic return-oriented programming exploits are mitigated, but advanced code-reuse attacks such as call-oriented programming can still bypass the defense

Engineering Contradiction:
Improvedefense effectivenessVSAvoidattack vulnerability
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The patent segments the control-flow integrity check into two distinct phases: (1) a fast coarse-grained check that verifies the target address belongs to a valid module, and (2) a finer-grained check that validates the specific function entry point within that module. This segmentation allows the system to maintain high defense effectiveness while reducing the overhead compared to full fine-grained validation of every indirect call.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent performs preliminary validation by pre-computing and caching the set of valid function entry points for each module before execution. During runtime, the control-flow integrity mechanism simply checks whether the indirect call target matches one of the pre-validated entry points, rather than performing complex analysis at call time. This preliminary action enables the system to defend against advanced code-reuse attacks with minimal runtime overhead.

Inventive Principle:
Principle #10Preliminary action

2Reliability

If fine-grained control-flow enforcement is applied, then advanced code-reuse attacks are detected, but performance overhead increases significantly

Engineering Contradiction:
Improveattack detection capabilityVSAvoidexecution performance
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent divides the validation process into hierarchical levels: first checking if the target address falls within a valid module boundary (coarse-grained), and only if that passes, then verifying the specific function entry point (fine-grained). This segmentation allows most legitimate calls to be validated quickly at the coarse level, while only suspicious calls require the more expensive fine-grained check.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent applies partial validation by focusing control-flow integrity checks only on indirect calls that cross module boundaries or target unusual entry points. Legitimate intra-module calls with standard entry points are assumed safe and require minimal validation. This partial action approach maintains high detection capability for attacks while reducing overall performance overhead.

Inventive Principle:
Principle #16Partial or excessive action

3Measurement precision

If instrumentation of application binaries is performed, then precise control-flow monitoring is achieved, but device complexity and modification requirements increase

Engineering Contradiction:
Improvecontrol-flow monitoring accuracyVSAvoidsystem modification complexity
Core Design Contradiction:
Measurement precisionVSDevice complexity

Solution Approach 1:

The patent introduces an intermediary control-flow validation layer that sits between the application binary and the execution engine. This intermediary component intercepts indirect calls, validates them against the pre-computed set of legitimate entry points, and either allows or blocks execution. This approach achieves precise control-flow monitoring without requiring modification of the application binary itself, as the validation occurs in the intermediary layer.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent replaces the mechanical approach of instrumenting and modifying application binaries with a software-based validation mechanism that operates on the control flow data itself. Instead of embedding validation code within the application binary (mechanical modification), the system uses software to dynamically check control flow targets against a database of legitimate entry points, achieving the same security goal with less complexity.

Inventive Principle:
Principle #28Mechanics substitution (Replace mechanical system)

Data Source

PatentUS10515217B2Technologies for mitigating call-oriented programming using an inter-module control flow policy
Publication Date: 2019.12.24 INTEL CORP
  • US10515217B2 patent drawing
  • US10515217B2 patent drawing
  • US10515217B2 patent drawing

AI summary

Technologies for control flow validation a computing device having a processor with real-time instruction tracing support. The processor generates trace data indicative of control flow of a protected application. The computing device identifies an indirect branch target based on the trace data and determines whether the indirect branch target is included in the same module as a previous indirect branch target. If the indirect branch target and the previous indirect branch target are not included in the same module, the computing device determines whether an inter-module transfer policy is satisfied. If satisfied, the indirect branch target is stored as the previous indirect branch target and the protected application continues to execute. If the policy is not satisfied, the computing device generates an exception. The policy may be satisfied, for example, if the indirect branch target is an exported function. Other embodiments are described and claimed.