Detecting WEBASSEMBLY-based browser vulnerability utilization

Abstract

In one embodiment, the vulnerability utilizes a detector to hook functions of a WebAssembly engine API, including functions that are called when creating a WebAssembly instance, when permitting modification of a read-write-execution (RWX) memory allocated for the WebAssembly instance, and when calling a derived WebAssembly function. When the hooked instance (s) create a function call, the detector obtains an address of the RWX memory allocated for the instance (s), reads data stored there, and records an association between the address and the data. The detector updates the data stored in the logged in association with the modified data read by the RWX memory if the hooked function (s) for permissible modification of the RWX memory is invoked. Based on the induction of the hooked function (s) associated with the WebAssessment derived function call, the detector compares the current data to be executed in the RWX memory with the data recorded in association with the address. If the actual data and the expected data are different, the detector detects browser vulnerability utilization.

Description

TECHNICAL FIELD

[0001] The present disclosure relates generally to data processing (e.g., CPC subclass G06F), and to security apparatuses for protecting computers, components thereof, programs, or data from unauthorized acts (e.g., CPC subclass G06F 21 / 00). BACKGROUND

[0002] A browser exploit is a type of exploit that compromises the security of a web browser, typically by targeting a vulnerability or flaw in the web browser. An attacker gains access to a web browser of a remote system, and thus access to the remote system itself, through a browser exploit.

[0003] WebAssembly is a portable binary code format used as a compilation target for multiple programming languages. Support for WebAssembly is widespread among major web browsers, thus allowing web applications to be written in high-level languages other than the JavaScript® programming language. A WebAssembly instance object is an executable module that includes functions that can be accessed (e.g., called) from JavaScript code. BRIEF DESCRIPTION OF DRAWINGS

[0004] Embodiments of the present disclosure can be better understood by reference to the following drawings.

[0005] Figure 1 is a conceptual diagram of detecting a browser exploit targeting WebAssembly.

[0006] Figure 2 is a flow diagram of example operations for hooking into a target function of a WebAssembly engine API for detecting a WebAssembly-based browser exploit.

[0007] Figure 3 is a flow diagram of example operations for detecting a browser exploit based on monitoring contents of RWX memory allocated for a WebAssembly instance.

[0008] Figure 4 depicts an example computer system having a browser exploit detector. DETAILED DESCRIPTION

[0009] The following description includes example systems, methods, techniques, and program flows to help demonstrate the present disclosure and are not intended to limit the scope of the claims. Well-known instruction instances, protocols, structures, and techniques have not been shown or described in detail in the interest of conciseness.

[0010] SUMMARY Executable WebAssembly code is typically executed from a memory page that has read- write-execute (RWX) permissions allocated for the WebAssembly instance. However, allocating RWX permissions to a WebAssembly instance creates an opportunity for a browser exploit that is able to bypass data execution prevention (DEP) security mitigations, because the RWX memory from which the WebAssembly code is executed cannot be marked as non-executable with DEP. The exploit obtains the memory address of the WebAssembly instance, and by resolving the structure of the WebAssembly instance, determines the memory address of the RWX memory allocated for the instance. A shell code is written to the RWX memory region and executed by invoking an exported WebAssembly function for the instance.

[0011] A browser exploit that abuses the RWX memory allocation for a WebAssembly instance in this way can be detected as described herein. The exploit detector is injected into the process of a web browser that uses a WebAssembly engine. The exploit detector hooks into multiple functions of the API of the WebAssembly engine: the WebAssembly instance creation function(s), the memory content update function through which the RWX memory allocated for a WebAssembly instance can be allowed to be modified, and the function that is invoked as part of executing an exported WebAssembly function. Upon invocation of the function through which the WebAssembly instance was created, a first of the inserted hooks is triggered, and the exploit detector can obtain the memory address of the RWX region allocated for the WebAssembly instance. The exploit detector reads the data stored in memory at that address, and records an association between that memory address and a copy of the data. If the function(s) through which the RWX memory can be allowed to be modified is invoked, a second of the inserted hooks is triggered. The exploit detector determines the modified data that was written to the RWX memory, and updates the data recorded in association with the memory address accordingly. Thus, the recorded data reflects the contents that can be allowed to be written to the RWX memory corresponding to the WebAssembly instance. Finally, invocation of the function that is called as part of preparing an exported WebAssembly function for execution triggers a third of the inserted hooks, the exploit detector reads the data that is currently written to the RWX memory allocated for the WebAssembly instance based on the third hook, and compares that data ("actual" data) to the expected data that has been recorded in association with the memory address. If a difference between the actual data written to the RWX memory and the expected data is identified, the exploit detector detects an exploit that abuses the RWX memory of the WebAssembly instance, and can prevent execution of the malicious code by preventing execution of the exported WebAssembly function. The exploit can be detected because the contents of the RWX memory that can be allowed to be written to are monitored and recorded based on invocation of the hooks, so any difference is attributed to an exploit that writes to that memory region that is not allowed to be written to.

[0012] Illustrative Figure 1is a conceptual diagram of detecting a web browser exploit targeting WebAssembly. A web browser 103 executes on a host system 101. The web browser 103 is a web browser that supports WebAssembly. The web browser 103 uses a WebAssembly engine 107 to support execution of WebAssembly programs. The WebAssembly engine 107 can be a JavaScript and WebAssembly engine, such as the V8 JavaScript and WebAssembly engine. The WebAssembly engine 107 has an API 113, which can be an internal API of the WebAssembly engine 107. For implementations in which the WebAssembly engine 107 is the V8 engine, the API 113 can correspond to the internal ::wasm namespace of the V8 API. Figure 1 A browser exploit detector 111 is also depicted. The browser exploit detector 111 has been injected into the process of the associated web browser 103. For purposes of illustration, the browser exploit detector 111 can comprise a dynamic link library (DLL) that is injected into the web browser 103 process via DDL injection.

[0013] Figure 1 The stages are annotated with a series of letters A-D. Each letter represents a stage of one or more operations. Although the stages are ordered for this example, the stages illustrate an example to help understand the present disclosure and should not be used to limit the claims. The subject matter falling within the scope of the claims can vary from what is illustrated. In addition, Figure 1 Stages B and C are depicted as comprising stages B1 / B2 and C1 / C2, respectively. This is to distinguish the operations performed by the browser exploit detector 111 from other operations that trigger the operations performed by the browser exploit detector 111.

[0014] At stage A, the browser exploit detector 111 hooks into target functions of the API 113. The browser exploit detector 111 inserts hooks 109 (i.e., code hooks) into a set of target functions of the API 113 such that when the target functions are invoked, the corresponding hooks are triggered and perform a redirection to the browser exploit detector 111. The browser exploit detector 111 hooks into three types of functions of the API 113: the function(s) that are invoked to create a WebAssembly instance, the function(s) that are invoked such that cause allowable modifications to the contents of the memory allocated for the WebAssembly instance, and the function(s) that are invoked as part of executing the exported functions corresponding to the WebAssembly instance. Although Figure 1 The API 113 is depicted as including functions associated with the V8 engine, although the naming of these functions can differ between WebAssembly engine APIs, with the hooks 109 including three corresponding hooks (depicted as hooks 109A-C). The target functions that are hooked can be functions of the API 113 that are invoked by the WebAssembly engine 107 as part of compiling a program to WebAssembly. In other words, the target functions that are hooked can not necessarily be called by the web application itself.

[0015] The browser exploit detector 111 inserts the hook 109A into a function of the API 113 named "InstantiateToInstanceObject," which is a function that is invoked as part of creating a WebAssembly instance. The browser exploit detector 111 inserts the hook 109B into a function of the API 113 named "PatchJumpTableLocked," which is a function that is invoked when patching the main jump table based on changes made to the exported WebAssembly functions (e.g., based on optimization / de-optimization of the exported WebAssembly functions) or other RWX memory allocated for the WebAssembly instance. The browser exploit detector 111 inserts the hook 109C into a function of the API 113 named "GenericJSToWasmWrapper," which is a function that is invoked when making a call to an exported WebAssembly function. Each of the hooks 109A-C can be inserted such that the hook is triggered upon invocation of the hooked function or before return of the hooked function.

[0016] At stage Bl, the browser exploit 105 triggers the hook 109A on the call to the function for creating a WebAssembly instance. The browser exploit 105 executes in the web browser 103. The browser exploit 105 creates a new WebAssembly instance via a call to the WebAssembly.Instance() constructor for a WebAssembly module named "wasmModule." The function "InstantiateToInstanceObject" of the API 113 should be invoked as part of creating the WebAssembly instance via the constructor call, which triggers the hook 109A and redirects execution to the browser exploit detector 111. The browser exploit detector 111 can have inserted the hook 109A such that the hook is triggered on return from the "InstantiateToInstanceObject" function.

[0017] At stage B2, the browser exploit detector 111 determines the memory address of the memory allocated with RWX permissions for the created WebAssembly instance (depicted as RWX memory 123 in Figure 2 ) and the contents of the RWX memory. The browser exploit detector 111 determines the address of the created WebAssembly instance based on the value returned from the "InstantiateToInstanceObject" function. Based on the address of the WebAssembly instance, the browser exploit detector 111 can determine the address of the RWX memory 123 allocated for the WebAssembly instance by accessing a property associated with the address of the WebAssembly instance, where the property corresponds to the address (e.g., via ). Figure 1 The browser exploit detector 111 is depicted as determining the RWX memory 123 to be allocated for the created WebAssembly instance at stage B2. The browser exploit detector 111 determines the RWX memory 123 to be allocated for the created WebAssembly instance based on the address of the WebAssembly instance and the contents of the RWX memory 123. The browser exploit detector 111 determines the address of the RWX memory 123 allocated for the WebAssembly instance by accessing a property associated with the address of the WebAssembly instance, where the property corresponds to the address (e.g., via The address 115 identifies an address of the RWX memory 123 allocated for the WebAssembly instance created by the browser exploit 105. The browser exploit detector 111 reads the contents 119 of the RWX memory 123 stored at the address 115 and records the address 115 and a copy of the contents 119 in a data structure 117 that it maintains. The data structure 117 includes associations between addresses of RWX memory allocated for WebAssembly instances and corresponding contents that are allowable to be written to the RWX memory. If the contents are written to the RWX memory 123 via inducement of the API 113 rather than directly (which would typically be done by a malicious actor, such as the browser exploit 105 that has gained access to the RWX memory 123), then the contents can be considered to be allowable to be written.

[0018] At stage CI, the hook 109C is triggered by a call by the browser exploit 105 to an exported function of the WebAssembly instance. The browser exploit 105 calls the exported function of the WebAssembly instance named "main" via "wasmInstance.exports" to trigger execution of the shell code written to the RWX memory 123 (not depicted in FIG. 1). As part of the execution of the exported WebAssembly function, the function "GenericJSToWasmWrapper" of the API 113 should be induced, which triggers the hook 109C. The browser exploit detector 111 can have inserted the hook 109C at the inducement of the "GenericJSToWasmWrapper" function (i.e., as opposed to the return of the function), such that the hook is triggered before the exported function is executed. Figure 1

[0019] At stage C2, the browser exploit detector 111 reads the contents of the RWX memory 123 corresponding to the created WebAssembly instance for which the exported function was called and compares the contents read from the RWX memory 123 to the memory contents stored in the data structure 117. To determine the address of the RWX memory 123 from which to read, the browser exploit detector 111 can determine the JSFunction argument obtained from the inducement of the "GenericJSToWasmWrapper" function. This JSFunction argument can be used to retrieve the WebAssembly instance associated therewith, from which the RWX memory address can be obtained (e.g., via the path ​). The browser exploit detector 111 reads the contents 121 of the RWX memory 123 at the determined address and compares the contents 121 to the contents recorded in the data structure 117 (i.e., contents 119). The difference between the contents written at the time of the WebAssembly instance creation and the induced time of the export function of the WebAssembly instance (i.e., contents 119 and contents 121, respectively) can be attributed to the browser exploit attempting to execute code written to the RWX memory 123 of the WebAssembly instance created thereby. As Figure 1 As depicted, the contents 119 stored in the data structure 117 and the contents 121 read from the RWX memory 123 are different.

[0020] At stage D, the browser exploit detector 111 detects the browser exploit. The browser exploit detector 111 detects the browser exploit based on the determined difference between the contents that can be allowed to be written to the RWX memory 123 of the WebAssembly instance and the contents that are not allowed to be written (i.e., those written by the browser exploit 105). The browser exploit detector 111 prevents the execution of the export function to prevent the execution of the malicious code written to the RWX memory 123 by the browser exploit 105. The browser exploit detector 111 can also generate a report or notification indicating that a browser exploit has been detected. The generated report or notification can include information about the exploit that the browser exploit detector 111 can discern, such as the affected memory address of the RWX memory 123. The browser exploit detector 111 can indicate the report or notification (e.g., via display on a graphical user interface, GUI), store the report or notification (e.g., in a database), etc.

[0021] Although not depicted, the browser exploit detector 111 can also detect the browser exploit at the time of the WebAssembly instance creation. The browser exploit detector 111 can read the contents of the RWX memory 123 at the time of the WebAssembly instance creation and compare the contents to the contents recorded in the data structure 117 (i.e., contents 119). The difference between the contents written at the time of the WebAssembly instance creation and the contents recorded in the data structure 117 (i.e., contents 119) can be attributed to the browser exploit attempting to execute code written to the RWX memory 123 of the WebAssembly instance created thereby. Figure 2-3The hook 109B can be triggered based on an invocation of the "PatchJumpTableLocked" function by the WebAssembly engine 107, however. The WebAssembly engine 107 can invoke the function based on recompiling the WebAssembly module and / or optimizing or deoptimizing the exported functions of the WebAssembly instance. These operations result in modifications to the RWX memory 123 allocated for the WebAssembly instance because the WebAssembly engine 107 will modify the main jump table to reflect the changes made to the code. When the main jump table is modified, the WebAssembly engine 107 calls the "PatchJumpTableLocked" function of the API 113, which triggers the hook 109B. Thus, the browser exploit detector 111 can read the contents of the RWX memory 123 that have been modified and update the contents recorded in the data structure 117 in association with the memory addresses of the RWX memory 123. This provides monitoring of the RWX memory 123 for contents that have been permissibly written to the RWX memory, which prevents false positive detection of browser exploits.

[0022] Figure 1 is a flowchart of example operations. To be consistent with Figure 2 and to facilitate understanding, the example operations are described with respect to a browser exploit detector. The nomenclature chosen for the program code is not a limitation on the claims. The structure and organization of the program can vary due to platform, programmer / architect preference, programming language, etc. Moreover, the nomenclature of the code units (programs, modules, methods, functions, etc.) can vary for the same reasons and can be arbitrary.

[0023] Figure 3 is a flowchart of example operations to insert a hook into a target function of a WebAssembly engine API for detecting WebAssembly-based browser exploits. The example operations assume that a process(es) have been launched for a web browser that supports WebAssembly with a WebAssembly engine. The functions of the API of the WebAssembly engine (e.g., internal API of the WebAssembly engine) into which the hook should be inserted can be predefined for each WebAssembly engine. The function nomenclature given below as an example is for an implementation of the WebAssembly engine that is the V8 JavaScript and WebAssembly engine, although the nomenclature of the functions to be hooked can vary between WebAssembly engines and corresponding APIs.

[0024] At box 201, a browser exploit detector is injected into the web browser process. Process injection techniques are used to inject code units (e.g., one or more libraries) of the browser exploit detector into the web browser process. The specific techniques used for process injection may depend on the operating system of the host on which the web browser runs. For example, the browser exploit detector may be implemented using a DLL injected into the browser process via DLL injection. The browser exploit detector may be self-injected or may be injected via an injector program.

[0025] At box 203, the browser exploit detector inserts one or more hooks into one or more corresponding functions of the API for creating a WebAssembly instance. The hooked functions are functions that accept (multiple) parameter values ​​and / or return (multiple) values, based on which the browser exploit detector can determine the memory address of the RWX memory allocated to the WebAssembly instance. Regarding the V8 engine, the browser exploit detector can insert hooks into... "In the given function, the browser exploit detector can insert (multiple) hooks that are triggered when the function returns (i.e., after the WebAssembly instance has been created).

[0026] At box 205, the browser exploit detector inserts one or more hooks into one or more corresponding functions of the API, through which the RWX memory allocated for web component instances can be permissibly modified. The hooked functions(s) are those triggered when the WebAssembly engine, such as through optimization / de-optimization of WebAssembly functions recompiled and exported by the WebAssembly module, modifies the RWX memory. These modifications to the RWX memory are considered permissible (i.e., as opposed to unpermissible writes made by browser exploits). Regarding the V8 engine, the browser exploit detector can insert hooks into functions allocated by " "In the given function, the browser exploit detector can insert (multiple) hooks that are triggered when the function returns (i.e., after the RWX memory has been modified by the WebAssembly engine)."

[0027] At block 207, the browser exploit detector inserts one or more hooks into corresponding one or more functions of the API that are invoked as part of executing the exported WebAssembly functions. The browser exploit detector can insert the hook(s) such that the hook(s) are triggered when the function is invoked (i.e., prior to execution of the exported function). The function(s) to hook and the technique for hooking can depend on the type and / or version of the web browser that the browser exploit detector is able to determine (e.g., based on web browser metadata accessible to the browser exploit detector).

[0028] With respect to the V8 engine, for some web browsers, such as older versions of the Chrome® browser, the browser exploit detector can insert a hook into the function "Builtins_GenericJSToWasmWrapper" according to traditional code hooking techniques. For other web browsers, such as newer versions of the Chrome browser, in which the function "Builtins_GenericJSToWasmWrapper" is an inline function, a different approach can be taken. As an example, a flag "--no-turbo-inline-js-wasm-calls" can be set when starting the web browser. When this flag is used, the function "Builtins_GenericJSToWasmWrapper" will not be an inline function, and the browser exploit detector can thus insert a hook into the function as previously described. As another example, the browser exploit detector can dynamically hook the "Builtins_GenericJSToWasmWrapper" function. To do so, the browser exploit detector first determines the address of the inline "Builtins_GenericJSToWasmWrapper" function. This can be accomplished by inserting a hook into a function given by "WebAssembly.Module.prototype.exports" that can be invoked during WebAssembly instance creation. This function takes a parameter named "export_wrapper" that is associated with the exported function(s) of the WebAssembly instance. The browser exploit detector obtains the address of "Builtins_GenericJSToWasmWrapper" via the value of the "export_wrapper" parameter that it obtains when it intercepts WebAssembly instance creation, such as by accessing a property of "export_wrapper" (e.g., via ). The browser exploit detector can then insert a hook for the determined address of the inline function​ In addition, the exported function wrapper function given by "Builtins_GenericJSToWasmWrapper" can be optimized for exported functions. This results in the creation of a new wrapper function given as "JSToWasmWrapper" for the exported function and any exported functions that share its signature. To determine the inlined "JSToWasmWrapper" function's nearest address for an exported WebAssembly function, the browser exploit detector hooks into the function given by "Builtins_GenericJSToWasmWrapper". When this hook is triggered, the browser exploit detector accesses the value of its parameter "wrapper_code" to determine (e.g., via ) the wrapper function's entry point property corresponding to this inlined function address. The browser exploit detector also hooks into the wrapper function with this determined address. As a result, the hook will be triggered on the invocation of any JSToWasmWrapper function, so the browser exploit detector can then intercept calls to the API made as part of preparing any exported function for execution, regardless of whether the exported function's wrapper function has been optimized.

[0029] Figure 3 is a flowchart of example operations for detecting a browser exploit based on monitoring the contents of RWX memory allocated for a WebAssembly instance. Variations Several of the blocks of this example operation are depicted in dashed line. This is to distinguish the example operations corresponding to the triggering of the invocation of a hook function that redirects execution flow to the browser exploit detector from the example operations performed by the browser exploit detector itself.

[0030] At block 301, the invocation of a WebAssembly instance creation function triggers a hook. The browser exploit detector intercepts the function invocation, and can obtain the value(s) passed into the creation function as parameters and / or returned from the WebAssembly instance creation function.

[0031] ​At block 303, the browser exploit detector determines the address of the RWX memory allocated for the WebAssembly instance. The browser exploit detector can determine the memory address of the created WebAssembly instance returned from a function creation function and obtained based on an interception of the function. From this memory address, the browser exploit detector can further determine the address of the memory with RWX permissions allocated to the WebAssembly instance, such as based on determining the address of the primary jump table via the memory address of the WebAssembly instance.

[0032] At block 305, the browser exploit detector records the memory address associated with a copy of the data read from the address. The browser exploit detector maintains a data structure (e.g., a map) in which it stores memory addresses of RWX memory and writes corresponding data for those addresses. The browser exploit detector reads data from the RWX memory at the memory address and stores the memory address and a copy of the data read from the RWX memory in the data structure (e.g., as a key-value pair in the map).

[0033] Block 305 is depicted as connecting to both block 307 and block 311. Operation can continue at either block depending on which function next gets invoked to trigger the hook. In implementations, the WebAssembly engine can invoke the function(s) for allowable modifications of the RWX memory, such as to optimize exported functions for the WebAssembly instance. If such a function is invoked, the corresponding hook is triggered and operation continues at block 307. However, despite being hooked, the function(s) can not be invoked across the deployment of the browser exploit detector, as the WebAssembly engine can not optimize / de-optimize exported WebAssembly functions or recompile WebAssembly modules, and thus can not invoke the function(s). In other words, the invocation of the function(s) can occur, but is not a necessary part of WebAssembly compilation and execution. If the function(s) are not invoked, operation continues at block 311.

[0034] At block 307, the invocation of the function that modifies the RWX memory triggers the hook. The browser exploit detector intercepts the function invocation and can obtain the value(s) passed into the function as arguments and / or returned from the WebAssembly function.

[0035] At block 309, the browser exploit detector updates the recorded association between memory addresses and corresponding data based on the modified RWX memory. The browser exploit detector can read the modified data from the recorded memory addresses of the RWX memory and update the association between the memory addresses and the corresponding data recorded in the data structure by replacing the data stored in the data structure with a copy of the modified data (e.g., by replacing the value mapped by the memory address key with a copy of the modified data).

[0036] At block 311, the browser exploit detector triggers the function invocation hook in response to the invoked function of the exported WebAssembly function. The browser exploit detector intercepts the function invocation and can obtain the value(s) passed into the function as parameters and / or returned from the WebAssembly function.

[0037] At block 313, the browser exploit detector compares the actual data read from the RWX memory to the recorded data. The browser exploit detector reads the data from the memory addresses of the RWX memory allocated for the WebAssembly instance recorded at block 305. When the WebAssembly exported function is invoked, the browser exploit detector compares the data stored in the data structure corresponding to the WebAssembly instance to the current data read from the RWX memory allocated for the WebAssembly instance. This can be considered a comparison between the actual data, or the data actually written to the RWX memory, and the expected data, or the data stored in the data structure indicating the data allowable to be written to the RWX memory.

[0038] At block 315, the browser exploit detector determines whether the actual data and the recorded data are different. If the data read from the RWX memory of the WebAssembly instance is different from the data recorded in the data structure of the WebAssembly instance, the browser exploit detector determines that the actual data is different from the recorded or expected data. If the actual data and the recorded data are the same, the operation continues at block 317. If the actual data and the recorded / expected data are different, the operation continues at block 319.

[0039] At block 317, the browser exploit detector allows the function to execute. If the actual data stored in memory and the recorded data expected to be stored in memory are the same, the browser exploit detector allows the execution of the invoked function and, thus, the exported WebAssembly function for which the hook was triggered.

[0040] At block 319, the browser exploit detector detects a browser exploit. The difference between the actual data and the recorded / expected data indicates a browser exploit that has written data inadmissibly to the RWX memory of a WebAssembly instance that it attempted to execute via the induced derived WebAssembly function. The browser exploit detector prevents execution of the hooking function in response to the call to the derived WebAssembly function being induced. The browser exploit detector can also indicate that a browser exploit was detected, such as via generating a report or notification that is displayed on a GUI and / or stored for subsequent access.

[0041] Figure 2 The flow diagrams have been provided merely as illustrative examples and are not intended to limit the scope of the claims. The flow diagrams depict operations within example embodiments that can be varied in many different ways. Additional operations can be performed; fewer operations can be performed; operations can be performed in different orders; operations can be performed in parallel; and operations can be performed by different entities. For example, Figure 4 The operations depicted in blocks 203, 205, and 207 of FIG. 2 can be performed in parallel or concurrently. It will be appreciated that each block of the flow diagram, and combinations of blocks in the flow diagram, can be implemented by program code. The program code can be provided to a processor of a general purpose computer, special purpose computer, or other programmable machine or apparatus.

[0042] As will be appreciated, aspects of the present disclosure can be embodied as a system, method, or program code / instructions stored in one or more machine-readable media. As such, aspects can take the form of hardware, software (including firmware, resident software, micro-code, etc.), or a combination of software and hardware aspects, all of which are generally referred to herein as a "circuit," "module" or "system." The functionality of the features presented as individual modules / units in the example illustrations can be organized in different ways depending on the platform (operating system and / or hardware), application ecosystem, interface, programmer's preference, programming language, administrator's preference, etc.

[0043] Any combination of one or more machine readable medium can be utilized. The machine readable medium can be a machine readable signal medium or a machine readable storage medium. A machine readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the machine readable storage medium would include the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a machine readable storage medium can be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. A machine readable storage medium is not a machine readable signal medium.

[0044] A machine readable signal medium can have a machine readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal can take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A machine readable signal medium can be any machine readable medium that is not a machine readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

[0045] Program code embodied on a machine readable medium can be transmitted using any appropriate medium, including but not limited to wireless, wired, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0046] Computer program code for carrying out operations for aspects of the present disclosure can be written in any combination of one or more programming languages, including an object oriented programming language such as the Java® programming language, C++, or the like; a dynamic programming language such as Python; and a conventional procedural programming language such as the "C" programming language or similar programming languages. The program code can execute entirely on a single machine, in a distributed fashion across multiple machines, and can be executed on one machine while providing results and / or accepting input on another machine.

[0047] The program code / instructions can also be stored in a machine readable medium that can direct a machine to function in a particular manner, such that the instructions stored in the machine readable medium produce an article of manufacture including instructions which implement the function / act specified in the flowchart and / or block diagram block or blocks.

[0048] Figure 4An example computer system with a browser exploit detector is depicted. The computer system includes a processor 401 (possibly including multiple processors, multiple cores, multiple nodes, and / or implementing multi-threading, etc.). The computer system includes a memory 407. The memory 407 can be system memory or any of the possible realizations of machine-readable media described above. The computer system also includes a bus 403 and a network interface 405. The system also includes a browser exploit detector 411. The browser exploit detector 411 installs a plurality of hooks into a WebAssembly engine API to track contents of RWX memory allocated for a WebAssembly instance that are permissibly written. The browser exploit detector 411 also detects browser exploit abuses of RWX memory allocations for a WebAssembly instance based on a difference between tracked permissibly written contents of RWX memory attributable to an exploit and actual contents of the memory. Any of the previously described functionality can be implemented partially (or entirely) in hardware and / or on the processor 401. For example, the functionality can be implemented with an application specific integrated circuit, in logic that is implemented in the processor 401, in a coprocessor on a peripheral device or card, etc. Moreover, realization can include any combination of hardware and / or software. Terminology Fewer or additional components (e.g., video cards, audio cards, additional network interfaces, peripheral devices, etc.) not shown in FIG. 1 are possible realizations. The processor 401 and the network interface 405 are coupled to the bus 403. Although illustrated as being coupled to the bus 403, the memory 407 can be coupled to the processor 401.

[0049] ​ The phrase “at least one of a list of items, preceding the conjunction “and” should not be interpreted as an exclusive list, and should not be interpreted as a list of categories from which only one item is to be selected, unless specifically stated otherwise. A clause reciting “at least one of A, B, and C” can be infringed upon by only one of the listed items, multiple of the listed items, and one or more of the items in the list and another item not listed.

Claims

1. A method comprising: installing a plurality of code hooks for a corresponding plurality of functions of an application programming interface (API) of a WebAssembly engine for a web browser; based on invocation of a first function of the plurality of functions, determining an address of a memory allocated for a WebAssembly instance and recording first content read from the memory, wherein the memory has read-write-execute permissions; based on invocation of a second function of the plurality of functions, reading second content from the memory allocated for the WebAssembly instance; determining whether the first content and the second content of the memory are different; and based on a determination that the first content and the second content are different, determining that the web browser has been exploited.

2. The method of claim 1, wherein the first function is a function of the API for creating a WebAssembly instance, wherein installing the plurality of code hooks comprises installing a first code hook of the plurality of code hooks into the first function of the API. Determining the address of the memory comprises determining the address of the memory based on a return value of the first function.

3. The method of claim 2, wherein, The second function is a function of the API based on invocation of an exported function of a WebAssembly instance, wherein installing the plurality of code hooks comprises installing a second code hook of the plurality of code hooks into the second function of the API.

4. The method of any one of claims 1 to 3, wherein, 5. The method of any one of claims 1 to 4, wherein installing the plurality of code hooks comprises installing a third code hook of the plurality of code hooks into a third function of the API, wherein the third function is a function of the API for permissibly modifying content of the memory.

6. The method of claim 5, further comprising, based on invocation of the third function, reading third content from the memory and updating the recorded first content for the memory based on the third content.

7. The method of any one of claims 1 to 6, wherein recording the first content read from the memory comprises storing an association between the address of the memory and the first content in a data structure.

8. The method of any one of claims 1 to 7, further comprising, injecting into a process associated with a web browser, wherein installing the plurality of code hooks is based on the injection into the process.

9. One or more non-transitory machine-readable media having stored thereon program code that, when executed by a computing device, causes the computing device to perform the method of any one of claims 1 to 8.

10. An apparatus comprising: a processor; and a machine-readable medium having instructions stored thereon that are executable by the processor to cause an apparatus to: install a plurality of code hooks into a corresponding plurality of functions of a WebAssembly engine application programming interface (API); ​ ​ trigger a first code hook of the plurality of code hooks based on creation of a WebAssembly instance, determine a memory address associated with read-write-execute (RWX) memory allocated for the WebAssembly instance; record memory contents read from the memory address, wherein the memory contents have RWX permissions; trigger a second code hook of the plurality of code hooks based on invocation of an exported function of the WebAssembly instance, compare current memory contents of the RWX memory to the recorded memory contents; and detect a browser exploit based on a determination that the current memory contents are different from the recorded memory contents.

11. The apparatus of claim 10, further comprising instructions executable by the processor to cause the apparatus to trigger a third code hook of the plurality of code hooks based on modification of the memory contents, update the recorded memory contents using modified memory contents read from the memory address, wherein the instructions executable by the processor to cause the apparatus to compare the current memory contents to the recorded memory contents comprise instructions executable by the processor to cause the apparatus to compare the current memory contents to the modified memory contents.

12. The apparatus of any one of claims 10 or 11, wherein the instructions executable by the processor to cause the apparatus to record the memory contents comprise instructions executable by the processor to cause the apparatus to record memory contents in a data structure in association with the memory address.

13. The apparatus of any one of claims 10 to 12, wherein the instructions executable by the processor to cause the apparatus to install the plurality of code hooks comprise instructions executable by the processor to cause the apparatus to install the first code hook to a first function of the API, wherein the first function is a function for WebAssembly instance creation, wherein the instructions executable by the processor to cause the apparatus to determine the memory address comprise instructions executable by the processor to cause the apparatus to determine the memory address based on a return value of the first function.

14. The apparatus of any one of claims 10 to 13, wherein the instructions executable by the processor to cause the apparatus to install the plurality of code hooks comprise instructions executable by the processor to cause the apparatus to install the second code hook to a second function of the API, wherein the second function is a function that is induced based on invocation of an exported function of a WebAssembly instance.

15. The apparatus of any of claims 10 to 14, further comprising instructions executable by the processor to cause the apparatus to inject a library into a web browser process, wherein the instructions executable by the processor to cause the apparatus to install the plurality of code hooks comprise instructions executable by the processor to cause the apparatus to install the plurality of code hooks based on injection of the library into the web browser process.

Images