An Empirical Study of Real-World WebAssembly Binaries Security, Languages, Use Cases

Aaron Hilbig Daniel Lehmann Michael Pradel [email protected] [email protected] [email protected] University of Stuttgart University of Stuttgart University of Stuttgart Germany Germany Germany

ABSTRACT supported and available in 93% of all global browser installations 1 WebAssembly has emerged as a low-level language for the web and as of February 2021. Beyond client-side web applications, WebAs- beyond. Despite its popularity in different domains, little is known sembly is also running on Node.js and even stand-alone runtimes. about WebAssembly binaries that occur in the wild. This paper Despite its growing popularity, the WebAssembly ecosystem is presents a comprehensive empirical study of 8,461 unique WebAs- severely understudied. To date, little is know about how the lan- sembly binaries gathered from a wide range of sources, including guage is used, for what purposes, and how this affects the security source code repositories, package managers, and live websites. We of WebAssembly-based applications. In particular, we are interested study the security properties, source languages, and use cases of the in the following research questions: binaries and how they influence the security of the WebAssembly RQ1: Source languages and tools. WebAssembly is a compilation ecosystem. Our findings update some previously held assumptions target, and in principle any programming language can be compiled about real-world WebAssembly and highlight problems that call to it. What languages are actually compiled to WebAssembly, how for future research. For example, we show that vulnerabilities that much do they contribute to the overall population, and what tools propagate from insecure source languages potentially affect a wide are used to produce the binaries? Answering these questions is range of binaries (e.g., two thirds of the binaries are compiled from relevant for understanding the impact of issues that specific source memory unsafe languages, such as tag">C and C++) and that 21% of all languages may have and for guiding future work toward source binaries import potentially dangerous APIs from their host envi- languages and toolchains prevalent in practice. ronment. We also show that cryptomining, which once accounted for the majority of all WebAssembly code, has been marginalized RQ2: Vulnerabilities propagated from insecure source languages. (less than 1% of all binaries found on the web) and gives way to a Recent work has shown that memory vulnerabilities in insecure diverse set of use cases. Finally, 29% of all binaries on the web are source languages, such as C and C++, may be exploited in Web- minified, calling for techniques to decompile and reverse engineer Assembly binaries, sometimes even more easily than in native bi- WebAssembly. Overall, our results show that WebAssembly has left naries [18]. How large is the attack surface offered by real-world its infancy and is growing up into a language that powers a diverse WebAssembly binaries compiled from insecure languages, e.g., in ecosystem, with new challenges and opportunities for security re- terms of dangerous APIs these binaries import from JavaScript or searchers and practitioners. Besides these insights, we also share in terms of vulnerable memory allocators they ship? Answering the dataset underlying our study, which is 58 times larger than the this question will increase our understanding of the threat posed largest previously reported benchmark. by vulnerabilities compiled to the web. RQ3: Cryptomining. Previous results show [24], and recent work CCS CONCEPTS assumes [15, 25, 34, 43], that WebAssembly is frequently used for • Security and privacy → Software and application security. cryptojacking, i.e., cryptomining performed in the browser of an unsuspecting client. Is cryptomining still an important threat today? ACM Reference Format: Aaron Hilbig, Daniel Lehmann, and Michael Pradel. 2021. An Empirical RQ4: Use cases. As a general purpose language, WebAssembly Study of Real-World WebAssembly Binaries: Security, Languages, Use Cases. can serve many purposes in web applications and beyond. What In Proceedings of the Web Conference 2021 (WWW ’21), April 19–23, 2021, are the typical use cases of WebAssembly? Given that the language Ljubljana, Slovenia. ACM, New York, NY, USA, 13 pages. https://doi.org/10. is becoming more widely adopted, it is important to understand 1145/3442381.3450138 what its use cases are and how this affects the security of the web. 1 INTRODUCTION RQ5: Minification and names. The ability to understand WebAs- sembly binaries, e.g., for auditing third-party code or for reverse WebAssembly is a fast, compact, low-level byte code language origi- engineering malware, depends on whether binaries contain mean- nally intended for client-side execution in web browsers. It is widely ingful names for program elements, e.g., functions. Do real-world WebAssembly binaries contain meaningful names or are they ob- This paper is published under the Creative Commons Attribution 4.0 International (CC-BY 4.0) license. Authors reserve their rights to disseminate the work on their fuscated through minification? personal and corporate Web sites with the appropriate attribution. WWW ’21, April 19–23, 2021, Ljubljana, Slovenia Answering these and other questions requires a set of WebAssembly © 2021 IW3C2 (International World Wide Web Conference Committee), published binaries that is (i) representative for how WebAssembly is used in under Creative Commons CC-BY 4.0 License. ACM ISBN 978-1-4503-8312-7/21/04. https://doi.org/10.1145/3442381.3450138 1https://caniuse.com/?search=WebAssembly WWWWWW ’21, ’21, April April 19–23, 19–23, 2021, 2021, Ljubljana, Ljubljana, Slovenia Slovenia Aaron Aaron Hilbig, Hilbig, Daniel Daniel Lehmann, Lehmann, and and Michael Michael Pradel Pradel the wild and (ii) large enough to cover the diversity of real-world int increment(int x) (func (param i32) [...]// header with the wild and (ii) large enough to cover the diversity of real-world { (result i32) // type info WebAssemblyWebAssembly usage. usage. Currently, Currently, no no such such set set of of binaries binaries exists. exists. return x + 1; local.get 0 20 00// local.get0 TheThe closest closest existing existing work work is is by by Musch Musch et et al al.. [24] [24],, who who report report } i32.const 1 41 01// i32.const1 on a study of WebAssembly usage in the top one million websites. i32.add 6a// i32.add on a study of WebAssembly usage in the top one million websites. ) 0b// end WhileWhile inspiring, inspiring, their their study study falls falls short short in in two two respects. respects. First, First, it it has has beenbeen performed performed at at a a point point in in time time when when WebAssembly WebAssembly was was still still (a) C Source Code. (b) WebAssembly (c) WebAssembly text format. binary format. inin its its infancy, infancy, with with usage usage biased biased to to early early adopters, adopters, e.g., e.g., cryptomin- cryptomin- Figure 1: Example of a function compiled to WebAssembly. ers,ers, and and a a single single toolchain toolchain dominating dominating the the ecosystem. ecosystem. Since Since then, then, Figure 1: Example of a function compiled to WebAssembly. manymany changes changes have have happened, happened, including including higher higher browser browser adoption, adoption, alternative compilers that have become available, the shutdown of • 28.8% of all binaries on the web are minified, calling for future alternative compilers that have become available, the shutdown of of instructions that cover diverse use cases, including vi- Coinhive (a common cryptomining platform) [42], and the realiza- work on decompiling and reverse engineering WebAssembly, to Coinhive (a common cryptomining platform) [42], and the realiza- sualization, interactive shells for programming languages, tion that vulnerabilities in insecure source languages can also be ensure that security analysts can understand web applications tion that vulnerabilities in insecure source languages can also be media players, game engines, data compression, and natural exploited in WebAssembly [18]. Second, the methodology proposed despite the presence of low level components. exploited in WebAssembly [18]. Second, the methodology proposed language processing. by Musch et al. [24] focuses only on binaries found on the web, and by Musch et al. [24] focuses only on binaries found on the web, and Overall,• 28.8% ourof all findings binaries on show the web that are minified,WebAssembly calling is “growing for future up”, only on those that are executed when just visiting a website. By only on those that are executed when just visiting a website. By whichwork leads on to decompiling a larger and muchand reverse more diverse engineering ecosystem WebAssem- than in only looking into client-side web applications, WebAssembly on only looking into client-side web applications, WebAssembly on its earlybly, days. to ensure From a that security security perspective, analysts this can diversity understand has several web other platforms is disregarded, e.g., on Node.js, browser extensions, other platforms is disregarded, e.g., on Node.js, browser extensions, implications.applications First, despite the fact the that presence there of are low now level many components. legitimate andand stand-alone stand-alone WebAssembly WebAssembly runtime runtime engines. engines. applications, and proportionally much fewer malicious ones, shifts Overall, our findings show that WebAssembly is “growing up”, ThisThis paper paper presents presents a a comprehensive comprehensive empirical empirical study study of of real- real- the focus from detecting malicious code to handling vulnerable code. which leads to a larger and much more diverse ecosystem than in worldworld WebAssembly WebAssembly binaries. binaries. The The core core of of our our work work is isWasmBenchWasmBench, , Second, the large fraction of binaries that originate from “insecure” its early days. From a security perspective, this diversity has several aa diverse diverse set set of of 8,461 8,461 unique unique binaries binaries gathered gathered from from a a variety variety of of source languages, in particular C and C++, shows the risk that implications. First, the fact that there are now many legitimate sources,sources, including including querying querying source source code code repositories repositories and and package package their problems, e.g., memory vulnerabilities, will now propagate to applications, and proportionally much fewer malicious ones, shifts managers,managers, searching searching the the HTTP HTTP Archive, Archive, and and crawling crawling the the web. web. The The the web. Mitigations against such memory vulnerabilities [18] are the focus from detecting malicious code to handling vulnerable code. binariesbinaries found found through through our our methodology methodology show show that that considering considering becoming an important goal to keep the web safe. Third, the many Second, the large fraction of binaries that originate from “insecure” onlyonly a a single single one one of of these these data data sources sources would would miss miss a a significant significant different compilation toolchains and their variants, e.g., in terms of source languages, in particular C and C++, shows the risk that fractionfraction of of the the WebAssembly WebAssembly ecosystem. ecosystem. While While we we obviously obviously can- can- memory allocators compiled into the binaries, create a potentially their problems, e.g., memory vulnerabilities, will now propagate to notnot guarantee guarantee to to cover cover all all kinds kinds of of real-world real-world WebAssembly WebAssembly usages, usages, large attack surface. Automated tools to analyze and improve the the web. Mitigations against such memory vulnerabilities [18] are WasmBenchWasmBench provides provides not not only only a a 58 58××largerlarger benchmark, benchmark, but but also also a a security of WebAssembly binaries are needed. becoming an important goal to keep the web safe. Third, the many moremore diverse diverse set set of of WebAssembly WebAssembly binaries, binaries, than than the the largest largest previ- previ- differentIn summary, compilation this paper toolchains contributes: and their variants, e.g., in terms of ouslyously reported reported benchmark benchmark [24]. [24]. memory• allocators compiled into the binaries, create a potentially WeWe use use WasmBench WasmBench to to address address the the above above research research questions questions The first comprehensive study of WebAssembly binaries gath- large attack surface. Automated tools to analyze and improve the throughthrough a a combination combination of of manual manual inspection, inspection, custom custom static static analysis analysis ered from multiple sources, including client-side web applica- security of WebAssembly binaries are needed. tools,tools, and and statistical statistical analyses. analyses. Our Our findings findings include:include: tions, package managers, and source code repositories; • In summary,A combination this paper of automated contributes: program analyses, manual inspec- • Real-world WebAssembly binaries are compiled from a variety tion, and statistical analysis to answer research questions about of source languages, including systems programming languages, • • Real-world WebAssembly binaries are compiled from a va- theThe security, first source comprehensive languages, andstudy use cases of WebAssembly of WebAssembly; binaries such as C, C++, Rust, and Go, higher level languages, such as riety of source languages, including systems programming • Empiricalgathered evidence from multiple and insights sources, about including security-related client-side proper- web AssemblyScript (a variant of TypeScript), and some rather unex- languages, such as C, C++, Rust, and Go, higher level lan- tiesapplications, of real-world package WebAssembly, managers, some and of source which code update reposito- earlier pected languages, such as COBOL and Kotlin. guages, such as AssemblyScript (a variant of TypeScript), findingsries; and many of which call for future work on mitigation • The majority of binaries is compiled from memory-unsafe lan- • and some rather unexpected languages, such as COBOL and techniquesA combination and analysis of automated tools; program analyses, manual in- guages, from which vulnerabilities may propagate into WebAs- Kotlin. • Byspection, far the largest and statistical benchmark analysis of WebAssembly to answer researchbinaries, whichques- sembly binaries [18]. • The majority of binaries is compiled from memory-unsafe wetions make about available the as security, a basis forsource other languages, studies and and as use a benchmark cases of • 65% of all binaries and 44% of all functions in them use the “un- languages, from which vulnerabilities may propagate into forWebAssembly; future tools: https://github.com/sola-st/WasmBench . managed stack”, a portion of linear memory that is unprotected • Empirical evidence and insights about security-related prop- WebAssembly binaries [18]. by the virtual machine and that can be exploited by attackers. erties of real-world WebAssembly, some of which update • 65% of all binaries and 44% of all functions in them use 2 BACKGROUND • 21% of all binaries import potentially dangerous APIs from their earlier findings and many of which call for future workon the “unmanaged stack”, a portion of linear memory that is host environment, e.g., the infamous eval, APIs to modify the File formats and modules. WebAssembly is a low-level bytecode unprotected by the virtual machine and that can be exploited mitigation techniques and analysis tools; DOM from JavaScript, or system call-like APIs to interact with language,• executed on a stack-based virtual machine. Figure 1 shows by attackers. By far the largest benchmark of WebAssembly binaries, the network and file system on platforms outside the browser. a small code example in C, the corresponding code in WebAssem- • 21% of all binaries import potentially dangerous APIs from which we make available as a basis for other studies and An attacker compromising a binary may abuse such APIs to bly’s .watas atext benchmark format, and for futurethe same tools: code https://github.com/sola- in WebAssembly’s .wasm their host environment, e.g., the infamous eval, APIs to mod- trigger unexpected behavior. binary format. The latter is usually used to distribute WebAssem- ify the DOM from JavaScript, or system call-like APIs to st/WasmBench . • Contrary to earlier findings24 [ ], cryptomining has dropped sig- bly. Instructions are arranged into functions, and functions are interact with the network and file system on platforms out- nificantly in relevance, comprising only 1% of all binaries. Instead, arranged into modules, which correspond to files. We use the terms side the browser. An attacker compromising a binary may 2 BACKGROUND we find applications with up to many millions of instructions “module” and “binary” interchangeably. Each module is divided abuse such APIs to trigger unexpected behavior. File formats and modules. WebAssembly is a low-level bytecode that cover diverse use cases, including visualization, interactive into multiple sections, including import and export sections that • Contrary to earlier findings24 [ ], cryptomining has dropped language, executed on a stack-based virtual machine. Figure 1 shows shells for programming languages, media players, game engines, declare functions shared with the environment, a code section that significantly in relevance, comprising only 1% of all bina- a small code example in C, the corresponding code in WebAssem- data compression, and natural language processing. defines functions and their bodies, anda data section that initializes ries. Instead, we find applications with up to many millions bly’smemory..wat text Functions, format, types, and the and same variables code in are WebAssembly’s referenced by indices..wasm An Empirical Study of Real-World WebAssembly Binaries WWW ’21, April 19–23, 2021, Ljubljana, Slovenia

Source Phase 1 Phase 3 GitHub 3,148 WebAssembly-related repositories Code Sources Collection Dataset Analysis Wasm Binaries, top 1,000 depended-on packages GitHub, NPM, NPM • Querying Metadata • Static Anal. WAPM, Addons, • • 2,350 WebAssembly-related packages Crawling Metadata Package Web, ... • Other • Manual Managers WAPM all 103 packages Phase 2 Firefox Dedup. & Filtering top 2,500 addons by average daily users All Sources Addons RQs Representative HTTP Archive 855 URLs to likely WebAssembly files Figure 2: Overview of the phases of our methodology. Web Tranco list: top 1,000,000 websites Own HTTP Archive: 40,000 URLs with WebAssembly in JS code Crawling binary format. The latter is usually used to distribute WebAssem- 3 WebAssembly top lists Survey bly. Instructions are arranged into functions, and functions are Manual arranged into modules, which correspond to files. We use the terms Other Figure 3: Sources from which we collect binaries. “module” and “binary” interchangeably. Each module is divided into multiple sections, including import and export sections that different contexts and at different stages of deployment. Sections 3.1 declare functions shared with the environment, a code section that to 3.4 present how we collect WebAssembly binaries from source defines functions and their bodies, anda data section that initializes code repositories, package managers that distribute deployed soft- memory. Functions, types, and variables are referenced by indices. ware, archived and live websites, and through manual search, re- Host environments. WebAssembly runs within a host environ- spectively. Figure 3 gives on overview of the different sources we ment, such as the browser, Node.js, or a standalone WebAssembly collect binaries from. Alongside each binary, we also collect meta- runtime like wasmer or wasmtime. The host environment instanti- data, e.g., on which website a binary was found. All activities related ates the WebAssembly binary and can provide imported functions to to collecting binaries were done between April and September 2020. the module. For example, in a client-side web application, JavaScript Overall, the collection phase results in 51,148 binaries, including code can instantiate binaries through the WebAssembly.instantiate duplicates and binaries that are not representative for real-world and WebAssembly.Module APIs. usages of WebAssembly. Section 3.5 presents the filtering phase, Linear memory. Each module instance has a linear memory sec- where we filter and deduplicate these binaries into a set of 8,461 tion, which can be thought of as an array of consecutive bytes. It unique binaries that serve as the basis for our study. Finally, the stores all data handled by the module, except for locals and globals third phase analyzes the set of binaries through a combination of (which can only be of four primitive types), including all dynami- static code analysis, analysis of metadata associated with the bina- cally allocated data structures. The i32 datatype is used for pointers ries, and manual inspection. We present the analysis phase along into linear memory. The linear memory has two implications. First, with its results in Section 4. programs that want to associate non-primitive data with functions To the best of our knowledge, no prior work has gathered Web- typically do so through a so-called “unmanaged stack”, which sim- Assembly binaries from such a diverse set of sources. As a result, ply is a region in the linear memory used to represent the function the number of binaries we obtain is 58 times larger than the largest stack. This stack is called “unmanaged” because it is not protected set studied so far (147 unique binaries) [24]. Our experimental re- by the virtual machine and under full control of the program. As a sults (Section 4.2) show that the sources we consider WebAssembly result, memory-unsafe behavior from source languages, e.g., C and binaries from complement each other, i.e., considering all of them C++, can also affect WebAssembly binaries. Second, non-trivial ap- is crucial to obtain a representative dataset. plications often have their own memory allocator compiled into the binary. Both the unmanaged stack and custom memory allocators 3.1 Collecting Binaries from Repositories may allow attackers to exploit a WebAssembly binary [18]. Our first method for collecting binaries looks into source code Compilers, tools, and runtimes. Various compilers target Web- repositories. Even though WebAssembly is a binary format, devel- Assembly, e.g., the Emscripten compiler for C and C++, the Rust opers often store binaries into source code repositories, e.g., to ease compiler, the AssemblyScript compiler, or the Asterius compiler the installation of a project or to include third-party libraries. To for Haskell. Several compilers sometimes share a common frame- gather such binaries, we clone all public repositories that are in the work, e.g., Emscripten and the Rust compiler are based on LLVM, top 1,000 results of four queries to the GitHub search API: while the AssemblyScript compiler and Asterius are based on Bina- • Repositories where “wasm” or “WebAssembly” is in the ryen. Because the bare WebAssembly language does not provide repository name or description (i.e., two queries). any built-in library, compilers often combine the compiled code • Repositories that are tagged with “WebAssembly” as one of with a runtime environment. For example, the Emscripten runtime the used programming languages. environment and the WebAssembly system interface (WASI) both • Repositories tagged with the topic “WebAssembly”. offer a set of low-level system calls, e.g., to support file I/Oand Overall, the queries result in 3,148 repositories, which we clone, networking. and then search for files ending in .wasm. 3 METHODOLOGY 3.2 Collecting Binaries from Package Managers Our methodology is split into three phases (Figure 2). In the col- Once developers deploy a WebAssembly-based application, it is lection phase, we obtain a large set of WebAssembly binaries from often made available through a package manager. We consider three a variety of sources. We select sources to cover WebAssembly in software ecosystems that use WebAssembly. WWW ’21, April 19–23, 2021, Ljubljana, Slovenia Aaron Hilbig, Daniel Lehmann, and Michael Pradel

3.2.1 npm Packages. The Node Package Manager (npm) distributes We search the responses stored in the HTTP Archive tables for JavaScript code, some of which relies on WebAssembly modules. likely WebAssembly binaries and then directly download the cor- Packages distributed via npm are typically used in server-side ap- responding files. To this end, we query two tables, from months plications with Node.js or on the client side. To find npm packages May and June 2020, which contain information about all requests that contain WebAssembly binaries, we gather two sets of pack- made while crawling the websites, and the corresponding responses. ages. First, from the full registry file of npm we compute the top These tables, called summary_requests are 434.4 GB and 476.7 GB 1,000 most depended-upon packages. Second, we query npm for all large. We filter all requests in the tables by the MIME type ofthere- packages that match at least one of the keywords “wasm” and “Web- quested resource, keeping only those commonly used to serve Web- Assembly”, which yields 2,350 packages. We install these packages Assembly, such as application/wasm and application/octet-stream, and their transitive dependencies, and then search the resulting and where .wasm appears in the URL. These queries result in a set 7,198 packages for .wasm files. of 855 URLs. We download files from each of these URLs using wget and keep all that start with \0asm, WebAssembly’s magic number. 3.2.2 wapm Packages. The WebAssembly Package Manager (wapm) specializes on distributing WebAssembly code. Most of the wapm 3.3.2 Web Crawling. The HTTP Archive-guided search covers a packages are intended to run standalone WebAssembly runtime wide range of top-level domains, but it may miss WebAssembly engines. Unlike for npm, we can afford to analyze all 103 available binaries on websites not covered by crawling a generic list of web- packages. We install all packages and again extract all .wasm files. sites and binaries that one cannot identify based on their MIME type. To collect additional binaries, we also perform our own web 3.2.3 Firefox Browser Add-ons. Browser extensions, traditionally crawling. There are three components to our crawling: the seed list, implemented in JavaScript, nowadays can also make use of Web- the crawling algorithm, and methods for detecting WebAssembly. Assembly code. To gather binaries used in browser extensions, we Seed lists. Any kind of web crawling requires a seed list of URLs download the top 2,500 Firefox add-ons from addons.mozilla.org, as to start from. We consider three seed lists, one generic list of popular measured by average daily users. We then unpack the extensions’ websites and two lists targeted specifically at WebAssembly: XPI archives, and search again for .wasm files. • Top one million websites. As a generic set of websites to ex- 3.3 Collecting Binaries from Websites plore, we start crawling from the one million most popular Collecting WebAssembly binaries from the web involves several websites on the Tranco list [28], a top list more resilient to challenges. First, as the web is too big to be searched in its entirety, manipulation. • finding suitable starting points for exploring it is crucial. Second, “WebAssembly” in JavaScript files. WebAssembly binaries on even when visiting a WebAssembly-powered website, it is non- websites must be executed by some surrounding JavaScript WebAssembly.instantiate trivial to identify and collect WebAssembly binaries from it. Some code, e.g., by calling . To identify sites embed WebAssembly modules into JavaScript source code, websites with such JavaScript code, we query a table pro- vided by the HTTP Archive that stores the full bodies of e.g., as base64-encoded strings that are decoded and instantiated at runtime. For such sites, we must detect WebAssembly modules all HTTP responses up to some size. We search this table, when they are executed. Other websites spawn requests for Web- which has a total size of 9.32 TB, with Google BigQuery for WebAssembly Assembly modules but never execute them during our collection all JavaScript responses that contain and add the process, e.g., because execution relies on specific user inputs. A URLs of the corresponding websites to our seed list, which purely dynamic methodology would miss such binaries. results in about 40,000 URLs. • We address the first challenge, finding good websites as starting WebAssembly top lists. As the most targeted seed list, we points, through two techniques. On the one hand, we can build on start crawling from three hand-curated lists of notewor- results from the HTTP Archive for finding sites known to con- thy WebAssembly-related websites. These websites cover projects using WebAssembly3, tools and demos4, and tain WebAssembly binaries (Section 3.3.1). On the other hand, 5 for our own crawling, we systematically start from potentially WebAssembly-based games . WebAssembly-related seed URLs (Section 3.3.2). To address the Crawling algorithm. Given a seed list, our crawler visits each second challenge of detecting WebAssembly binaries during crawl- URL on the list and recursively follows links on the visited websites. ing, we analyze all websites through a combination of static and The crawler visits each URL, with up to one retry. If the website dynamic detection techniques. is loading successfully, the crawler waits until either the “DOM content loaded” event is fired and all network connections have be- 3.3.1 Direct Downloads Guided by HTTP Archive. The HTTP Archive 2 come idle, or until a 30-second timeout occurs. The crawler collects project regularly crawls the web and makes the requests and re- all WebAssembly binaries loaded or executed in this time (details sponses available. Starting from URLs obtained from the Chrome below). For each visited website, the crawler extracts more URLs to User Experience Report , the project currently covers over 5 million explore from the href attribute of all -tags on the site. top-level domains, monthly. We here focus on websites crawled To control the amount of sites to visit, the crawler is configured using the desktop version of Google Chrome, which we access via with two parameters: the recursion depth d, which bounds how Google’s BigQuery database system. 3https://madewithwebassembly.com/ 4https://github.com/mbasso/awesome-wasm 2https://httparchive.org/ 5https://www.webassemblygames.com/ An Empirical Study of Real-World WebAssembly Binaries WWW ’21, April 19–23, 2021, Ljubljana, Slovenia many links away from the seed URLs to explore, and the exploration those variants by filename (e.g., *.opt.wasm) and path (e.g., breadth b, which bounds how many links to follow on each explored binaries in afl_out/). site. If a site has more than b links, the crawler picks b of them at • Test suites: On GitHub and in some npm packages, we find random. For the first two seed lists, we set d = b = 2, i.e., the crawler binaries that are used as test inputs for WebAssembly-related visits at most seven sites per URL in the seed list. Because the third tools, e.g., parsers, compilers, and virtual machines. One seed list is the most focused one, we explore it more thoroughly large portion are binaries from the official specification test with d = 7 and b = 3, and repeat the exploration with 16 separate suite, which often test only a single instruction or language crawler instances. We chose those parameters based on preliminary construct. We identify them by typical repositories and paths experiments, to find most binaries in a given time budget. (e.g., files in spectest/). • Tutorial projects: Many npm projects and some GitHub repos- Identifying WebAssembly binaries. For each website visited by itories are instances of users following WebAssembly tutori- the crawler, we use a combination of two techniques to identify als for particular tool chains.6 Those binaries are small and WebAssembly binaries on the site. Our first detection mechanism all very similar. We identify them based on common binary intercepts the website’s traffic using a local proxy that inspects names (e.g., hello_world_bg.wasm) and project names (e.g., the headers and contents of all requests and responses. To iden- [email protected]). tify WebAssembly modules, we check if the content-type header • Small and invalid binaries: Finally, we remove binaries that matches application/wasm or application/octet-stream, or if the contain ten or fewer instructions, and binaries that cannot URL contains .wasm, and then ensure that the response payload be validated by the reference WebAssembly binary toolkit starts with the proper magic number. If this is the case, we store (WABT), even with all language extensions enabled. the loaded file as a WebAssembly binary. The key advantage ofthis detection mechanism is that it detects WebAssembly modules even 4 RESULTS if they are not executed during the crawler’s visit of the website. The second detection mechanism tracks calls to APIs used for in- Based on our WasmBench dataset of real-world WebAssembly bi- stantiating WebAssembly modules, as proposed in prior work [24]. naries, we address the research questions (RQs) described in the We transparently overwrite built-in JavaScript functions, such as introduction. For each RQ, we detail the analyses performed on WebAssembly.instantiate, and analyze its invocations. In contrast the dataset, the direct results, and then interpret those to obtain to the first detection mechanism, this mechanism can detect Web- insights, i.e., take-away points, often with a focus on security. Assembly binaries that occur inline in JavaScript code, if executed. 4.1 Implementation and Experimental Setup 3.4 Collecting Binaries Manually The crawler is implemented based on Puppeteer and Puppeteer Clus- ter, two Node.js libraries for controlling instances of the Chromium In addition to automatically collecting WebAssembly binaries, we browser, here version 83.0.4103.0. The static analyses described in also gather a small number of binaries manually. On the one hand, the following are implemented in several Rust programs to stat- we collect binaries through manual interaction with the web in daily ically extract relevant features, such as instructions, names, etc. browsing between April and September 2020. On the other hand, from the binaries, complemented by Python scripts that perform we asked WebAssembly developers on reddit.com/r/WebAssembly the final analyses. For parsing binaries, we use the wasmparser li- in June 2020 for binaries they are willing to share. As discussed in brary, a project by the Bytecode Alliance. All experiments were run the results, these two manual collection methods complement our on an Ubuntu 18.04 machine with two Intel Xeon CPUs at 2.2 GHz automatically collected binaries with otherwise missed examples. running 48 threads, equipped with 256 GB of memory. The crawling was performed in chunks of 50,000 websites, where each chunk took 3.5 Deduplication and Filtering about 7 hours to finish, with a total of about 10 days for all crawling. After collecting binaries and associated metadata from the afore- The static analyses usually finish within several minutes for the en- mentioned sources, we remove duplicates and filter binaries that tire dataset. Our entire dataset and the implementation are available are not representative of real-world applications. To deduplicate for others to build on at https://github.com/sola-st/WasmBench. binaries, we compare files based on their SHA256 hash and remove identical files. Unless mentioned otherwise, our study focuses in 4.2 Overview of Dataset the deduplicated dataset. In addition to deduplication, we remove Table 1 gives an overview of our dataset. For each source, the table binaries that are non-representative of real-world applications, be- shows how many binaries we found, and how many remain after cause they fall into at least one of the following categories. Binaries deduplication and filtering. The last column shows how many bina- that occur multiple times, e.g., across different sources, are only ries are found only via a single source, illustrating the importance removed if all occurrences of it were filtered out. of particular collection methods for obtaining a diverse dataset. • Generated binary variants: Some GitHub repositories contain Sources. The largest contribution to the dataset are the GitHub binaries generated by research tools, e.g., to fuzz-test Web- repositories and packages from npm. Given that WebAssembly Assembly implementations, to superoptimize WebAssembly binaries on websites or in arbitrary packages are still relatively code [4], or to perform code diversification2 [ ]. Since these scarce, selecting repositories and packages related to WebAssembly tools turn a single binary into many, only slightly differ- ent variants, we remove the generated variants. We identify 6For example, the rustwasm book: https://rustwasm.github.io/docs/book/. WWW ’21, April 19–23, 2021, Ljubljana, Slovenia Aaron Hilbig, Daniel Lehmann, and Michael Pradel

Table 1: Contribution of different sources to the dataset. Table 2: Binaries filtered out due to different criteria. Found Binaries Removed Binaries Source (see Figure 3) Filter WWW ’21, April 19–23, 2021, Ljubljana, SloveniaTotal Unique Filtered Only Aaron Hilbig, Daniel Lehmann,Total and Michael Unique Pradel WWW ’21, April 19–23, 2021, Ljubljana, Slovenia Aaron Hilbig, Daniel Lehmann, and Michael Pradel GitHub,Table search: 2: Binaries wasm filtered 44,218 out due 21,117 to different 6,830 criteria. 6,641 Generated binary variants, of those: 9,279 8,048 NPM,Table top dependend-upon2: Binaries filtered out 14 due to 8 different 8 criteria. 3 1250 in CROW [2] repository100% 8,025 7,987 1250 100% NPM, search: wasm 3,488 2,452Removed Binaries1,163 1,036 Test suites and files, of those:80% 26,138 5,283 Filter Removed Binaries 1000 80% FilterWAPM, all 122 113Total 108 Unique 81 1000 variants of WebAssembly spec suite 25,133 4,931 Total Unique 750 60% Firefox add-ons, top by users 29 17 17 15 750Invalid WebAssembly binaries60% 13,593 3,513 Generated binary variants, of those: 9,279 8,048 40% GeneratedWeb, HTTP binary Archive variants, of those: 261 141 9,279 141 8,048 54 500Small binaries: <10 instructions40% 10,146 1,881 in CROW [2] repository 8,025 7,987 500 Web,in CROW crawling, [2] with repository seed list: 2,923 432 8,025 412 7,987 298 Tutorial projects, of those:20% 848 633 Test suites and files, of those: 26,138 5,283 Number of binaries 250 20% Percentilebinaries of TestHTTP suites Archive and files, of those: 2,046 268 26,138 254 128 5,283 Number of binaries 250 hello-wasm projects 695 506 variants of WebAssembly spec suite 25,133 4,931 Percentilebinaries of 0% 0 0% 5 7 9 11 13 15 17 19 21 23 25 27 variantsTranco top of WebAssembly websites spec suite 769 167 25,133 164 4,931 86 0 0 50 100 150 200 2 2 2 2 2 2 2 2 2 2 2 2 Invalid WebAssembly binaries 13,593 3,513 All0 Filters 50 100 150 200 25 2737,80829 211 213 215 217 219 2 14,95221 223 225 227 InvalidWebAssembly WebAssembly top lists binaries 108 13,593 89 76 3,513 43 Size (kilobytes) Size (bytes) Small binaries: <10 instructions 10,146 1,881 Size (kilobytes) Size (bytes) SmallManual binaries: <10 instructions 93 10,146 89 88 1,881 57 (a) Histogram of the lower 80% (b) Cumulative distribution of Tutorial projects, of those: 848 633 (a)opencascade.js Histogram of8 (65.8 the lower MB, 22.2M 80% instructions),(b) Cumulative a WebAssembly distribution port of TutorialAll Sources projects, of those:51,148 23,413 848 8,461 633 of the sizes of the binaries. the binary sizes (in log2 scale). hello-wasm projects 695 506 ofof the an opensizes of source the binaries. C++ CAD library,thefound binary on sizes npm (in and log2 GitHub;scale). hello-wasm projects 695 506 Figure 4: Distribution of binary sizes. All Filters 37,808 14,952 and finallyFigure the Clang 4: Distribution compiler, ofitself binary compiled sizes. to WebAssembly isAll an Filters effective way of finding binaries.37,808 At the same time, 14,952 the sources (46.7 MB, 12.6M instructions), found on wapm and GitHub. where we do not query for WebAssembly specifically (i.e., most where we do not query for WebAssembly specifically (i.e., most Insight 2. Complex, real-world applications with millions of lines whereof the webwe do crawling, not query the for top WebAssembly packages from specifically npm, and Firefox (i.e., add- most Insight 2. Complex, real-world applications with millions of lines of the web crawling, the top packages from npm, and Firefox add- of code are compiled to WebAssembly. ofons) the still web show crawling, that WebAssembly the top packages binaries from are npm, found and in Firefox the wild add- in of code are compiled to WebAssembly. ons) still show that WebAssembly binaries are found in the wild in ons)popular still projects show that used WebAssembly by millions of binaries users. Forare foundthe web, in thewe also wild see in popular projects used by millions of users. For the web, we also see popularthat all projectsour four used sources by millions are essential of users. for For finding the web, a diverse we also seeset of that all our four sources are essential for finding a diverse set of 4.3 RQ1: Source Languages and Tools thatWebAssembly all our four binaries. sources Only are crawlingessential the fortop finding one million a diverse websites set of WebAssembly binaries. Only crawling the top one million websites 4.3Given RQ1: WebAssembly’s Source goal Languages of being a universal and Tools bytecode, we study WebAssemblywould miss at binaries. least 225 Only unique crawling binaries. the top The one fact million that websitesthe seed 4.3 RQ1: Source Languages and Tools would miss at least 225 unique binaries. The fact that the seed Givenwhich WebAssembly’s languages are compiled goal of being to it in a practice, universal and bytecode, which toolchains we study wouldlists from miss HTTP at least Archive 225 unique and the binaries. WebAssembly The fact top thatlists arethe much seed Given WebAssembly’s goal of being a universal bytecode, we study lists from HTTP Archive and the WebAssembly top lists are much whichare used languages for to it. are compiled to it in practice, and which toolchains listssmaller from than HTTP the listArchive of the and top the one WebAssembly million websites, top yet lists the are number much which languages are compiled to it in practice, and which toolchains smaller than the list of the top one million websites, yet the number are used for to it. smallerof found than binaries the list are of similar the top or one even million higher, websites, shows yet that the atargeted number areAnalysis. used for toItit. is non-trivial to infer from a binary which source ofseed found list binaries for crawling are similar is key orto findingeven higher, otherwise shows that missed a targeted binaries. of found binaries are similar or even higher, shows that a targeted languageAnalysis. andIt is compiler non-trivial has toproduced infer from it. We a binary rely on which several source com- seed list for crawling is key to finding otherwise missed binaries. Analysis. It is non-trivial to infer from a binary which source seed list for crawling is key to finding otherwise missed binaries. languageplementary and methods. compiler First, haswe produced check the it. Weproducers rely onsection, several where com- language and compiler has produced it. We rely on several com- Insight 1. All methods we use to collect binaries contribute in plementarysome toolchains methods. explicitly First, encode we check the the sourceproducers language(s)section, a program where Insight 1. All methods we use to collect binaries contribute in plementary methods. First, we check the producers section, where a non-negligible way. Combining different sources and collection someis compiled toolchains from. explicitly Second, encode our analysis the source searches language(s) for characteris- a program a non-negligible way. Combining different sources and collection some toolchains explicitly encode the source language(s) a program techniques is crucial for obtaining a representative dataset. istic compiled function from. names Second,that appear our analysis in the import searchessection, for characteris- the export techniques is crucial for obtaining a representative dataset. is compiled from. Second,name our analysis searches for_ZdaPvcharacteris- ticsection, function or namesthe optionalthat appearsection. in the import For example,section, the exportis the ticname-mangled function namesdeletethatoperator appear in of the C++;import or runtime.gostringsection, the exportis a Filtering.Filtering.DeduplicationDeduplication and and filtering filtering non-representativenon-representative binariesbinaries section, or the optional name section. For example, _ZdaPv is the Filtering. Deduplication and filtering non-representative binaries section,Go runtime or the library optional function.name section. Overall, For we example, identify characteristic_ZdaPv is the (Section(Section 3.5) 3.5) significantly significantly reduces reduces thethe datasetdataset (Table(Table 2).2). InIn particular,particular, name-mangled delete operator of C++; or runtime.gostring is a (Section 3.5) significantly reduces the dataset (Table 2). In particular, name-mangledfunction namesdelete for C++,operator C, Rust, of Go, C++; AssemblyScript, or runtime.gostring Kotlin,is and a oneone repository repository that that contains contains generated generated variants variants of of input input binaries binaries is is Go runtime library function. Overall, we identify characteristic one repository that contains generated variants of input binaries is GoFStar. runtime Third, library the analysis function. searches Overall, for characteristic we identify characteristicstrings among importantimportant to to filter, filter, asas it it otherwiseotherwise accountsaccounts for for over over 8,0008,000 unique unique function names for C++, C, Rust, Go, AssemblyScript, Kotlin, and important to filter, as it otherwise accounts for over 8,000 unique functionall text sequences names for of C++, >3 ASCII C, Rust, characters Go, AssemblyScript, in the data section. Kotlin, and For binaries.binaries. From From the the second second category, category, test test suites, suites, we we also also see see that that FStar. Third, the analysis searches for characteristic strings among binaries. From the second category, test suites, we also see that FStar.example, Third, being the core analysis types, searchesResult::unwrap for characteristicand Option::unwrap strings amongfre- testtest binaries binaries are are commonly commonly reused reused across across many many projects projects (26,138 (26,138 all text sequences of >3 ASCII characters in the data section. For test binaries are commonly reused across many projects (26,138 allquently text sequences appear in oferror >3 messagesASCII characters of the Rust in the standarddata section. library. For We occurrences,occurrences, but but only only 5,283 5,283 unique unique binaries), binaries), and and that that most most of of them them example, being core types, Result::unwrap and Option::unwrap fre- occurrences, but only 5,283 unique binaries), and that most of them example,identify characteristic being core types, stringsResult::unwrap for C++, Rust,and Matlab,Option::unwrap and COBOL.fre- areare from from the the official official specification specification testtest suite.suite. TheThe lastlast filterfilter removes removes quently appear in error messages of the Rust standard library. We are from the official specification test suite. The last filter removes quentlyFourth, appearif none in of error the above messages work, of we the analyze Rust standardsibling files library.of bina- We binariesbinaries from from a a few, few, very very similar similar tutorials, tutorials, including including more more than than 500 500 identify characteristic strings for C++, Rust, Matlab, and COBOL. binaries from a few, very similar tutorials, including more than 500 identifyries collected characteristic from code strings repositories for C++, and Rust, package Matlab, managers. and COBOL. Sibling binaries from projects called hello-wasmhello-wasm. Fourth, if none of the above work, we analyze sibling files of bina- binariesbinaries from from projects projects called calledhello-wasm.. Fourth, if none of the above work, we analyze sibling files of bina- riesfile collected here frommeans code a repositories file in and the same package directory managers. that Sibling shares thefile BinaryBinary sizes. sizes.AsAs a a first first proxyproxy forfor the the diversity diversity ofof thethe collected collected ries collected from code repositories and package managers. Sibling Binary sizes. As a first proxy for the diversity of the collected filename here except formeans the extension.a file Wein take the same into directory account extensions that shares for thefile binaries,binaries, we we look look into into their their sizes sizes and and instruction instruction count. count. Figure Figure 4 4 file here means a file in the same directory that shares thefile binaries, we look into their sizes and instruction count. Figure 4 nameC, C++, except Rust, for Go, the AssemblyScript/TypeScript, extension. We take into account the extensionsWebAssembly for showsshows the the histogram histogram and and cumulative cumulative distribution distribution of of binary binary sizes sizes name except for the extension. We take into account extensions for shows the histogram and cumulative distribution of binary sizes C,text C++, format Rust, (.wat Go,/.wast AssemblyScript/TypeScript,), and several smaller languages. the WebAssembly Finally, for inin bytes. bytes. The The distribution distribution of of the the number number of of instructions instructions is is similar similar C, C++, Rust, Go, AssemblyScript/TypeScript, the WebAssembly in bytes. The distribution of the number of instructions is similar textsome format source (.wat code/.wast repositories), and several and packages smaller languages. with multiple Finally, uniden- for inin shape shape and and omitted omitted for for space space reasons. reasons. While While there there are are many many text format (.wat/.wast), and several smaller languages. Finally, for in shape and omitted for space reasons. While there are many sometified source binaries, code repositories we manually inspect and packagessource code, with buildmultiple scripts, uniden- and smallsmall binaries, binaries, there there is is a a long long and and heavy heavy tail tail towards towards larger larger sizes. sizes. some source code repositories and packages with multiple uniden- small binaries, there is a long and heavy tail towards larger sizes. tifiedbinaries. binaries, For each we manually of the automated inspect source methods code, above, build we scripts, manually and TwoTwo thirds thirds of of the the binaries binaries are are larger larger than than 20 20 KB KB and and have have more more tified binaries, we manually inspect source code, build scripts, and Two thirds of the binaries are larger than 20 KB and have more binaries.inspect binaries For each and of the theautomated predictions methods to confirm above, that we manuallyour heuristics thanthan 8,700 8,700 instructions. instructions. The The median median binary binary is is 37.1 37.1 KB KB large large and and has has binaries. For each of the automated methods above, we manually than 8,700 instructions. The median binary is 37.1 KB large and has inspectare precise. binaries For binaries and the where predictions multiple to confirm methods identifythat our the sourceheuristics 14,88514,885 instructions. instructions. The The largest largest binaries binaries are are a a WebAssembly WebAssembly port port inspect binaries and the predictions to confirm that our heuristics 14,885 instructions. The largest binaries are a WebAssembly port arelanguage, precise. we For confirm binarieswhere that multiplethe predictions methods are identify consistent. the source ofof TiDB TiDB77,, a a distributed distributed SQL SQL database database written written in in Go, Go, with with 75.1 75.1 MB MB are precise. For binaries where multiple methods identify the source of TiDB7, a distributed SQL database written in Go, with 75.1 MB language,Results. weFigure confirm 5a shows that the the inferred predictions source are languages. consistent. We see andand 16.9M 16.9M instructions, instructions, respectively, respectively, found found as as a a wapm wapm package; package; language, we confirm that the predictions are consistent. and 16.9M instructions,8 respectively, found as a wapm package; that almost two thirds (64.2%) of the binaries are compiled from C, opencascade.js 8 (65.8 MB, 22.2M instructions), a WebAssembly port Results. Figure 5a shows the inferred source languages. We see opencascade.js7 (65.8 MB, 22.2M instructions), a WebAssembly port 8 Results. Figure 5a shows the inferred source languages. We see ofhttps://github.com/pingcap/tidb an open source C++ CAD library, found on npm and GitHub; thathttps://github.com/donalffons/opencascade.js almost two thirds (64.2%) of the binaries are compiled from C, of an open source C++ CAD library, found on npm and GitHub; that almost two thirds (64.2%) of the binaries are compiled from C, and finally the Clang compiler, itself compiled to WebAssembly C++, or a combination of both. Given that these are memory-unsafe and finally the Clang compiler, itself compiled to WebAssembly C++, or a combination of both. Given that these are memory-unsafe (46.7 MB, 12.6M instructions), found on wapm and GitHub. languages, plagued with decades of vulnerabilities [41] and that (46.7 MB, 12.6M instructions), found on wapm and GitHub. languages, plagued with decades of vulnerabilities [41] and that 7https://github.com/pingcap/tidb WebAssembly binaries are not automatically safe from exploita- 7 WebAssembly binaries are not automatically safe from exploita- 8https://github.com/donalffons/opencascade.jshttps://github.com/pingcap/tidb tion [18], this result is highly worrying. 8https://github.com/donalffons/opencascade.js tion [18], this result is highly worrying. An Empirical Study of Real-World WebAssembly Binaries WWW ’21, April 19–23, 2021, Ljubljana, Slovenia

C++ (3,986) 47.1% Figure 5b shows which of our methods are most effective at Producers Section Projects (245) (1,710) 2.9% File Extension (304) inferring the source language. 20.2% of the binaries contain a pro- 20.2% 3.6% ducers section, from which the source code language can be directly 60.9% Strings (5,156) obtained. Characteristic names and strings are also important in- 14.9% 9.0% Unknown (763) 64.9% Rust (1,261) 3.8% ference methods, since they apply to 64.9% and 60.9% of binaries, 1.7% Names (5,495) 9.0% 3% Other (324) respectively. Overall, our methods infer the source language for 8.1% 3.3% Go (146) C/C++ (760) AssemblyScript (256) 91% (7,698) of the 8,461 unique binaries. C (682) <100 instructions (283) (b) Analysis methods (multi- (a) Source languages. ple can apply per binary). 4.4 RQ2: Vulnerabilities Propagated from Figure 5: Source languages and methods for inferring them. Source Languages Recent work shows that memory vulnerabilities in unsafe source Insight 3. Almost two-thirds of all collected binaries are com- languages can propagate to WebAssembly binaries and may some- piled from memory-unsafe source languages. These results and times be exploited even more easily than for native binaries [18]. those in the next section call for techniques to analyze and ensure While this prior work evaluates the risks of such attacks on a small WebAssembly’s binary security. set of 26 binaries, most of which are compiled C/C++ benchmarks, it remains unclear to what extent propagated vulnerabilities may Rust comes in second place with 14.9% of all binaries, followed affect real-world WebAssembly binaries. by AssemblyScript (3%) and Go (1.7%) as source languages with We address this question by studying three important character- official WebAssembly support. Finally, there is a longer tail ofother istic of binaries that attackers can abuse: (i) uses of the unmanaged languages, often used in single projects: Matlab9 (0.69%), FStar10 stack, i.e., an unprotected representation of the function stack in (0.33%), CHIP-811 (0.26%), several binaries compiled from toy lan- WebAssembly’s linear memory (Section 2), which attackers can use guages, and even a single instance of COBOL. A small portion of for stack-based buffer overflows and stack overflows (Section 4.4.1); binaries (1.1%) is translated directly from the WebAssembly text for- (ii) unsafe memory allocators compiled into a binary, which at- mat, i.e., likely to be written by hand. Finally, for 3.3% of all binaries tackers can abuse as a memory write primitive (Section 4.4.2); and we could not assign a source language, but since they contain less (iii) accesses to potentially dangerous APIs imported from the host than 100 instructions, they are also likely to be written manually. environment (Section 4.4.3). For (i) [18] reports results on 26 bina- ries only. We refine their static analysis and consider a325× larger Insight 4. In addition to C/C++, various other languages are com- dataset. For characteristics (ii) and (iii), this work is the first to sys- piled to WebAssembly, including languages with garbage collection tematically evaluate their prevalence in real-world WebAssembly and heavier runtimes (Go, Matlab). This result matches WebAssem- binaries. We study all binaries, irrespective of the source language, bly’s goal of serving as a universal bytecode. It also means binary because the problem of propagated vulnerabilities may affect all analysis will become more important, since source code is not al- languages with memory-unsafe behavior, in particular C, C++, but ways available, and even if it is, implementing separate analyses also, e.g., Rust, as its unsafe keyword is commonly used [7] and can for many languages is impractical. An Empirical Study of Real-World WebAssembly Binaries WWW ’21, April 19–23, 2021, Ljubljana, Slovenia cause memory-safety related vulnerabilities [46]. We also analyze the tools used to produce the binaries. For 20.2% 4.4.1 Usage of the Unmanaged Stack. The so-called “unmanaged 100% C++ (3,986) 1250 47.1% of the binaries, the producers section explicitly mentionsProjects (245) them in stack” is a region within the linear memory of a WebAssembly 80% Producers Section 1000 the processed-by field. 10.8% of all binaries (1,710) explicitly2.9% File mentionExtension being (304) program that holds, e.g., non-primitive data with function livetime. 20.2% 3.6% 750 60% produced by Clang. No binaries mention Emscripten because it does This design is motivated by the fact that all non-scalar data and all AnAn Empirical Empirical Study Study of of Real-World Real-World WebAssembly WebAssembly Binaries Binaries WWW WWW ’21, ’21, April April 19–23, 19–23, 2021, 2021, Ljubljana, Ljubljana,60.9% Strings Slovenia Slovenia (5,156) 40% not emit14.9% a producer section,9.0% Unknown unlike (763) newer versions of Clang. These data of which an address is taken cannot be put in WebAssembly’s 500 64.9% Rustresults (1,261) show that Emscripten3.8% is no longer the only way to compile locals or globals, but must instead reside in linear memory. Given 20% 1.7%

Number of binaries Names (5,495) 250 C++C++ (3,986)(3,986) Other (324) 47.1% Percentilebinaries of 3% producer that buffer overflows on the unmanaged stack can overwrite across 47.1% Projects (245) C andFigureFigure C++ 5b 5b9.0% to WebAssembly.shows shows which which of ofOther our our tools methods methods that appear are are most most in the effective effective atat ProducersProducers0% SectionSection Projects (245) 8.1% 3.3% Go (146) 12 0 5 7 9 11 13 15 File17 19Extension21 23 25 (304)27 rustc wasm-bindgen stack frames and even into supposedly “constant” data, this makes 0 50 100 150 200 2(1,710)(1,710)2 2 2 2.9%22.9%2 2File2 Extension2 2 2 (304)2 inferringsectioninferringC/C++ (760) are the the source source(9.5%), language. language.AssemblyScript 20.2% 20.2% (256) of of the the(7.9%), binaries binaries a JavaScript contain contain a a host- pro- pro- 3.6%3.6% 13 Size (kilobytes) 20.2%20.2%Size (bytes) ducerscodeducers generator, section, section,C from(682)from and walrus which<100 which instructions(7.5%) the the source source (283), a binary code code(b) Analysis language language transformation methods can can be be directly directly library, (multi- the unmanaged stack a more dangerous exploitation target than (a) Histogram of the lower 80% (b) Cumulative distribution60.9%60.9% StringsStrings (5,156)(5,156) of obtained.andobtained. the official(a) Characteristic Characteristic Source Golanguages. compiler names names (0.4%). and and strings stringsple Since can are are apply also alsoall percompilersimportant important binary). in- in-for Rust,C, even in native programs [18]. For this reason, we evaluate how 14.9%14.9% 9.0%9.0% UnknownUnknown (763)(763) Rust (1,261) 64.9%64.9% Rustof (1,261) the sizes of the binaries.3.8%3.8% the binary sizes (in log2 scale). ferenceandferenceFigure C++ methods,5: methods, to Source WebAssembly since since languages they they are apply apply andbased methods to to on 64.9% 64.9% LLVM, and and for we 60.9% 60.9% inferring can ofalso of binaries, binaries, derivethem. many binaries use it in practice. 1.7%1.7% NamesNames (5,495)(5,495) Figure3% 4: DistributionOther (324) of binary sizes. respectively.that 79.1% of theOverall, binaries our are methods produced infer with the the source help language of LLVM. for 9.0%9.0% 3% Other (324) respectively. Overall, our methods infer the source language for 8.1% 3.3% Go (146) Analysis. To analyze the usage of the unmanaged stack, our 8.1% 3.3% Go (146) 91%91% (7,698) (7,698) of of the the 8,461 8,461 unique unique binaries. binaries. C++,C/C++C/C++ or (760)(760) a combinationAssemblyScriptAssemblyScript of both. Given (256)(256) that these are memory-unsafe Insight 5. Almost 80% of all binaries are compiled with the help static analysis performs two steps. First, it tries to identify the stack CC (682)(682) <100<100 instructionsinstructions (283)(283) (b)(b) Analysis Analysis methods methods (multi- (multi- languages, plagued with decades of vulnerabilities [41] and that of the LLVM toolchain. This implies that security mitigations, such pointer to determine whether a binary uses an unmanaged stack at (a)(a) Source Source languages. languages. pleple can can apply apply per per binary). binary). WebAssembly binaries are not automatically safe from exploita- as4.4 stack RQ2: canaries, Vulnerabilities would have a large Propagated effect on fromthe ecosystem if all. Out of all global variables, the analysis selects the one that FigureFigure 5: 5: Source Source languages languages and and methods methods for for inferring inferring them. them. tion [18], this result is highly worrying. implementedSource in thisLanguages toolchain. • has type i32, i.e., the type of all pointers, Recent work shows that memory vulnerabilities in unsafe source • is declared mutable, to exclude constants like STACK_MAX, 9 Figure 5b shows which of our methods are most effective at InsightInsight 3. 3. Almost two-thirds of all collected binaries are com- languageslanguageshttps://github.com/Sable/matwably can can propagate propagate to to WebAssembly WebAssembly binaries binaries and and may may some- some- • is the most read and written global, as determined by the number 10inferring the source language. 20.2% of the binaries contain a pro- 14 piledpiled from from memory-unsafe memory-unsafe source source languages. languages. These These results results and and timeshttps://github.com/FStarLang/kremlin be exploited even more easily than for native binaries [18]. of global.get × global.set instructions , and 11timesducersAn 8-bit be section, VM exploited language fromfrom even which 1970s, more thehttps://github.com/pepyakin/emchipten sourceeasily than code forlanguage native can binaries be directly [18]. thosethose in in the the next next section section call call for for techniques techniques to to analyze analyze and and ensure ensure While12 this prior work evaluates the risks of such attacks on a small 14 Whileobtained.https://github.com/rustwasm/wasm-bindgen this Characteristic prior work evaluates names the and risks strings of such are alsoattacks important on a small in- The product of the counts prefers globals which are similarly often read and written. WebAssembly’s binary security. 13sethttps://github.com/rustwasm/walrus of 26 binaries, most of which are compiled C/C++ benchmarks, This is true for the stack pointer, but not for other frequently accessed pointers. setference of 26 methods, binaries, most since of they which apply are to compiled 64.9% and C/C++ 60.9% benchmarks, of binaries, it remains unclear to what extent propagated vulnerabilities may Rust comes in second place with 14.9% of all binaries, followed itrespectively. remains unclear Overall, to what our methods extent propagated infer the source vulnerabilities language may for Rust comes in second place with 14.9% of all binaries, followed affect real-world WebAssembly binaries. by AssemblyScript (3%) and Go (1.7%) as source languages with affect91% (7,698) real-world of the 8,461 WebAssembly unique binaries. binaries. by AssemblyScript (3%) and Go (1.7%) as source languages with byofficial AssemblyScript WebAssembly (3%) and support. Go (1.7%) Finally, as source there languagesis a longer with tail ofother We address this question by studying three important character- official WebAssembly support. Finally, there is a longer tail ofother officiallanguages, WebAssembly often used in singlesupport. projects: Finally, Matlab there9 (0.69%),is a longer FStar tail10 ofother isticistic4.4 of of binariesRQ2: binaries Vulnerabilities that that attackers attackers can can abuse: abuse: Propagated (i) (i) uses uses of of the the from unmanaged unmanaged languages, often used in single projects: Matlab99 (0.69%), FStar1010 languages,(0.33%), CHIP-8 often11 used(0.26%), in single several projects: binaries Matlab compiled(0.69%), from toyFStar lan- stack,stack, i.e., i.e., an an unprotected unprotected representation representation of of the the function function stack stack in in (0.33%), CHIP-81111 (0.26%), several binaries compiled from toy lan- Source Languages (0.33%),guages, CHIP-8and even a(0.26%), single severalinstance binaries of COBOL. compiled A small from portion toy lan- of WebAssembly’s linear memory (Section 2), which attackers can use guages, and even a single instance of COBOL. A small portion of Recent work shows that memory vulnerabilities in unsafe source guages,binaries and (1.1%) even is translated a single instance directly from of COBOL. the WebAssembly A small portion text for- of forfor stack-based stack-based buffer buffer overflows overflows andand stackstack overflowsoverflows (Section(Section 4.4.1); 4.4.1); binaries (1.1%) is translated directly from the WebAssembly text for- languages can propagate to WebAssembly binaries and may some- binariesmat, i.e., (1.1%) likely isto translated be written directly by hand. from Finally, the WebAssembly for 3.3% of all binariestext for- (ii)(ii) unsafe unsafe memory memory allocators allocators compiled compiled into into a a binary, binary, which which at- at- mat, i.e., likely to be written by hand. Finally, for 3.3% of all binaries times be exploited even more easily than for native binaries [18]. mat,we could i.e., likely not assign to be written a source by language, hand. Finally, but since for 3.3% they of contain all binaries less tackerstackers can can abuse abuse as as a a memory memory write write primitive primitive (Section (Section 4.4.2); 4.4.2); and and we could not assign a source language, but since they contain less While this prior work evaluates the risks of such attacks on a small wethan could 100 instructions,not assign a source they are language, also likely but to since be written they contain manually. less (iii)(iii) accesses accesses to to potentially potentially dangerous dangerous APIs APIs imported imported from from the the host host thanthan 100 100 instructions, instructions, they they are are also also likely likely to to be be written written manually. manually. environmentenvironmentset of 26 binaries, (Section (Section most 4.4.3). 4.4.3). of which For For (i) (i) are [ [1818 compiled]] reports reports C/C++ results results benchmarks, on on 26 26 bina- bina- riesriesit remains only. only. We We unclear refine refine to their whattheir extentstaticstatic propagatedanalysisanalysis andand vulnerabilities considerconsider a325× a325 largerlarger may Insight 4. In addition to C/C++, various other languages are com- Insight 4. In addition to C/C++, various other languages are com- dataset.dataset.affect real-world For For characteristics characteristics WebAssembly (ii) (ii) and and binaries. (iii), (iii), this this work work is is the the first first toto sys-sys- piled to WebAssembly, including languages with garbage collection piled to WebAssembly, including languages with garbage collection tematicallytematicallyWe address evaluate evaluate this question their their prevalence prevalence by studying in in real-worldthree real-world important WebAssembly WebAssembly character- and heavier runtimes (Go, Matlab). This result matches WebAssem- and heavier runtimes (Go, Matlab). This result matches WebAssem- binaries.binaries.istic of binaries We We study study that all all attackers binaries, binaries, can irrespective irrespective abuse: (i) ofof uses the the of source source the unmanaged language, language, bly’s goal of serving as a universal bytecode. It also means binary bly’s goal of serving as a universal bytecode. It also means binary becausebecausestack, i.e., the the an problem problem unprotected of of propagated propagated representation vulnerabilities vulnerabilities of the function may may affect affect stack in allall analysis will become more important, since source code is not al- analysis will become more important, since source code is not al- languageslanguagesWebAssembly’s with with memory-unsafe memory-unsafe linear memory (Section behavior, behavior, 2), in in which particular particular attackers C, C, C++, C++, can but butuse ways available, and even if it is, implementing separate analyses ways available, and even if it is, implementing separate analyses also,also,for stack-based e.g., e.g., Rust, Rust, as as buffer its itsunsafeunsafe overflowskeywordkeyword and is is commonly commonly stack overflows used used [ [77]] and and(Section can can 4.4.1); for many languages is impractical. for many languages is impractical. causecause(ii) unsafe memory-safety memory-safety memory allocators related related vulnerabilities vulnerabilities compiled into [46]. [46]. a binary, which at- We also analyze the tools used to produce the binaries. For 20.2% tackers can abuse as a memory write primitive (Section 4.4.2); and We also analyze the tools used to produce the binaries. For 20.2% 4.4.14.4.1 Usage Usage of of the the Unmanaged Unmanaged Stack. Stack. The so-called “unmanaged of the binaries, the producers section explicitly mentions them in (iii) accesses to potentially dangerous APIs imported from the host ofof the the binaries, binaries, the the producers producers section section explicitly explicitly mentions mentions them them in in stack”stack” is is a a region region within within the the linear linear memory memory of of a a WebAssembly WebAssembly the processed-by field. 10.8% of all binaries explicitly mention being environment (Section 4.4.3). For (i) [18] reports results on 26 bina- thetheprocessed-byprocessed-byfield.field. 10.8%10.8% of of allall binariesbinaries explicitlyexplicitly mentionmention being being programprogram that that holds, holds, e.g., e.g., non-primitive non-primitive data data with with function function livetime. livetime. produced by Clang. No binaries mention Emscripten because it does ries only. We refine their static analysis and consider a325× larger producedproduced by by Clang. Clang. No No binaries binaries mention mention Emscripten Emscripten because because it it does does This design is motivated by the fact that all non-scalar data and all not emit a producer section, unlike newer versions of Clang. These dataset. For characteristics (ii) and (iii), this work is the first to sys- notnot emit emit a a producerproducer section,section, unlike unlike newer newer versions versions of of Clang. Clang. These These datadata of of which which an an address address is is taken taken cannot cannot be be put put in in WebAssembly’s WebAssembly’s results show that Emscripten is no longer the only way to compile tematically evaluate their prevalence in real-world WebAssembly resultsresults show show that that Emscripten Emscripten is is no no longer longer the the only only way way to to compile compile localslocals or or globals, globals, but but must must instead instead reside reside in in linear linear memory. memory. Given Given C and C++ to WebAssembly. Other tools that appear in the producer binaries. We study all binaries, irrespective of the source language, C and C++ to WebAssembly. Other tools12 that appear in the producerproducer thatthatbecause buffer buffer the overflows overflows problem of on on propagated thethe unmanagedunmanaged vulnerabilities stackstack can canmay overwriteoverwrite affect all across across section are rustc (9.5%), wasm-bindgen1212 (7.9%), a JavaScript host- sectionsection are are rustcrustc (9.5%),(9.5%), wasm-bindgenwasm-bindgen13 (7.9%),(7.9%), a a JavaScript JavaScript host- host- stackstacklanguages frames frames with and and memory-unsafe even even into into supposedly supposedly behavior, “constant” “constant” in particular data, data, C, this this C++, makes makes but code generator, and walrus (7.5%)13 , a binary transformation library, codecode generator, generator, and andwalruswalrus(7.5%)(7.5%)13,, a a binary binary transformation transformation library, library, thethe unmanaged unmanaged stack stack a a more more dangerous dangerous exploitation exploitation target target than than and the official Go compiler (0.4%). Since all compilers for Rust,C, also, e.g., Rust, as its unsafe keyword is commonly used [7] and can andand the the official official Go Go compilercompiler (0.4%).(0.4%). SinceSince allall compilerscompilers forfor Rust,C, Rust,C, eveneven in in native native programs programs [ [1818].]. For For this this reason, reason, we we evaluate evaluate how how and C++ to WebAssembly are based on LLVM, we can also derive cause memory-safety related vulnerabilities [46]. andand C++ C++ to to WebAssembly WebAssembly are are based based on on LLVM, LLVM, we we can can also also derive derive many binaries use it in practice. that 79.1% of the binaries are produced with the help of LLVM. 4.4.1 Usage of the Unmanaged Stack. The so-called “unmanaged thatthat 79.1% 79.1% of of the the binaries binaries are are produced produced with with the the help help of of LLVM. LLVM. stack”Analysis. is a regionTo analyze within the the usage linear of memory the unmanaged of a WebAssembly stack, our 9https://github.com/Sable/matwably staticprogram analysis thatholds, performs e.g., two non-primitive steps. First, data it tries with to identify function the livetime. stack InsightInsight10 5. 5. Almost 80% of all binaries are compiled with the help static analysis performs two steps. First, it tries to identify the stack https://github.com/FStarLang/kremlin pointerThis design to determine is motivated whether by the a binary fact that uses all an non-scalar unmanaged data stack and allat ofof11An the the 8-bit LLVM LLVM VM language toolchain. toolchain. from This This 1970s, implies implies https://github.com/pepyakin/emchipten that that security security mitigations, mitigations, such such pointer to determine whether a binary uses an unmanaged stack at asas12https://github.com/rustwasm/wasm-bindgen stack stack canaries, canaries, would would have have a a large large effect effect onon thethe ecosystemecosystem if if all.all.data Out Out of whichof of all all global global an address variables, variables, is taken the the cannot analysis analysis be selects selects put in the the WebAssembly’s one one that that 13 implementedimplementedhttps://github.com/rustwasm/walrus in in this this toolchain. toolchain. •locals• hashas typeor type globals,i32i32,, i.e., i.e., but the the must type type instead of of all all pointers, pointers, reside in linear memory. Given •• isis declared declared mutable, mutable, to to exclude exclude constants constants like like STACK_MAXSTACK_MAX,, 99https://github.com/Sable/matwablyhttps://github.com/Sable/matwably •• isis the the most most read read and and written written global, global, as as determined determined by by the the number number 1010https://github.com/FStarLang/kremlinhttps://github.com/FStarLang/kremlin of global.get × global.set instructions1414, and 11 of global.get × global.set instructions , and 11AnAn 8-bit 8-bit VM VM language language from from 1970s, 1970s,https://github.com/pepyakin/emchiptenhttps://github.com/pepyakin/emchipten 12 14 12https://github.com/rustwasm/wasm-bindgenhttps://github.com/rustwasm/wasm-bindgen 14TheThe product product of of the the counts counts prefers prefers globals globals which which are are similarly similarly often often read read and and written. written. 13 13https://github.com/rustwasm/walrushttps://github.com/rustwasm/walrus ThisThis is is true true for for the the stack stack pointer, pointer, but but not not for for other other frequently frequently accessed accessed pointers. pointers. WWW ’21, April 19–23, 2021, Ljubljana, Slovenia Aaron Hilbig, Daniel Lehmann, and Michael Pradel

100% Unknown (1,994) No loads/stores (155) No memory (167) Not enough accesses (805) 80% 23.6% Unknown, 1.8% 9.5% Emscripten (1,189) 2.0% Others (9) 60% emmalloc (11) 14.0% Stack pointer: 4.3% No mutable 0.7% Boehm GC (61) global 0 (4,216) 23.5% 40% i32 global (1,989) 0.7% wee_alloc (62) 49.8% eosio simple_malloc (368) 20% dlmalloc (1,430) 16.9% 2.0% unmanaged stack 32.7% No memory (167) 1.6%

15.2% Functions that access the 0% 1.3% eosio malloc (2,766) 0% 20% 40% 60% 80% 100% Go malloc (139) Stack pointer: others (1,284) Percentile of binaries AssemblyScript alloc (114) (a) Proportion of binaries (b) Cumulative distribution of pro- Figure 7: Allocators in binaries, multiple can apply. with identified stack pointer, portion of functions in a binary to reuse space of deallocated objects, needs to be handled by an and if not why. that use the unmanaged stack. allocator that is statically linked into the binary. Especially for bi- Figure 6: Unmanaged stack usage in binaries. naries on the web and for smart contract platforms, code size is an • has at least three reads and at least three writes, to avoid false important consideration, so developers can choose a lightweight positives in small binaries. allocator instead of the default allocator provided by the compiler. We manually validate that these heuristics identify the stack pointer Prior work has shown [18] that those smaller allocators can lack reliably on randomly sampled binaries. If the analysis cannot iden- important mitigations against heap metadata corruption and yield tify a stack pointer, it conservatively assumes that the binary does powerful arbitrary write primitives for an attacker. However, it not use an unmanaged stack. Second, once the stack pointer is remains unclear what allocators developers use in practice. identified, the analysis counts the number of functions inthebi- Analysis. To identify allocators in a binary, we rely on similar nary that access the stack pointer somewhere in their body. Our heuristics as for source language detection (Section 4.3). That is, we implementation builds upon the prototype analysis provided by 15 first identify allocators by characteristic function names in binaries, Lehmann et al. , but uses a different WebAssembly parser to also if those are available. Then, we inspect frequent strings in the data handle language extensions and makes the analysis robust enough section of binaries, e.g., for error messages of certain allocators. to run on thousands of real-world binaries. Results. Figure 7 shows our results, grouped into three categories. Results. Figure 6a shows that almost two thirds (65%) of all bina- In blue, we mark default allocators provided by programming lan- ries use the unmanaged stack. While most of them use the global guages and compilers, in different shades of red we mark other al- with index 0 as their stack pointer, our heuristics to identify the locators that we identified, and in gray when we could not identify stack pointer are important, since 15.2% of all binaries use another an allocator. In terms of default allocators, we see that 16.9% of all WWW ’21, April 19–23, 2021, Ljubljana, Sloveniaglobal variable. For 2% of the Aaron binaries, Hilbig, Danielthe analysis Lehmann, can and clearly Michael deter- Pradel binaries use dlmalloc, the default allocator provided by Emscripten, mine that they have no unmanaged stack in linear memory, simply 100% Clang, and the Rust compiler when targeting WebAssembly. Go and because there is no linearUnknown memory (1,994) atNo all. loads/stores For 23.5% (155) of the binaries, No memory (167) AssemblyScript allocators are present roughly in the proportion of Not enough accesses (805) 80% 23.6% there isUnknown, a linear memory section,1.8% but no mutable i32 global that 9.5% Emscripten (1,189) 2.0% Others (9) their respective languages. 60% emmalloc (11) could be a stack pointer.14.0% Finally, 9.5% of all binaries have at least Stack pointer: 4.3% Among the non-default allocators, two particular ones domi- No mutable 0.7% Boehm GC (61) global 0 (4,216) 23.5% 40% one candidate mutable global pointer, but it is not accessed often i32 global (1,989) 0.7% wee_alloc (62) nate, being in 32.7% and 4.3% of our binaries. They are both from 49.8% eosio simple_malloc (368) 20% enough fordlmalloc our (1,430) analysis16.9% to consider it the stack pointer. Interest-

unmanaged stack EOSIO, a smart contract platform that uses WebAssembly as its 2.0% 32.7% No memory (167) ingly, AssemblyScript programs1.6% are in the last category, since its

15.2% Functions that access the 0% 1.3% eosio malloc (2,766) bytecode. Those contracts can be written in C++ and compiled with 0% 20% 40% 60% 80% 100% runtime seemsGo malloc to not (139) support stack allocation. Stack pointer: others (1,284) Percentile of binaries AssemblyScript alloc (114) Emscripten. However, most of them are not using Emscripten’s To better understand how much a binary uses the unmanaged default allocator. While we did not perform an in-depth security (a) Proportion of binaries (b) Cumulative distribution of pro- stack,Figure Figure 7: 6b Allocators shows how in manybinaries, of the multiple functions can in apply. a binary with identified stack pointer, portion of functions in a binary analysis of EOSIO malloc and simple_malloc we can attest that both accessin 35% the of all stack binaries pointer no at function least once. uses Consistent the stack pointer with Figure because 6a, and if not why. that use the unmanaged stack. are considerably shorter in terms of code and do not feature any innone 35% is of present. all binaries In the no median function binary, uses already the stack 33% pointer of all functions because assertions that would guard against metadata corruption. In our Figure 6: Unmanaged stack usage in binaries. none is present. In the median binary, already 33% of all functions use the stack pointer, and in some binaries almost every function dataset, we also find wee_alloc (62 binaries) and emmalloc (11 bi- that buffer overflows on the unmanaged stack can overwrite across useuses the the stack unmanaged pointer, stack. and in On some average binaries across almost all binaries every functionwith an naries), two small allocators for Rust and Emscripten respectively, stack frames and even into supposedly “constant” data, this makes usesunmanaged the unmanaged stack, 44% stack. of their On average functions across make all use binaries of it. with an that were already found to be vulnerable against heap metadata the unmanaged stack a more dangerous exploitation target than unmanaged stack, 44% of their functions make use of it. corruption attacks [18]. Other interesting custom allocators are even in native programs [18]. For this reason, we evaluate how Insight 6. Many binaries (65%) and functions in those binaries Boehm GC (a mark-and-sweep garbage collector) and gperftools, many binaries use it in practice. (44%) use the unmanaged stack, which attackers may abuse for in several binaries collected from Google domains. Analysis. To analyze the usage of the unmanaged stack, our runtime exploitation. This result extends earlier findings [18] to a Insight 7. WebAssembly binaries come with a variety of memory static analysis performs two steps. First, it tries to identify the stack much larger and more diverse set of real-world binaries. allocators, including many custom allocators (38.6%), increasing pointer to determine whether a binary uses an unmanaged stack at the risk to include vulnerable allocators. If code size is the motiva- all. Out of all global variables, the analysis selects the one that 4.4.2 Statically Linked Allocators. WebAssembly’s memory orga- 4.4.2 Statically Linked Allocators. WebAssembly’s memory orga- tion to use custom allocators, a more secure alternative could be a nization is very low-level. Besides the single linear memory section, • has type i32, i.e., the type of all pointers, nization is very low-level. Besides the single linear memory section, memory allocation or garbage collection API provided by the host which can be expanded at runtime with the memory.growmemory.growinstruc- • is declared mutable, to exclude constants like STACK_MAX, which can be expanded at runtime with the instruc- environment [33]. • is the most read and written global, as determined by the tion,tion, no no help help with with allocating allocating memory memory is is provided provided by by the the language. language. × 14 SubdividingSubdividing the the linear linear memory, memory, e.g., e.g., to to avoid avoid fragmentation fragmentation and and number of global.get global.set instructions , and 4.4.3 Imports of Security-Critical APIs from Host Environment. To • to reuse space of deallocated objects, needs to be handled by an has at least three reads and at least three writes, to avoid 15https://github.com/sola-st/wasm-binary-security exploit a WebAssembly binary, an attack proceeds in two steps. The false positives in small binaries. allocator that is statically linked into the binary. Especially for bi- We manually validate that these heuristics identify the stack pointer naries on the web and for smart contract platforms, code size is an reliably on randomly sampled binaries. If the analysis cannot iden- important consideration, so developers can choose a lightweight tify a stack pointer, it conservatively assumes that the binary does allocator instead of the default allocator provided by the compiler. not use an unmanaged stack. Second, once the stack pointer is Prior work has shown [18] that those smaller allocators can lack identified, the analysis counts the number of functions inthebi- important mitigations against heap metadata corruption and yield nary that access the stack pointer somewhere in their body. Our powerful arbitrary write primitives for an attacker. However, it implementation builds upon the prototype analysis provided by remains unclear what allocators developers use in practice. Lehmann et al.15, but uses a different WebAssembly parser to also Analysis. To identify allocators in a binary, we rely on similar handle language extensions and makes the analysis robust enough heuristics as for source language detection (Section 4.3). That is, we to run on thousands of real-world binaries. first identify allocators by characteristic function names in binaries, Results. Figure 6a shows that almost two thirds (65%) of all bina- if those are available. Then, we inspect frequent strings in the data ries use the unmanaged stack. While most of them use the global section of binaries, e.g., for error messages of certain allocators. with index 0 as their stack pointer, our heuristics to identify the Results. Figure 7 shows our results, grouped into three categories. stack pointer are important, since 15.2% of all binaries use another In blue, we mark default allocators provided by programming lan- global variable. For 2% of the binaries, the analysis can clearly deter- guages and compilers, in different shades of red we mark other al- mine that they have no unmanaged stack in linear memory, simply locators that we identified, and in gray when we could not identify because there is no linear memory at all. For 23.5% of the binaries, an allocator. In terms of default allocators, we see that 16.9% of all there is a linear memory section, but no mutable i32 global that binaries use dlmalloc, the default allocator provided by Emscripten, could be a stack pointer. Finally, 9.5% of all binaries have at least Clang, and the Rust compiler when targeting WebAssembly. Go and one candidate mutable global pointer, but it is not accessed often AssemblyScript allocators are present roughly in the proportion of enough for our analysis to consider it the stack pointer. Interest- their respective languages. ingly, AssemblyScript programs are in the last category, since its Among the non-default allocators, two particular ones domi- runtime seems to not support stack allocation. nate, being in 32.7% and 4.3% of our binaries. They are both from To better understand how much a binary uses the unmanaged EOSIO, a smart contract platform that uses WebAssembly as its stack, Figure 6b shows how many of the functions in a binary bytecode. Those contracts can be written in C++ and compiled with access the stack pointer at least once. Consistent with Figure 6a, Emscripten. However, most of them are not using Emscripten’s default allocator. While we did not perform an in-depth security 14The product of the counts prefers globals which are similarly often read and written. This is true for the stack pointer, but not for other frequently accessed pointers. analysis of EOSIO malloc and simple_malloc we can attest that both 15https://github.com/sola-st/wasm-binary-security are considerably shorter in terms of code and do not feature any WWW ’21, April 19–23, 2021, Ljubljana, Slovenia Aaron Hilbig, Daniel Lehmann, and Michael Pradel

100% Unknown (1,994) No loads/stores (155) No memory (167) Not enough accesses (805) 80% 23.6% Unknown, 1.8% 9.5% Emscripten (1,189) 2.0% Others (9) 60% emmalloc (11) 14.0% Stack pointer: 4.3% No mutable 0.7% Boehm GC (61) global 0 (4,216) 23.5% 40% i32 global (1,989) 0.7% wee_alloc (62) 49.8% eosio simple_malloc (368) 20% dlmalloc (1,430) 16.9% 2.0% unmanaged stack 32.7% No memory (167) 1.6%

15.2% Functions that access the 0% 1.3% eosio malloc (2,766) 0% 20% 40% 60% 80% 100% Go malloc (139) Stack pointer: others (1,284) Percentile of binaries AssemblyScript alloc (114) (a) Proportion of binaries (b) Cumulative distribution of pro- Figure 7: Allocators in binaries, multiple can apply. with identified stack pointer, portion of functions in a binary to reuse space of deallocated objects, needs to be handled by an and if not why. that use the unmanaged stack. allocator that is statically linked into the binary. Especially for bi- Figure 6: Unmanaged stack usage in binaries. naries on the web and for smart contract platforms, code size is an • has at least three reads and at least three writes, to avoid false important consideration, so developers can choose a lightweight positives in small binaries. allocator instead of the default allocator provided by the compiler. We manually validate that these heuristics identify the stack pointer Prior work has shown [18] that those smaller allocators can lack reliably on randomly sampled binaries. If the analysis cannot iden- important mitigations against heap metadata corruption and yield tify a stack pointer, it conservatively assumes that the binary does powerful arbitrary write primitives for an attacker. However, it not use an unmanaged stack. Second, once the stack pointer is remains unclear what allocators developers use in practice. identified, the analysis counts the number of functions inthebi- Analysis. To identify allocators in a binary, we rely on similar nary that access the stack pointer somewhere in their body. Our heuristics as for source language detection (Section 4.3). That is, we implementation builds upon the prototype analysis provided by 15 first identify allocators by characteristic function names in binaries, Lehmann et al. , but uses a different WebAssembly parser to also if those are available. Then, we inspect frequent strings in the data handle language extensions and makes the analysis robust enough section of binaries, e.g., for error messages of certain allocators. to run on thousands of real-world binaries. Results. Figure 7 shows our results, grouped into three categories. Results. Figure 6a shows that almost two thirds (65%) of all bina- In blue, we mark default allocators provided by programming lan- ries use the unmanaged stack. While most of them use the global guages and compilers, in different shades of red we mark other al- with index 0 as their stack pointer, our heuristics to identify the locators that we identified, and in gray when we could not identify stack pointer are important, since 15.2% of all binaries use another an allocator. In terms of default allocators, we see that 16.9% of all global variable. For 2% of the binaries, the analysis can clearly deter- binaries use dlmalloc, the default allocator provided by Emscripten, mine that they have no unmanaged stack in linear memory, simply Clang, and the Rust compiler when targeting WebAssembly. Go and because there is no linear memory at all. For 23.5% of the binaries, AssemblyScript allocators are present roughly in the proportion of i32 there is a linear memory section, but no mutable global that their respective languages. could be a stack pointer. Finally, 9.5% of all binaries have at least Among the non-default allocators, two particular ones domi- one candidate mutable global pointer, but it is not accessed often nate, being in 32.7% and 4.3% of our binaries. They are both from enough for our analysis to consider it the stack pointer. Interest- EOSIO, a smart contract platform that uses WebAssembly as its ingly, AssemblyScript programs are in the last category, since its bytecode. Those contracts can be written in C++ and compiled with runtime seems to not support stack allocation. Emscripten. However, most of them are not using Emscripten’s To better understand how much a binary uses the unmanaged defaultAn Empirical allocator. Study of While Real-World we WebAssembly did not perform Binaries an in-depth security WWW ’21, April 19–23, 2021, Ljubljana, Slovenia stack, Figure 6b shows how many of the functions in a binary analysis of EOSIO malloc and simple_malloc we can attest that both access the stack pointer at least once. Consistent with Figure 6a, Table 3: Imports matching potentially security-critical APIs. areassertions considerably that would shorter guard in terms against of code metadata and do corruption. not feature In any our in 35% of all binaries no function uses the stack pointer because assertions that would guard against metadata corruption. In our Matching none is present. In the median binary, already 33% of all functions dataset, we also find wee_alloc (62 binaries) and emmalloc (11 bi- Category Patterns dataset,naries), twowe also small find allocatorswee_alloc for(62 Rust binaries) and Emscripten and emmalloc respectively,(11 bi- Imports Binaries % use the stack pointer, and in some binaries almost every function naries), two small allocators for Rust and Emscripten respectively, that were already found to be vulnerable against heap metadata Code execution eval, exec, execve 383 160 1.9% uses the unmanaged stack. On average across all binaries with an that were already found to be vulnerable against heap metadata unmanaged stack, 44% of their functions make use of it. corruption attacks [18]. Other interesting custom allocators are emscripten_run_script corruptionBoehm GC attacks (a mark-and-sweep [18]. Other interesting garbage collector) custom and allocators gperftools, are Network access xhr, request, http, fetch 944 172 2.0% Insight 6. Many binaries (65%) and functions in those binaries Boehmin several GC binaries (a mark-and-sweep collected from garbage Google collector) domains. and gperftools, File I/O file, fd, path 7,532 1,610 19.0% (44%) use the unmanaged stack, which attackers may abuse for in several binaries collected from Google domains. DOM interaction document, html, body, element 1,720 212 2.5% runtime exploitation. This result extends earlier findings [18] to a Dynamic linking dlopen, dlsym, dlclose 352 138 1.6% Insight 7. WebAssembly binaries come with a variety of memory much larger and more diverse set of real-world binaries. allocators, including many custom allocators (38.6%), increasing At least one 10,468 1,797 21.2% the risk to include vulnerable allocators. If code size is the motiva- 4.4.2 Statically Linked Allocators. WebAssembly’s memory orga- tion to use custom allocators, a more secure alternative could be a nization is very low-level. Besides the single linear memory section, bufdelete does not. We manually inspect matches to ensure they memory allocation or garbage collection API provided by the host which can be expanded at runtime with the memory.grow instruc- are plausible and remove benign matches otherwise. environment [33]. tion, no help with allocating memory is provided by the language. Results. Table 3 shows the results of our name-based import Subdividing the linear memory, e.g., to avoid fragmentation and 4.4.34.4.3 Imports Imports of of Security-Critical Security-Critical APIs APIs from from Host Host Environment. Environment. ToTo analysis. The first two columns show the category and patterns 15https://github.com/sola-st/wasm-binary-security exploitexploit a a WebAssembly WebAssembly binary, binary, an an attack attack proceeds proceeds in in two two steps. steps. The The we match import names against. In the third column, we count first step is compromising the state or behavior of the WebAssembly imported functions that match at least one pattern. The last two Anbinary Empirical itself, Study e.g., of Real-World by exploiting WebAssembly an unsafe Binaries allocator (Section 4.4.2) columns show the number WWWof binaries ’21, April with 19–23, at 2021, least Ljubljana, one matching Slovenia or a buffer overflow on the unmanaged stack (Section 4.4.1). The Table 3: Imports matching potentially security-critical APIs. import, and which fraction of the filtered dataset this corresponds to. second step is actually performing the malicious action to the un- import,We see thatand which imports fraction related of to the file filtered I/O, datasetthe most this commoncorresponds category, to. Matching derlying system. The only way to do so, assuming VM implementa- Weare seepresent that in imports almost related every fifthto file binary. I/O, theInterestingly, most common even category,though Category Patterns 16 tions are bug-free and host security is perfectImports (which Binaries they are not % areWebAssembly present in almost was originally every fifth not meantbinary. to Interestingly, replace JavaScript, even but though [1, 36]), is to call functions imported into the WebAssembly binary eval, exec, execve WebAssemblyrather for compute was originally intensive notapplications, meant to stillreplace 212 JavaScript, binaries likely but Code execution 383 160 1.9% from the host environment.emscripten_run_script For example, an attacker could pass an ratherinteract for with compute the DOM intensive from WebAssembly, applications, still which 212 attackers binaries likely could Networkinjected access string onxhr the, request unmanaged, http, fetch stack to an944 imported 172 function, 2.0% interactuse for cross-site with thescripting. DOM from In WebAssembly, the last row, we which see that attackers overall could21.2% Filee.g., I/O JavaScript’s evalfile., Tofd, estimatepath how often WebAssembly7,532 1,610 binaries 19.0% useof all for binaries cross-site import scripting. at least In theone last potentially row, we seesecurity-critical that overall 21.2% API. DOMuse such interaction security-criticaldocument, hosthtml, APIs,body, element we thus analyze1,720 their 212 imports. 2.5% of all binaries import at least one potentially security-critical API. Dynamic linking dlopen, dlsym, dlclose 352 138 1.6% Analysis. We identify imported security-critical APIs based on Insight 8. Many binaries (21.2%) import potentially dangerous At least one 10,468 1,797 21.2% their import name in the WebAssembly binary. Going by name APIs from their host environment, which may allow compromised (instead of implementation) is necessary because, (1) the imple- binaries, e.g., to inject arbitrary code or to write to the file system. firstmentation step is of ancompromising imported function the state is suppliedor behavior by the of hostthe WebAssembly only binaryat instantiation-time, itself, e.g., by exploiting so it is not an available unsafe allocator when given (Section only 4.4.2) the orbinary; a buffer and (2) overflow there are on many the host unmanaged environments, stack not (Section all of which 4.4.1). The 4.5 RQ3: Cryptomining second step is actually performing the malicious action to the un- are using JavaScript. WASI for example, defines imports that can A study of real-world uses of WebAssembly performed in early derlying system. The only way to do so, assuming VM implementa- be implemented by different standalone WebAssembly VMs in na- 2019 [24] reports cryptomining to be one of the most common use tions are bug-free and host security16 is perfect (which they are not tive code. We thus identify import names for which the host im- cases of WebAssembly on the web. That study found 55.7% of the [1, 36]), is to call functions imported into the WebAssembly binary plementation is likely a security-critical function. E.g., the import analyzed websites to use WebAssembly for cryptojacking, i.e., the from the host environment. For example, an attacker could pass an emscripten_run_script in WebAssembly binaries is typically bound practice of using a website visitor’s hardware resources for mining injected string on the unmanaged stack to an imported function, to Emscripten-generated JavaScript code that calls eval. We match cryptocurrencies without their consent. Identifying and controlling e.g., JavaScript’s eval. To estimate how often WebAssembly binaries imports against 18 patterns in five categories known to be poten- cryptominers on the web has been the focus of several recent pieces use such security-critical host APIs, we thus analyze their imports. tially security-critical APIs: of work [15,, 25,, 34,, 43]. In this research question, we study whether Analysis.• Code executionWe identify. Imports imported like eval security-critical, exec, or emscripten_run_script APIs based on . cryptomining is still an important threat today. We address this their• importNetwork name access in. the Imports WebAssembly containing binary.XHR, request Going, byhttp name, or question in two ways. First, we analyze those binaries we collected (insteadfetch of implementation). is necessary because, (1) the imple- from the web for signs of being cryptominers. Second, we directly mentation• File I/O of. an Imports imported containing functionfile is, suppliedfd, or path by. the host only compare the binaries gathered in earlier work with our dataset. at instantiation-time,• DOM interaction so. Imports it is not containing availabledocument when given, html only, body the, or 4.5.1 Analyzing Binaries Found on the Web. To understand the 4.5.1 Analyzing Binaries Found on the Web. To understand the binary;element and (2) therecould are manipulate many host the environments, DOM, which notcan all lead of to which XSS. prevalence of cryptomining today, we analyze all binaries collected prevalence of cryptomining today, we analyze all binaries collected are using• Dynamic JavaScript. linking WASI. dlopen for, example,dlsym, and definesdlclose importsallow loading that can from the web, i.e., direct downloads guided by HTTP Archive and from the web, i.e., direct downloads guided by HTTP Archive and be implementedadditional by code different at runtime, standalone which can leadWebAssembly to code injection. VMs in na- the results of our own crawling, using VirusTotal. The VirusTotal the results of our own crawling, using VirusTotal. The VirusTotal tive code. We thus identify import names for which the host im- API allows to upload and scan files with up to 70 independent third- To avoid spurious matches, especially for short patterns like fd, API allows to upload and scan files with up to 70 independent third- plementation is likely a security-critical function. E.g., the import party antivirus scanners and malware detectors, and reports back we tokenize import names based on camel-case and non-alphabet party antivirus scanners and malware detectors, and reports back emscripten_run_script in WebAssembly binaries is typically bound the number of positive results. Among the 352 analyzed binaries, characters, and then check for a pattern to occur verbatim in the the number of positive results. Among the 352 analyzed binaries, to Emscripten-generated JavaScript code that calls eval. We match VirusTotal reports four files to contain malicious content. Three of token sequence. E.g., fd_write matches our file I/O category, but VirusTotal reports four files to contain malicious content. Three of imports against 18 patterns in five categories known to be poten- them are likely to be the same program, as they have similar sizes 16 them are likely to be the same program, as they have similar sizes tiallyHost security-criticalsecurity: isolation of APIs: WebAssembly execution from the underlying host, e.g., (68.8±0.7kB) and the same distribution of instructions. These three ensuring that a WebAssembly program can write only to its designated memory region. (68.8±0.7kB) and the same distribution of instructions. These three • Code execution. Imports like eval, exec, or emscripten_run_script. files are detected by 26 or more scanning tools employed byVirus- • Network access. Imports containing XHR, request, http, or fetch. Total. One of the files is collected from http://monero.cit.net, • File I/O. Imports containing file, fd, or path. which further supports the presumption that the binary is a cryp- • DOM interaction. Imports containing document, html, body, or tominer, as “Monero” is the name of a common cryptocurreny. element could manipulate the DOM, which can lead to XSS. Moreover, one of three binaries is identical to a binary we collect • Dynamic linking. dlopen, dlsym, and dlclose allow loading addi- also from a GitHub repository called “CryptoNoter”17, which is an tional code at runtime, which can lead to code injection. open-source Monero cryptominer. The fourth file reported by Virus- To avoid spurious matches, especially for short patterns like fd, Total is tested positive by only one scanner. Our manual analysis we tokenize import names based on camel-case and non-alphabet shows that the report for this binary is likely to be a false positive. characters, and then check for a pattern to occur verbatim in the 4.5.2 Comparison with Dataset by Musch et al. [24]. The previous token sequence. E.g., fd_write matches our file I/O category, but study is based on 147 unique WebAssembly binaries, which the bufdelete does not. We manually inspect matches to ensure they authors kindly shared with us. The intersection of their dataset are plausible and remove benign matches otherwise. with ours contains 23 binaries, i.e., 16% of their dataset and 0.2% Results. Table 3 shows the results of our name-based import of our dataset. To better understand these binaries, we manually analysis. The first two columns show the category and patterns examine them and visit the corresponding websites. We find four we match import names against. In the third column, we count of the 23 binaries to be suspicious. Two of them are among the files imported functions that match at least one pattern. The last two flagged by VirusTotal, as discussed above. For one file from awebsite columns show the number of binaries with at least one matching that declares itself to be a “blockchain explorer”, we could not observe any suspicious activity when visiting the source website, 16Host security: isolation of WebAssembly execution from the underlying host, e.g., ensuring that a WebAssembly program can write only to its designated memory region. 17https://github.com/JayWalker512/CryptoNoter WWW ’21, April 19–23, 2021, Ljubljana, Slovenia Aaron Hilbig, Daniel Lehmann, and Michael Pradel

Other files are detected by 26 or more scanning tools employed byVirus- 300 Test for WebAssembly support Total. One of the files is collected from http://monero.cit.net, which Hyphenopoly 200 further supports the presumption that the binary is a cryptominer, Long.js as “Monero” is the name of a common cryptocurreny. Moreover, 100 one of three binaries is identical to a binary we collect also from a Number of domains 0 17 0 10 20 30 40 GitHub repository called “CryptoNoter” , which is an open-source Unique binaries, orderd by number of occurrences Monero cryptominer. The fourth file reported by VirusTotal is tested Figure 8: Binaries found on multiple websites. positive by only one scanner. Our manual analysis shows that the websites, which helps understand libraries and other widely reused report for this binary is likely to be a false positive. components (Section 4.6.1). Second, we inspect a random sample 4.5.2 Comparison with Dataset by Musch et al. [24]. The previous WWW ’21, April 19–23, 2021, Ljubljana, Sloveniaof 100 unique binaries, which Aaron Hilbig, helps Daniel understand Lehmann, andthe Michael application Pradel study is based on 147 unique WebAssembly binaries, which the domains of WebAssembly (Section 4.6.2). To capture the full picture authors kindly shared with us. TheOther intersection of their dataset Tableof WebAssembly 4: Application use cases, domains the results of 100are on randomly unfiltered sampled, binaries. with ours300 contains 23 binaries, i.e.,Test 16% forof WebAssembly their dataset support and 0.2% unique WebAssembly binaries found on the web. Hyphenopoly 4.6.1 Binaries Found on Multiple Websites. Out of all 476 unique of our dataset.200 To better understand these binaries, we manually Long.js binariesApplication found domain on the # web, Binaries 70 are reusedApplication across domain at least # two Binaries differ- examine them and visit the corresponding websites. We find four ent top-level domains. Figure 8 shows a histogram of how often of the 23100 binaries to be suspicious. Two of them are among the files Games 25 Online gambling 2

Number of domains binariesText processing occur on multiple domains. 11 Barcodes The data and follows QR codes a long-tail dis-2 flagged 0by VirusTotal, as discussed above. For one file from awebsite 0 10 20 30 40 tribution,Visualization i.e., / a Animation few binaries 11 occur onRoom many planning websites, / Furniture while many 2 that declares itself to be a “blockchain explorer”, we could not Unique binaries, orderd by number of occurrences otherMedia binaries processing recur / Player a few times 9 or onlyBlogging once. The top-most widely 2 observeFigure any suspicious 8: Binaries activity found when on multiple visiting the websites. source website, distributedDemo, e.g., binary of a occurs 371 times,Cryptocurrency i.e., in 28% of all wallet domains where 2 but also could not identify its functionality, and thus declare it to be 7 but also could not identify its functionality, and thus declare it to be weprogramming detect WebAssembly language binaries. Regular expressions 1 suspicious. For the last suspicious binary, visiting the corresponding Wasm tutorial or test 5 Hashing 1 suspicious. For the last suspicious binary, visiting the corresponding To better understand the most recurring binaries, we analyze website increases CPU load to 70%. The website offers a service to Chat 3 PDF viewer 1 them through a combination of automated clustering and manual websitemine cryptocurrency increases CPU and load openly to 70%. advertises The website the offers fact that a service one can to inspection. The automated clustering represents each binary as minestart miningcryptocurrency immediately and openlyin the browser. advertises That the is, fact the that binary one is can an a set of byte n-grams [21], summarizes the number of n-gram startexample mining of cryptomining immediately inbut the not browser. cryptojacking. That is, the binary is an To better understand the most recurring binaries, we analyze example of cryptomining but not cryptojacking. themoccurrences through in a a combination binary into a characteristic of automated vector, clustering and thenand manual clusters In summary, we identify only four binaries from our “web” dataset inspection.binaries based The on automated the pairwise clustering cosine similarity represents of their each vectors. binary We as In summary, we identify only four binaries from our “web” dataset as possible cryptominers (about 1% of the dataset), three of which athen set inspect of byte the n-grams top-most [21 binaries], summarizes in Figure the 8, usingnumber the of clusters n-gram to as possible cryptominers (about 1% of the dataset), three of which appeared to be inactive when visiting the website. While our analy- occurrencesquickly identify in a binary variants into of athe characteristic same binary. vector, Our analysis and then shows clusters the appeared to be inactive when visiting the website. While our analy- sis may miss cryptomining binaries, a risk one could reduce through binariesfollowing based to be on the the most pairwise widely cosine occurring similarity WebAssembly of their vectors. binaries. We sis may miss cryptomining binaries, a risk one could reduce through additional analysis techniques beyond those provided via VirusTo- then inspect the top-most binaries in Figure 8, using the clusters to additional analysis techniques beyond those provided via VirusTo- Testing for WebAssembly support. At least 509 domains (38.5% tal [24, 43], the prevalence of cryptomining seems to have dropped quickly identify variants of the same binary. Our analysis shows the tal [24, 43], the prevalence of cryptomining seems to have dropped of all domains that use WebAssembly) are serving a WebAssembly significantly over the past one to two years. This result isalso followingbinary that to tests be the whether most widely the browser occurring supports WebAssembly WebAssembly binaries. at significantlyconfirmed by over a themanual past analysis one to of two WebAssembly years. This binariesresult isalso found all.Testing We found for WebAssembly two variants support. of suchAt binaries, least 509 both domains of which (38.5% are confirmedon the web (Sectionby a manual 4.6.2) and analysis is in line of with WebAssembly other reports binaries [42] found ofrather all domains small: a that six instruction use WebAssembly) binary with are serving a single a function WebAssembly called onthat the cryptomining web (Section became 4.6.2) and less is appealing in line with after other one ofreports the major [42] binarytest and that an tests eight whether byte binary the thatbrowser only supports contains theWebAssembly WebAssembly at thatcryptomining cryptomining script became providers, less Coinhive, appealing shut after down. one of Varlioglu the major et all.magic We number found two followed variants by the of language such binaries, version. both Websites of which serving are cryptominingal. find a 99% script decrease providers, in sites Coinhive, using shut cryptomining down. Varlioglu among et sites ratherthese test small: binaries a six instruction often also binary serve larger with a binaries, single function i.e., they called first al.that find had made a 99% use decrease of it before. in sites The lowusing numbers cryptomining of cryptominers among sites testtest whetherand an eight WebAssembly byte binary is that supported, only contains and if the it is, WebAssembly load a more thatfound had by made our analysis use of it confirms before. The this low trend numbers and of shows cryptominers its declining magiccomplex number binary. followed For example, by the at language least 397 version. domains Websites that serve serving a test foundinfluence by our on analysis the WebAssembly confirms this ecosystem. trend and shows its declining influence on the WebAssembly ecosystem. thesebinary test also binaries serve the often Hyphenopoly also serve largerlibrary binaries, discussed i.e., next. they first testHyphenopoly. whether WebAssemblyAt least 462 is domains supported, (34.9% and of ifall it domains is, loadthat a more use Insight 9. We find WebAssembly-based cryptominers to have complexWebAssembly) binary. serveFor example, binaries at that least are 397 part domains of the thatHyphenopoly.js serve a test significantly dropped in importance compared to the results of binaryJavaScript also library, serve the which Hyphenopoly uses WebAssembly library discussed to implement next. its core an earlier study [24]. This finding motivates security research to functionality.Hyphenopoly. HyphenopolyAt least 462 is domains a polyfill (34.9% that of all“hyphenates domains that text use if the shift the focus from malicious WebAssembly to vulnerabilities in user agent does not support CSS-hyphenation”.18 Our clustering WebAssembly binaries. WebAssembly) serve binaries that are part of the Hyphenopoly.js JavaScriptidentifies library, 24 variants which uses of this WebAssembly binary, which to implement are all itsgenerated core from the same underlying library to support different natural languages. 4.6 RQ4: Use Cases on the Web functionality. Hyphenopoly is a polyfill that “hyphenates text if the 4.6 RQ4: Use Cases on the Web user64-bit agent integer does notarithmetic support in CSS-hyphenation”. long.js. At least 33118 domainsOur clustering (25% of GivenGiven the the decreased decreased prevalence prevalence of of cryptominers, cryptominers, we we study study what what identifiesall domains that24 variants use WebAssembly) of this binary, serve whicha binary are that all is generated part of from 19 otherother use use cases cases WebAssembly WebAssembly has. has. The The following following focuses focuses on on the the thelong.js same, a underlying JavaScript library library for to support 64-bit integer different computations. natural languages.The webweb because because it it is is the the most most prominent prominent target target platform platform of of WebAs- WebAs- library is commonly used in video players. sembly and because websites are complete applications that we can 64-bit integer arithmetic in long.js. At least 331 domains (25% of sembly and because websites are complete applications that we can Draco library for 3D data compression. At least 25 domains (1.8% manually analyze with reasonable effort. We address the question all domains that use WebAssembly) serve a binary that is part of manually analyze with reasonable effort. We address the question long.jsof all domains, a JavaScript that use library WebAssembly) for 64-bit integer serve a binarycomputations. that belongs19 The to inin two two ways. ways. First, First, we we study study binaries binaries that that occur occur across across multiple multiple library18https://github.com/mnater/Hyphenopoly is commonly used in video players. websites,17https://github.com/JayWalker512/CryptoNoter which helps understand libraries and other widely reused 19https://github.com/dcodeIO/long.js components (Section 4.6.1). Second, we inspect a random sample Draco library for 3D data compression. At least 25 domains (1.8% of 100 unique binaries, which helps understand the application of all domains that use WebAssembly) serve a binary that belongs to the Draco library, which support compressing and decompressing domains of WebAssembly (Section 4.6.2). To capture the full picture 20 of WebAssembly use cases, the results are on unfiltered binaries. 3D data. These binaries commonly occur on websites with 3D demos or integrated 3D assets. 4.6.1 Binaries Found on Multiple Websites. Out of all 476 unique binaries found on the web, 70 are reused across at least two differ- Insight 10. The most widely occurring binaries on the web are dy- ent top-level domains. Figure 8 shows a histogram of how often namic tests for WebAssembly support and JavaScript-WebAssembly binaries occur on multiple domains. The data follows a long-tail dis- libraries that perform computation-heavy tasks. tribution, i.e., a few binaries occur on many websites, while many other binaries recur a few times or only once. The top-most widely 18https://github.com/mnater/Hyphenopoly distributed binary occurs 371 times, i.e., in 28% of all domains where 19https://github.com/dcodeIO/long.js we detect WebAssembly binaries. 20https://github.com/google/draco WWW ’21, April 19–23, 2021, Ljubljana, Slovenia Aaron Hilbig, Daniel Lehmann, and Michael Pradel

Other Table 4: Application domains of 100 randomly sampled, 300 Test for WebAssembly support unique WebAssembly binaries found on the web. Hyphenopoly 200 Long.js Application domain # Binaries Application domain # Binaries 100 Games 25 Online gambling 2

Number of domains Text processing 11 Barcodes and QR codes 2 0 0 10 20 30 40 Visualization / Animation 11 Room planning / Furniture 2 Unique binaries, orderd by number of occurrences Media processing / Player 9 Blogging 2 Figure 8: Binaries found on multiple websites. Demo, e.g., of a Cryptocurrency wallet 2 7 but also could not identify its functionality, and thus declare it to be programming language Regular expressions 1 Wasm tutorial or test 5 Hashing 1 suspicious. For the last suspicious binary, visiting the corresponding Chat 3 PDF viewer 1 website increases CPU load to 70%. The website offers a service to mine cryptocurrency and openly advertises the fact that one can start mining immediately in the browser. That is, the binary is an To better understand the most recurring binaries, we analyze example of cryptomining but not cryptojacking. them through a combination of automated clustering and manual inspection. The automated clustering represents each binary as In summary, we identify only four binaries from our “web” dataset a set of byte n-grams [21], summarizes the number of n-gram as possible cryptominers (about 1% of the dataset), three of which occurrences in a binary into a characteristic vector, and then clusters appeared to be inactive when visiting the website. While our analy- binaries based on the pairwise cosine similarity of their vectors. We sis may miss cryptomining binaries, a risk one could reduce through then inspect the top-most binaries in Figure 8, using the clusters to additional analysis techniques beyond those provided via VirusTo- quickly identify variants of the same binary. Our analysis shows the tal [24, 43], the prevalence of cryptomining seems to have dropped following to be the most widely occurring WebAssembly binaries. significantly over the past one to two years. This result isalso confirmed by a manual analysis of WebAssembly binaries found Testing for WebAssembly support. At least 509 domains (38.5% on the web (Section 4.6.2) and is in line with other reports [42] of all domains that use WebAssembly) are serving a WebAssembly that cryptomining became less appealing after one of the major binary that tests whether the browser supports WebAssembly at cryptomining script providers, Coinhive, shut down. Varlioglu et all. We found two variants of such binaries, both of which are al. find a 99% decrease in sites using cryptomining among sites rather small: a six instruction binary with a single function called that had made use of it before. The low numbers of cryptominers test and an eight byte binary that only contains the WebAssembly found by our analysis confirms this trend and shows its declining magic number followed by the language version. Websites serving influence on the WebAssembly ecosystem. these test binaries often also serve larger binaries, i.e., they first test whether WebAssembly is supported, and if it is, load a more Insight 9. We find WebAssembly-based cryptominers to have complex binary. For example, at least 397 domains that serve a test significantly dropped in importance compared to the results of binaryAn Empirical also Study serve of theReal-World Hyphenopoly WebAssembly library Binaries discussed next. WWW ’21, April 19–23, 2021, Ljubljana, Slovenia an earlier study [24]. This finding motivates security research to shift the focus from malicious WebAssembly to vulnerabilities in TableHyphenopoly. 4: ApplicationAt least 462domains domains of (34.9% 100 ofrandomly all domains sampled, that use WebAssembly binaries. WebAssembly)unique WebAssembly serve binaries binaries that found are part on of the the web.Hyphenopoly.js Analysis. We perform a static analysis to assess two name-related JavaScript library, which uses WebAssembly to implement its core characteristics of binaries. First, the analysis checks whether a bi- Application domain # Binaries Application domain # Binaries functionality. Hyphenopoly is a polyfill that “hyphenates text if the nary contains a names section. While by default binaries contain 4.6 RQ4: Use Cases on the Web userGames agent does not support 25 CSS-hyphenation”.Online gambling18 Our clustering 2 names only for imported and exported program elements, the op- Given the decreased prevalence of cryptominers, we study what identifiesText processing 24 variants of 11 this binary,Barcodes which and QR are codes all generated 2 from tional names section maps all function indices to identifiers. Second, other use cases WebAssembly has. The following focuses on the theVisualization same underlying / Animation library to11 supportRoom different planning /natural Furniture languages. 2 the analysis checks whether the names of imported and exported web because it is the most prominent target platform of WebAs- Media processing / Player 9 Blogging 2 names are minified. Both to save space and to obfuscate the code, Demo,64-bit e.g., integer of a arithmetic in7 long.js.CryptocurrencyAt least 331 domains wallet (25% 2 of compilers may shorten names down to single or two-letter names sembly and because websites are complete applications that we can allprogramming domains that language use WebAssembly)Regular serve expressionsa binary that is part 1 of manually analyze with reasonable effort. We address the question long.jsWasm, a tutorial JavaScript or test library for 5 64-bitHashing integer computations.19 The 1 devoid of information. The analysis considers a WebAssembly bi- in two ways. First, we study binaries that occur across multiple libraryChat is commonly used in video 3 players.PDF viewer 1 nary as minified if it contains more than ten import or export names websites, which helps understand libraries and other widely reused (to exclude small, potentially hand-written modules), but the aver- components (Section 4.6.1). Second, we inspect a random sample Draco library for 3D data compression. At least 25 domains (1.8% age length of those names is ≤ 4 (to account for some imports that of 100 unique binaries, which helps understand the application ofthe allDraco domainslibrary, that which use WebAssembly) support compressing serve a binary and decompressing that belongs to are never minified by Emscripten, thus increasing the average). the Draco20library, which support compressing and decompressing domains of WebAssembly (Section 4.6.2). To capture the full picture 3D data. These binaries commonly occur on websites with 3D Results. Our results show an interesting difference between the 3D data.20 These binaries commonly occur on websites with 3D of WebAssembly use cases, the results are on unfiltered binaries. demos or integrated 3D assets. full dataset and binaries found on the web. In the full data set, many demos or integrated 3D assets. 4.6.1 Binaries Found on Multiple Websites. Out of all 476 unique binaries contain a names section (19.6%) but only 4.1% of the binaries binaries found on the web, 70 are reused across at least two differ- Insight 10. The most widely occurring binaries on the web are dy- are minified. In contrast, among all binaries found on the web,only ent top-level domains. Figure 8 shows a histogram of how often namic tests for WebAssembly support and JavaScript-WebAssembly 13.3% contain a names section but 28.8% are minified. These results libraries that perform computation-heavy tasks. show that for a significant fraction of websites, not only minified binaries occur on multiple domains. The data follows a long-tail dis- An Empirical Study of Real-World WebAssembly Binaries WWW ’21, April 19–23, 2021, Ljubljana, Slovenia tribution, i.e., a few binaries occur on many websites, while many JavaScript code [37], but also minified WebAssembly binaries make An Empirical Study of Real-World WebAssembly Binariesit harder to understand what WWW code ’21, is April running 19–23, on 2021, the Ljubljana, client side.Slovenia other binaries recur a few times or only once. The top-most widely 184.6.2 Manual Inspection of a Random Sample. To better understand 4.6.2https://github.com/mnater/Hyphenopoly Manual Inspection of a Random Sample. To better understand Insight 12. Many WebAssembly binaries on the web (28.8%) distributed binary occurs 371 times, i.e., in 28% of all domains where 19thehttps://github.com/dcodeIO/long.js long-tail of binaries found on a few or only a single website, we we detect WebAssembly binaries. 204.6.2alsothehttps://github.com/google/draco long-tail inspect Manual a of random Inspection binaries sample found of a Random on of100 a few uniqueSample. or only binariesTo a singlebetter found website,understand on the we Insightare minified 12. Manyand doWebAssembly not contain binaries useful on names. the web To (28.8%) help security theweb.also long-tail inspect We exclude ofa random binaries binaries sample found detected on of a100 few only unique or via only the binaries aWebAssembly single found website, on topthe we areanalysts minified understand and third-party do not contain code, futureuseful work names. on decompiling To help security alsolistsweb. inspect(Section We exclude a 3.3.2) random binaries to avoid sample detected biasing of 100only the unique results via the binaries toward WebAssembly found pre-selected on thetop analystsand reverse understand engineering third-party WebAssembly code, future is needed. work on decompiling web.applicationlists (Section We exclude domains. 3.3.2) binaries to By avoid inspecting detected biasingonly the the binaries, results via the toward WebAssembly the corresponding pre-selected top and reverse engineering WebAssembly is needed. listswebsites,application (Section and domains. 3.3.2) how to the By avoid websites inspecting biasing uses the the resultsbinaries, binaries, toward the we corresponding pre-selected identify the 5 RELATED WORK applicationpurposewebsites, of and domains.84 howout of the Bythe websites inspecting 100 binaries. uses the the Table binaries, binaries, 4 summarizes the we corresponding identify thethe ap- 5WebAssembly RELATED in WORK general. WebAssembly has been formally de- purpose of 84 out of the 100 binaries. Table 4 summarizes the ap- websites,plication domains and how that the thewebsites binaries uses are the used binaries, in. The we most identify common the finedWebAssembly [10], including in general. a mechanizedWebAssembly proof of has the been soundness formally of de- its plication domains that the binaries are used in. The most common purposedomains of are 84 games, out of accountingthe 100 binaries. for a quarterTable 4 summarizesof all binaries. the Text ap- finedtype system [10], including [44]. Since a mechanized the initial version proof of of the the language, soundness several of its domains are games, accounting for a quarter of all binaries. Text plicationprocessing domains and applications that the binaries in visualization are used and in. The animation most common are also typelanguage system extensions [44]. Since have the been initial proposed version [6, of the 32, 33].language, several processing and applications in visualization and animation are also domainsrelatively are common, games, with accounting 11/100 forbinaries a quarter each. of The all remainingbinaries. Text list languageCryptomining. extensionsCryptojacking, have been proposed i.e., websites [6, 32, that 33]. use the unsus- processingrelatively common, and applications with 11/100 in visualization binaries each. and The animation remaining are also list shows the diversity of application domains WebAssembly is used pectingCryptomining. client’s computingCryptojacking, resources i.e., forwebsites mining that cryptocurrencies, use the unsus- relativelyshows the common, diversity with of application 11/100 binaries domains each. WebAssembly The remaining is used list in, ranging from online demos of programming languages, over pectinghas been client’s among computing the first resourcesapplications for of mining WebAssembly cryptocurrencies,15 [ , 25, 34]. showsin, ranging the diversity from online of application demos of domains programming WebAssembly languages, is used over support for creating and scanning barcodes to document viewers. hasSeveral been techniques among the detect first and applications defend against of cryptojackingWebAssembly15 [ ,, [2514,,,3443].]. in,support ranging for fromcreating online and demos scanning ofbarcodes programming to document languages, viewers. over SeveralSection techniques 4.5 studies detect how prevalent and defend this against threat cryptojacking is, showing [ that14,, 43 its]. support for creating and scanning barcodes to document viewers. Insight 11. The application domains of WebAssembly binaries Sectionimportance 4.5studies has decreased how prevalent over time. this Wang threat et al is,. [43] showingdiscuss that limita- its Insighton the web 11. reflectThe application the diversity domains of of WebAssemblythe web itself, binaries showing that importancetions of VirusTotal has decreased in identifying over time. cryptomining, Wang et al.. [43] [43]whichdiscuss may impact limita- onWebAssembly the web reflect is used the in a widediversity range ofof applications. the web itself, showing that tionsthe validity of VirusTotal of our results. in identifying However, cryptomining, our manual which inspection may of impact bina- WebAssembly is used in a wide range of applications. theries validity confirms of our the results. low prevalence However, our of cryptominers manual inspection among of bina- today’s WebAssembly binaries, which is also supported by Varlioglu et al.’s 4.7 RQ5: Minification and Names ries confirms the low prevalence of cryptominers among today’s 4.7 RQ5: Minification and Names WebAssemblyobservations about binaries, the which decline is of also cryptojacking supported by [42]. Varlioglu et al.’s As a binary format with only a low-level textual representation, observationsWebAssembly about attacks. the declineBeyond of cryptojackingcryptomining, [42]. other kinds of at- 4.7WebAssemblyAs a binary RQ5: format Minification binaries with cannot only a be low-level asand easily textualNames inspected representation, and under- tacksWebAssembly based on WebAssembly attacks. Beyond exist. cryptomining, Lehmann etother al. show kinds that of vul- at- AsWebAssemblystood a binary as source format binaries code, with e.g., cannot only in JavaScript. a be low-level as easily The textual inspected ability representation, to understand and under- tacksnerabilities basedthat on WebAssembly propagate from exist. memory-unsafe Lehmann et al. source show languages that vul- WebAssemblyastood WebAssembly as source binaries code, binary e.g., cannot is in relevant JavaScript. be as for easily auditing The inspected ability third-party to understandand under- code nerabilitiesmay also be that exploited propagate in WebAssembly from memory-unsafe [18]. Others source report languages examples stoodanda WebAssembly reverse as source engineering code, binary e.g., malware.is in relevant JavaScript. For for example, auditing The ability when third-party to a understand frequently code mayof such also attacks be exploited [3, 22 in]. Custom WebAssembly memory [18 allocators]. Others report are potentially examples adepended-uponand WebAssembly reverse engineering npm binary package is malware. relevant contains For for example, a auditing WebAssembly when third-party a binary, frequently code the ofnot such hardened attacks [5 [3, ,,2222].]. Section Custom 4.4 memory shows allocators that several are of potentially the risks andpackagedepended-upon reverse distribution engineering npm packageplatform malware. contains may For want example, a WebAssembly to check when that a itbinary, frequently does not the notreported hardened by prior [5,, 22 work]. Section affect 4.4 a shows wide thatrange several of binaries. of the risks Another depended-uponperformpackage maliciousdistribution npm actions, package platform such contains may as stealingwant a WebAssembly to checkcryptocurrency. that binary,it does21 thenotBe- 21 reportedline of attack by prior are malicious work affect WebAssembly a wide range binaries, of e.g., binaries. to escape Another packagecauseperform meaningful distributionmalicious names, actions, platform e.g., such formay as functions, wantstealing to check cryptocurrency. are helpful that it for does under- notBe- linethe browser of attack sandbox are malicious [1, 36], WebAssembly attacks that use binaries, side channels e.g., to [ escape9], and performstandingcause meaningful malicious code [17], names, actions, especially e.g., such in for binaries,as functions, stealing we cryptocurrency. are study helpful to what for extentunder-21 Be- theattacks browser based sandbox on speculative [1,, 36], attacks execution that [20]. use side channels [9], and causeWebAssemblystanding meaningful code [binaries17], names, especially provide e.g., infor meaningful binaries, functions, we names. are study helpful to what for under- extent WebAssembly defenses. A defense against application-level at- standingWebAssembly code [ binaries17], especially provide in meaningful binaries, we names. study to what extent attacks based on speculative execution [20]. tacksWebAssembly is to enforce defenses. securityA policiesdefense onagainst untrusted application-level WebAssembly at- WebAssembly20https://github.com/google/dracoAnalysis. We binaries perform provide a static meaningful analysis to assess names. two name-related 21 tacksbinaries is to through enforce taint security tracking policies [8, 40 on]. WebAssembly untrusted WebAssembly also serves characteristicshttps://blog.npmjs.org/post/185397814280/plot-to-steal-cryptocurrency-foiled-by-Analysis. We of perform binaries. a static First, analysis the analysis to assess checks two name-relatedwhether a bi- the-npm binariesas a technology through to taint implement tracking defenses, [8,, 40]. WebAssembly e.g., to sandbox also libraries serves nary contains a names section. While by default binaries contain characteristics of binaries. First, the analysis checks whether a bi- asexecuted a technology in a browser to implement [26], to implement defenses, e.g.,formally to sandbox verified libraries cryptog- names only for imported and exported program elements, the op- nary contains a names section. While by default binaries contain executedraphy [30 in], or a browser to ensure [26 constant-time], to implement operations formally for verified cryptographic cryptog- tional names section maps all function indices to identifiers. Second, names only for imported and exported program elements, the op- raphyprimitives [30],[ or45 to]. Ourensure results constant-time call for additional operations mitigations, for cryptographic e.g., to the analysis checks whether the names of imported and exported tional names section maps all function indices to identifiers. Second, primitivesdefend against [45]. vulnerabilities Our results call propagated for additional from mitigations, source languages, e.g., to names are minified. Both to save space and to obfuscate the code, the analysis checks whether the names of imported and exported defendand provide against guidelines vulnerabilities for developing propagated such from techniques, source languages, e.g., by compilers may shorten names down to single or two-letter names names are minified. Both to save space and to obfuscate the code, andshowing provide which guidelines toolchains for are developing most commonly such techniques, used. e.g., by devoid of information. The analysis considers a WebAssembly bi- compilers may shorten names down to single or two-letter names showingStudies which of WebAssembly. toolchains areMusch most et commonly al. [24] systematically used. collect devoidnary as of minified information. if it Thecontains analysis more considers than ten a WebAssembly import or export bi- names WebAssemblyStudies of WebAssembly. from the webMusch and reportet al. [24 cryptomining] systematically tobe collect one nary(to exclude as minified small, if potentially it contains hand-written more than modules),ten import but theor aver-export names WebAssemblyof its prime use from cases. the Our web work and extends report cryptomining their findings to in be several one (toage exclude length of small, those potentially names is ≤ hand-written4 (to account modules), for some but imports the aver- that ofways: its prime (i) by considering use cases. Our a wider work range extends of sources their findings to gather binaries,in several ageare neverlength minified of those names by isEmscripten,≤ 4 (to account thus increasing for some imports the average). that ways:which (i) results by considering in 58× more a wider binaries; range (ii) of by sources showing to gather that other binaries, ap- are never minified by Emscripten, thus increasing the average). Results. Our results show an interesting difference between the whichplications results than in cryptomining 58× more binaries; have become (ii) by showing much more that prevalent; other ap- fullResults. datasetOur andresults binaries show found an on interesting the web. In difference the full data between set, many the plicationsand (iii) by than studying cryptomining several properties have become of WebAssembly much more prevalent; not con- fullbinaries dataset contain and binaries a names foundsection on (19.6%) the web. but In only the 4.1% full data of the set, binaries many andsidered (iii) before, by studying e.g., security several properties properties and of WebAssembly toolchains. Other not work con- binariesare minified. contain In a names contrast,section among (19.6%) all but binaries only 4.1% offound the binaries on the web,only sideredstudies thebefore, performance e.g., security of WebAssembly properties and and toolchains. compares Other it to native work are13.3% minified. contain aInnames contrast,section butamong 28.8% all arebinaries minified. found These on results the web,only studiesperformance the performance [12], however of WebAssembly again on a small and set compares of binaries. it to native 13.3%show containthat for a anames significantsection fraction but 28.8% of are websites, minified. not These only results minified performanceWebAssembly [12], benchmarks. however againPrior on work a small on set WebAssembly of binaries. often showJavaScript that forcode a [significant37], but also fraction minified of WebAssembly websites, not binaries only minified make reliesWebAssembly on benchmark benchmarks. suites thatPrior may not work well on represent WebAssembly the diversity often JavaScriptit harder to code understand [37], but what also minified code is running WebAssembly on the client binaries side. make reliesof real-world on benchmark WebAssembly suites that binaries, may not such well as represent PolyBenchC, the diversity SciMark, it21https://blog.npmjs.org/post/185397814280/plot-to-steal- harder to understand what code is running on the client side. ofand real-world Ostrich [13 WebAssembly], i.e., benchmarks binaries, of numericalsuch as PolyBenchC, or scientific SciMark, compu- cryptocurrency-foiled-by-the-npm tations [10, 11, 19], SPEC CPU, i.e., benchmarks of complex C/C++ 21https://blog.npmjs.org/post/185397814280/plot-to-steal- and Ostrich [13], i.e., benchmarks of numerical or scientific compu- cryptocurrency-foiled-by-the-npm tations [10, 11, 19], SPEC CPU, i.e., benchmarks of complex C/C++ WWW ’21, April 19–23, 2021, Ljubljana, Slovenia Aaron Hilbig, Daniel Lehmann, and Michael Pradel as a technology to implement defenses, e.g., to sandbox libraries REFERENCES executed in a browser [26], to implement formally verified cryptog- [1] Georgi Geshev Alex Plaskett, Fabian Beterke. 2018. Apple Safari – Wasm Section raphy [30], or to ensure constant-time operations for cryptographic Exploit. [2] Javier Cabrera Arteaga, Orestis Floros Malivitsis, Oscar Luis Vera Pérez, Benoit primitives [45]. Our results call for additional mitigations, e.g., to Baudry, and Martin Monperrus. 2020. CROW: Code Diversification for WebAs- defend against vulnerabilities propagated from source languages, sembly. arXiv preprint arXiv:2008.07185 (2020). [3] John Bergbom. 2018. Memory safety: old vulnerabilities become new with WebAs- and provide guidelines for developing such techniques, e.g., by sembly. showing which toolchains are most commonly used. [4] Javier Cabrera Arteaga, Shrinish Donde, Jian Gu, Orestis Floros, Lucas Satabin, Studies of WebAssembly. Musch et al. [24] systematically collect Benoit Baudry, and Martin Monperrus. 2020. Superoptimization of WebAssembly bytecode. In ICPS Companion 2020. 36–40. WebAssembly from the web and report cryptomining to be one [5] Frank Denis. 2018. WebAssembly doesn’t make unsafe languages safe (yet). of its prime use cases. Our work extends their findings in several [6] Craig Disselkoen, John Renner, Conrad Watt, Tal Garfinkel, Amit Levy, and Deian Stefan. 2019. Position Paper: Progressive Memory Safety for WebAssembly. In ways: (i) by considering a wider range of sources to gather binaries, HASP. which results in 58× more binaries; (ii) by showing that other ap- [7] Ana Nora Evans, Bradford Campbell, and Mary Lou Soffa. 2020. Is Rust used plications than cryptomining have become much more prevalent; Safely by Software Developers?. In ICSE. 246–257. [8] William Fu, Raymond Lin, and Daniel Inge. 2018. TaintAssembly: Taint-Based and (iii) by studying several properties of WebAssembly not con- Information Flow Control Tracking for WebAssembly. CoRR abs/1802.01050 sidered before, e.g., security properties and toolchains. Other work (2018). studies the performance of WebAssembly and compares it to native [9] Daniel Genkin, Lev Pachmanov, Eran Tromer, and Yuval Yarom. 2018. Drive-By Key-Extraction Cache Attacks from Portable Code. In ACNS. performance [12], however again on a small set of binaries. [10] Andreas Haas, Andreas Rossberg, Derek L Schuff, Ben L Titzer, Michael Holman, WebAssembly benchmarks. Prior work on WebAssembly often Dan Gohman, Luke Wagner, Alon Zakai, and JF Bastien. 2017. Bringing the web up to speed with WebAssembly. In PLDI. relies on benchmark suites that may not well represent the diversity [11] David Herrera, Hanfeng Chen, Erick Lavoie, and Laurie Hendren. 2018. Numerical of real-world WebAssembly binaries, such as PolyBenchC, SciMark, computing on the web: benchmarking for the future. In DLS. ACM, 88–100. and Ostrich [13], i.e., benchmarks of numerical or scientific compu- [12] Abhinav Jangda, Bobby Powers, Emery D. Berger, and Arjun Guha. 2019. Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code. In 2019 tations [10, 11, 19], SPEC CPU, i.e., benchmarks of complex C/C++ USENIX ATC. 107–120. programs that are not typically compiled to WebAssembly [12, 18], [13] Faiz Khan, Vincent Foley-Bourgon, Sujay Kathrotia, Erick Lavoie, and Laurie J. Hendren. 2014. Using JavaScript and WebCL for numerical computations: a and small sets of hand-picked applications [18]. This paper instead comparative study of native and web technologies. In DLS’14. ACM, 91–102. presents a set of thousands of real-world binaries collected from [14] Amin Kharraz, Zane Ma, Paul Murley, Charles Lever, Joshua Mason, Andrew various sources, which we make available for future research. Miller, Nikita Borisov, Manos Antonakakis, and Michael Bailey. 2019. Outguard: Detecting in-browser covert cryptocurrency mining in the wild. In WWW ’19. Studies of other languages and ecosystems. Beyond WebAssembly, [15] Radhesh Krishnan Konoth, Emanuele Vineti, Veelasha Moonsamy, Martina other studies investigate JavaScript and web security in general, Lindorfer, Christopher Kruegel, Herbert Bos, and Giovanni Vigna. 2018. MineSweeper: An In-depth Look into Drive-by Cryptocurrency Mining and including studies of minified and obfuscated code in the web[37], of Its Defense. In CCS 2018. the use of the eval [31], of the communication between websites and [16] Tobias Lauinger, Abdelberi Chaabane, Sajjad Arshad, William Robertson, Christo embedded frames with 3rd-party content [38], of outdated libraries Wilson, and Engin Kirda. 2017. Thou Shalt Not Depend on Me: Analysing the Use of Outdated JavaScript Libraries on the Web. In NDSS 2017. in the web [16], of trust relationships between websites that include [17] Dawn Lawrie, Christopher Morrell, Henry Feild, and David Binkley. 2006. What’s remote libraries and their corresponding library providers [27], of in a Name? A Study of Identifiers. In ICPC. 3–12. [18] Daniel Lehmann, Johannes Kinder, and Michael Pradel. 2020. Everything Old is implicit type conversations in JavaScript code [29], of ReDoS vul- New Again: Binary Security of WebAssembly (USENIX Security 2020). 217–234. nerabilities in JavaScript-based web servers [39], of XSS vulnera- [19] Daniel Lehmann and Michael Pradel. 2019. Wasabi: A framework for dynamically bilities [23], and of performance issues in JavaScript [35]. Inspired analyzing webassembly (ASPLOS 2019). 1045–1058. [20] Giorgi Maisuradze and Christian Rossow. 2018. Ret2spec: Speculative Execution by all that work, this paper fills in important gaps in the existing Using Return Stack Buffers. In CCS. knowledge about security properties of real-world WebAssembly. [21] Christopher D Manning, Hinrich Schütze, and Prabhakar Raghavan. 2008. Intro- duction to information retrieval. Cambridge university press. [22] Brian McFadden, Tyler Lukasiewicz, Jeff Dileo, and Justin Engler. 2018. Security 6 CONCLUSION Chasms of WASM. NCC Group Whitepaper. This paper presents a comprehensive empirical study of security [23] William Melicher, Anupam Das, Mahmood Sharif, Lujo Bauer, and Limin Jia. 2018. Riding out DOMsday: Towards Detecting and Preventing DOM Cross-Site properties, languages, and use cases of a diverse set of real-world Scripting. Network and Distributed System Security Symposium (NDSS). WebAssembly binaries. After gathering binaries from several sources, [24] Marius Musch, Christian Wressnegger, Martin Johns, and Konrad Rieck. 2019. ranging from source code repositories over packages managers to New Kid on the Web: A Study on the Prevalence of WebAssembly in the Wild (DIMVA 2019). Springer, 23–42. live websites, we analyze them through a combination of static [25] Marius Musch, Christian Wressnegger, Martin Johns, and Konrad Rieck. 2019. code analysis, manual inspection, and statistical analysis. Our study Thieves in the Browser: Web-based Cryptojacking in the Wild. In ARES. [26] Shravan Narayan, Craig Disselkoen, Tal Garfinkel, Nathan Froyd, Eric Rahm, shows that WebAssembly has grown into a diverse ecosystem with Sorin Lerner, Hovav Shacham, and Deian Stefan. 2020. Retrofitting Fine Grain new challenges and opportunities for security researchers and prac- Isolation in the Firefox Renderer. In USENIX Security. titioners, e.g., in analyzing vulnerabilities in WebAssembly binaries, [27] Nick Nikiforakis, Luca Invernizzi, Alexandros Kapravelos, Steven Van Acker, Wouter Joosen, Christopher Kruegel, Frank Piessens, and Giovanni Vigna. 2012. in hardening binaries against exploitation, and in helping security You are what you include: large-scale evaluation of remote JavaScript inclusions. analysts reverse engineer binaries. We make the binaries underlying In CCS. 736–747. our study, which yields by far the largest benchmark of WebAssem- [28] Victor Le Pochat, Tom Van Goethem, Samaneh Tajalizadehkhoob, Maciej Kor- czyński, and Wouter Joosen. 2018. Tranco: A research-oriented top sites ranking bly binaries to date, available to support future work. hardened against manipulation. arXiv preprint arXiv:1802.01156 (2018). ACKNOWLEDGMENTS This work was supported by the European Research Council (ERC, grant agreement 851895), and by the German Research Foundation within the ConcSys and Perf4JS projects. An Empirical Study of Real-World WebAssembly Binaries WWW ’21, April 19–23, 2021, Ljubljana, Slovenia

[29] Michael Pradel and Koushik Sen. 2015. The Good, the Bad, and the Ugly: An [40] Aron Szanto, Timothy Tamm, and Artidoro Pagnoni. 2018. Taint Tracking for Empirical Study of Implicit Type Conversions in JavaScript. In ECOOP. WebAssembly. https://arxiv.org/abs/1807.08349. arXiv:1807.08349 [cs.CR] [30] J. Protzenko, B. Beurdouche, D. Merigoux, and K. Bhargavan. 2019. Formally [41] Laszlo Szekeres, Mathias Payer, Tao Wei, and Dawn Song. 2013. SoK: Eternal Verified Cryptographic Web Applications in WebAssembly. In SP. War in Memory. In 2013 IEEE Symposium on Security and Privacy (SP 2013). [31] Gregor Richards, Andreas Gal, Brendan Eich, and Jan Vitek. 2011. Automated [42] Said Varlioglu, Bilal Gonen, Murat Ozer, and Mehmet Bastug. 2020. Is Crypto- construction of JavaScript benchmarks. In OOPSLA. 677–694. jacking Dead after Coinhive Shutdown?. In ICICT. IEEE, 385–389. [32] Andreas Rossberg. 2019. Multiple per-module memories for Wasm. [43] Wenhao Wang, Benjamin Ferrell, Xiaoyang Xu, Kevin W Hamlen, and Shuang [33] Andreas Rossberg. 2019. Proposal for adding basic reference types. Hao. 2018. Seismic: Secure in-lined script monitors for interrupting cryptojacks. [34] Jan Rüth, Torsten Zimmermann, Konrad Wolsing, and Oliver Hohlfeld. 2018. In European Symposium on Research in Computer Security. Springer, 122–142. Digging into Browser-based Crypto Mining. In IMC. [44] Conrad Watt. 2018. Mechanising and verifying the WebAssembly specification. [35] Marija Selakovic and Michael Pradel. 2016. Performance Issues and Optimizations In CPP 2018. 53–65. in JavaScript: An Empirical Study. In ICSE. [45] Conrad Watt, John Renner, Natalie Popescu, Sunjay Cauligi, and Deian Stefan. [36] Natalie Silvanovich. 2018. The Problems and Promise of WebAssembly. 2019. CT-Wasm: Type-Driven Secure Cryptography for the Web Ecosystem. [37] Philippe Skolka, Cristian-Alexandru Staicu, and Michael Pradel. 2019. Anything POPL (2019). to Hide? Studying Minified and Obfuscated Code in the Web.In WWW. [46] Hui Xu, Zhuangbin Chen, Mingshen Sun, and Yangfan Zhou. 2020. Memory- [38] Sooel Son and Vitaly Shmatikov. 2013. The Postman Always Rings Twice: At- Safety Challenge Considered Solved? An Empirical Study with All Rust CVEs. tacking and Defending postMessage in HTML5 Websites.. In NDSS. arXiv preprint arXiv:2003.03296 (2020). [39] Cristian-Alexandru Staicu and Michael Pradel. 2018. Freezing the Web: A Study of ReDoS Vulnerabilities in JavaScript-based Web Servers. In USENIX Sec.