WebAssembly Exploit Detection via RWX Memory Hooking
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Browser exploits that target WebAssembly instances can bypass data execution protection (DEP) security mitigation by abusing the allocation of read-write-execute (RWX) memory, making it difficult to detect and prevent malicious code execution.
Innovation Solution
An exploit detector is injected into the web browser process, which inserts hooks into specific functions of the WebAssembly engine API. These hooks monitor the contents of RWX memory allocated for WebAssembly instances, allowing the detector to record permissible data written to this memory and compare it to actual data, thereby detecting any discrepancies indicative of a browser exploit.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If RWX memory is allocated for WebAssembly instances, then WebAssembly code can be executed, but data execution protection (DEP) security mitigation is bypassed
Solution Approach 1:
The system performs preliminary actions by inserting hooks into WebAssembly engine functions before execution, recording expected memory contents in advance, and establishing a baseline of legitimate data patterns. This preliminary recording enables later comparison to detect exploits that bypass DEP protection.
Solution Approach 2:
The system implements feedback by continuously monitoring RWX memory contents during execution, comparing actual memory data against recorded expected contents, and detecting deviations that indicate exploit attempts. This feedback mechanism enables real-time security validation despite RWX permissions.
2Reliability
If hooks are inserted into WebAssembly engine functions, then exploit detection is enabled, but system complexity increases
Solution Approach 1:
The system uses an intermediary exploit detector component that sits between the WebAssembly engine and the execution environment. This intermediary intercepts function calls, records memory contents, and performs detection without requiring fundamental changes to the WebAssembly execution architecture, thereby managing complexity.
Solution Approach 2:
The system creates copies of expected memory contents and stores them for later comparison. Instead of complex real-time analysis, the system simply compares actual memory data against pre-recorded copies, simplifying the detection mechanism while maintaining high reliability.
3Measurement precision
If memory contents are monitored and compared, then exploit detection accuracy is improved, but processing overhead increases
Solution Approach 1:
The system extracts only the critical memory contents that need to be monitored and stores them separately. Instead of analyzing entire memory spaces, the system focuses on specific extracted data patterns, reducing processing overhead while maintaining detection accuracy through targeted comparison.
Data Source
AI summary
An exploit detector hooks functions of a WebAssembly engine API that include functions invoked when creating a WebAssembly instance, when permissibly modifying read-write-execute (RWX) memory allocated for a WebAssembly instance, and when calling an exported WebAssembly function. Upon invocation of the hooked instance creation function(s), the detector obtains an address of RWX memory allocated for the instance, reads data stored there, and records an association between the address and the data. If the hooked function(s) for permissibly modifying RWX memory is invoked, the detector updates the data stored in the recorded association with the modified data read from the RWX memory. Based on invocation of the hooked function(s) associated with WebAssembly export function calls, the detector reads the current data in the RWX memory to be executed and compares this data to the data recorded in association with the address. If the actual and expected data differ, the detector detects a browser exploit.