Dynamic Code Insertion in Sandboxed Runtimes
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current methods for sandboxing untrusted code in web browsers do not allow for dynamic code insertion or removal, limiting the flexibility and performance of browser-based applications that rely on dynamically linked libraries or just-in-time code generation.
Innovation Solution
A method for dynamically inserting and validating new code into a sandboxed application by writing it to secured memory, applying structural and alignment rules to ensure secure execution, and allowing deletion of the new code when safe, thereby enabling the execution of previously validated untrusted code with added flexibility and performance.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If static code analysis and sandboxing methods are used to securely execute untrusted code, then security is improved, but code flexibility and adaptability deteriorate because no new code can be added after initial validation
Solution Approach 1:
The patent implements dynamic code insertion capabilities within the sandboxed environment, allowing code to be added, validated, and executed at runtime rather than requiring complete static validation before execution. This transforms the previously static sandbox into a dynamic system that can adapt to new code requirements while maintaining security boundaries.
Solution Approach 2:
The patent applies preliminary validation and structural rule checking to dynamically inserted code before allowing execution. By performing validation actions in advance of actual code execution, the system ensures security requirements are met while still enabling dynamic code addition, resolving the contradiction between static analysis requirements and dynamic code needs.
2Adaptability or versatility
If dynamic code insertion is allowed in sandboxed applications, then code adaptability is improved, but system complexity increases due to additional validation and memory management requirements
Solution Approach 1:
The patent segments the memory space into distinct sandboxed regions with specific access controls and validation rules. By dividing the system into manageable segments (sandboxed application code, dynamically inserted code, secured memory regions), the complexity of managing dynamic code insertion is reduced through modular organization and targeted validation of each segment.
Solution Approach 2:
The patent introduces an intermediary validation layer that mediates between dynamically inserted code and the sandboxed execution environment. This intermediary performs structural rule validation, memory allocation checks, and security verification, isolating the complexity of dynamic code management from the core sandboxed application and simplifying the overall system architecture.
3Reliability
If code is written to secured memory that cannot be accessed by the sandboxed application, then security is improved, but execution speed deteriorates due to additional copying and validation steps
Solution Approach 1:
The patent performs validation, copying, and memory preparation actions in advance before code execution is required. By completing these security-critical operations preliminarily, the actual code execution can proceed at full speed without repeated validation overhead, resolving the contradiction between security checks and execution performance.
Solution Approach 2:
The patent implements an efficient copying mechanism that transfers validated code from secured non-accessible memory to sandboxed executable memory regions. This copying process is optimized to minimize performance impact, allowing code to be securely stored in protected memory while enabling fast execution from sandboxed regions without repeated security checks during execution.
Data Source
Figure 1~2
Figure 3
Figure 4A~4D
AI summary
Methods and apparatus for dynamically adding and deleting new code to previously validated application executing in a secured runtime. New code is written to a portion of secured memory not executable by application. New code is validated to ensure it cannot directly call operating system, address memory outside of secured memory, or modify secured memory state. Indirect branch instructions may only target addresses aligned on fixed size boundaries within the secured memory. Validated code is copied to portion of secured memory executable by application in two stage process that ensures partially copied segments cannot be executed. Validated new code can be deleted once all threads reach safe execution point, provided code was previously inserted as unit or contains no internal targets that can be called by code not also being deleted.