Software Execution Path Validation Against ROP Attacks
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Software applications are vulnerable to attacks like Return-Oriented Programming (ROP) where attackers exploit existing instructions to execute unintended code sequences, making it difficult for traditional countermeasures like integrity verification to detect these attacks, and new attacks are constantly evolving.
Innovation Solution
The method involves generating and executing protected software with an execution path that requires specific data properties to be satisfied before executing a primary function, including additional code that modifies or disables attacker-useful instructions at runtime, thereby preventing unauthorized execution of attack sequences.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If traditional integrity verification measures are implemented, then basic security is improved, but they cannot detect ROP attacks that use existing instructions
Solution Approach 1:
The patent applies preliminary action by modifying code at compile time to insert validation logic that checks execution context before allowing function execution. This pre-established protection mechanism validates whether the calling context is legitimate, preventing ROP attacks that attempt to execute functions in unauthorized contexts without requiring runtime detection systems.
Solution Approach 2:
The patent implements feedback by having the validation logic continuously monitor execution context and provide feedback on whether the current call is legitimate. The system checks if the caller is an authorized function and adjusts execution permission accordingly, creating a closed-loop security mechanism that adapts to detected attack patterns.
2Reliability
If code is modified to prevent attacks, then security is improved, but code complexity increases
Solution Approach 1:
The patent applies segmentation by dividing the security validation logic into separate, modular components that can be independently compiled and linked. The validation code is separated from the main application logic, allowing security checks to be implemented without significantly complicating the core business logic. This modular approach makes the security mechanism manageable and maintainable.
Solution Approach 2:
The patent introduces an intermediary validation layer that sits between the attacker-useful code and the protected function. This intermediary code checks execution context and either permits or blocks function execution, thereby protecting the system without requiring extensive modification of the original codebase. The intermediary acts as a buffer that adds security while minimizing impact on existing code structure.
3Object-affected harmful factors
If attacker-useful code is disabled at runtime, then attack effectiveness is reduced, but legitimate functionality may be affected
Solution Approach 1:
The patent applies local quality by making the disabling of attacker-useful code context-dependent rather than global. The validation logic checks the specific execution context (caller identity, call stack, etc.) and only prevents execution when the context indicates an attack. Legitimate calls from authorized functions proceed normally, while malicious calls from unauthorized contexts are blocked. This localized approach ensures that disabling code does not affect legitimate functionality.
Solution Approach 2:
The patent implements parameter changes by dynamically adjusting the execution permission parameter based on validation results. The system changes the state of the code from executable to non-executable only when the validation check fails, indicating a potential attack. When validation succeeds, the code remains fully executable, preserving legitimate functionality. This dynamic parameter adjustment allows the system to adapt security measures to the specific execution context.
Data Source
AI summary
A method of generating a protected item of software, there being an execution path within code for the protected item of software that causes code for one or more second functions to be executed before executing code for a first function, wherein execution of the code for the one or more second functions causes data to be stored at one or more memory locations, the data satisfying a set of one or more predetermined properties, wherein, in the absence of an attack against the protected item of software when the code for the protected item of software is being executed, the first function is arranged to provide first functionality, the method comprising: configuring the code for the first function so that execution, by one or more processors, of the code for the first function provides the first functionality only if the set of one or more predetermined properties is satisfied by data being stored, when the first function is executed, at the one or more memory locations.