A Sense of Time for JavaScript and Node.js:First-Class Timeouts as a Cure for Event Handler Poisoning

#24, Anonymous

AbstractThe software development community has begun toadopt the Event-Driven Architecture (EDA) to pro-vide scalable web services, most prominently throughNode.js. Though the EDA offers excellent scalability,it comes with an inherent risk: the Event Handler Poi-soning (EHP) Denial of Service attack. In essence, EHPattacks say that the scalability of the EDA is a double-edged sword: the EDA is scalable because clients sharea small set of threads, but if an attacker causes thesethreads to block then the server becomes unusable. EHPattacks are a significant threat, as hundreds of popularNode.js-based websites were recently reported to be vul-nerable to forms of EHP attacks.

In this work we make three contributions. First, weformally define EHP attacks, and we show that EHP at-tacks are a common form of vulnerability in the largestEDA community, the Node.js ecosystem. Second, wedesign and evaluate an EHP-safe defense: first-classtimeouts. Although realizing first-class timeouts is dif-ficult in a complex real-world framework like Node.js,our Node.cure prototype defends Node.js applicationsagainst all known EHP attacks. Third, we have identifiedand documented or corrected vulnerable APIs in Node.js,and our guide on avoiding EHP attacks is now availableon nodejs.org.

Node.cure is effective, defeating all known EHP at-tacks with application overheads as low as 0%. Moregenerally, we show that Node.cure offers strong securityguarantees against EHP attacks for the majority of theNode.js ecosystem.

Millions of developers have embraced the EDA, butwithout strict adherence to the EDA paradigm their codeis vulnerable to EHP attacks. Node.cure offers the cure.

1 IntroductionWeb services are the lifeblood of the modern Internet. Tominimize costs, service providers want to maximize thenumber of clients each server can handle. Over the pastdecade, this goal has led the software community to se-riously consider a paradigm shift in their software archi-

tecture — from the One Thread Per Client Architecture(OTPCA) used in Apache to the Event-Driven Architec-ture (EDA) championed by Node.js.

The EDA is not a passing fad. Perhaps inspiredby Welsh et al.’s SEDA concept [99], server-side EDAframeworks like Twisted [27] have been in use since atleast the early 2000s. But the boom in the EDA has comewith Node.js. Node.js (“server-side JavaScript”) was in-troduced in 2009 and is now used by many organizationsin many industries, including IBM, Microsoft, Apple,Cisco, Intel, RedHat, GE, Siemens, NASA, Wikipedia,and the NFL ([34, 67, 81, 77, 38, 18]). The associatedpackage ecosystem, npm, boasts 575,000 modules [12].It is not an exaggeration to state that Node.js is becominga critical component of the modern web [20, 37].

Given the importance of the EDA to the modern web,it has received surprisingly little study from a securityperspective [53, 78]. We present the first formal treat-ment of the weaknesses in the EDA, and describe a De-nial of Service attack, Event Handler Poisoning (EHP),that can be used against EDA-based services like Node.jsapplications (§3).

EHP attacks observe that the source of the EDA’s scal-ability is also its Achilles’ heel. Where the OTPCA givesevery client its own thread, the EDA multiplexes manyclients onto a small number of Event Handlers (threads)to reduce per-client overheads. Because many clientsshare the same Event Handlers, an EDA-based servermust correctly implement cooperative multitasking [90].An incorrect implementation of cooperative multitaskingenables an EHP attack: an attacker dominates the timespent by an Event Handler, preventing the server fromhandling all clients fairly. We found that although theEHP problem is little discussed in the Node.js documen-tation, EHP vulnerabilities are common in npm (§4).

In §5 we define criteria for EHP-safety, and use thesecriteria to evaluate four EHP defenses (§6). Though vari-ations of three of these defenses are used today, they aread hoc and thus impractical in an ecosystem dominatedby third-party modules. The fourth defense, the TimeoutApproach, requires extending existing EDA languages

1

and frameworks, but it provides a universal solution forEHP-safety with strong security guarantees. The Time-out Approach makes timeouts a first-class member of anEDA framework, securing both types of Event Handlerswith a universal timeout mechanism.

Our Node.cure prototype (§7) demonstrates the Time-out Approach in the complex Node.js framework, com-pletely defending real applications against EHP attacks.Node.cure spans the entire Node.js stack, modifyingthe Node.js JavaScript engine (V8, C++), core modules(JavaScript and C++), and the EDA mechanism (libuv,C), and can secure real applications with low overhead(§8). We feel our work is timely, as Staicu and Pradelrecently reported that hundreds of popular websites arevulnerable to one type of EHP attack with minimal at-tacker effort [93]; Node.cure defeats this and all otherEHP attacks.

In summary:1. We formally define Event Handler Poisoning (EHP)

(§3), a DoS attack against the EDA. We systemati-cally demonstrate that EHP attacks are common in thelargest EDA community, the Node.js ecosystem (§4).

2. We describe a general antidote for Event HandlerPoisoning attacks: first-class timeouts. We demon-strate effectiveness with our Node.cure prototype forNode.js in §7. We evaluate the security guarantees oftimeouts (strong, §6) and their costs (small, §8).

3. Our findings have been corroborated by the Node.jscommunity. Our guide on EHP-safe techniques is onnodejs.org, and our PRs documenting and improvingunsafe Node.js APIs have been merged (§9).

2 BackgroundIn this section we review the EDA (§2.1), explain ourchoice of EDA framework for study (§2.2), and introducedirectly related work (sections 2.3 and 2.4).

2.1 Overview of the EDAThere are two paradigms for web servers, distinguishedby the ratio of clients to resources, which correspondsto an isolation-performance tradeoff. The One ThreadPer Client Architecture (OTPCA) dedicates resources toeach client, for strong isolation but higher memory andcontext-switching overheads [83]. The Event-Driven Ar-chitecture (EDA) tries the opposite approach, with manyclients sharing execution resources: client connectionsare multiplexed onto a single-threaded Event Loop, witha small Worker Pool for expensive operations.

All mainstream server-side EDA frameworks use theAsymmetric Multi-Process Event-Driven (AMPED) ar-chitecture [82]. This architecture (hereafter “the EDA”)is illustrated in Figure 1. In the EDA, the OS or a frame-work places events in a queue, and the Callbacks ofpending events are executed sequentially by the Event

Loop. The Event Loop may offload expensive Taskslike file I/O to the queue of a small Worker Pool, whoseWorkers execute Tasks and generate “Task Done” eventsfor the Event Loop when they finish [61]. We refer to theEvent Loop and the Workers as Event Handlers.

Figure 1: This is the AMPED Event-Driven Architecture. Incomingevents from clients A and B are stored in the event queue, and the as-sociated Callbacks (CBs) will be executed sequentially by the EventLoop. We will discuss B’s EHP attack (CBB1), which has poisoned theEvent Loop, in §3.3.

Because the Event Handlers are shared by all clients,the EDA has a particular development paradigm. EachCallback and Task is guaranteed atomicity: once sched-uled, it runs to completion. Atomicity calls for coopera-tive multitasking [90], and developers partition the gen-eration of responses into multiple stages. The effect ofthis partitioning is to regularly yield to other requests bydeferring work until the next stage [54]. This partition-ing results in a Lifeline [41], a DAG describing the parti-tioned steps needed to complete an operation. A Lifelinecan be seen by following the arrows in Figure 1.

2.2 Node.js among other EDA frameworksExamples of EDA frameworks include Node.js(JavaScript) [15], libuv (C/C++) [10], Vert.x (Java) [28],Twisted (Python1) [27], and Microsoft’s P# [57].These frameworks have been used to build a widevariety of industry and open-source services (e.g.[7, 81, 67, 77, 32, 31, 8, 4]).

Most prominent among these frameworks is Node.js, aserver-side event-driven framework for JavaScript intro-duced in 2009. The popularity of Node.js comes from itspromise of “full stack JavaScript” — client- and server-side developers can speak the same language and sharethe same libraries. This vision has driven the rise of theJavaScript package ecosystem, npm, which with 575,000modules is the largest of any language [12]. Node.js isstill accelerating: use doubled between 2016 and 2017,from 3.5 million developers [33] to 7 million [35].

The Node.js codebase has three major parts [63],whose interactions complicate top-to-bottom extensions

1In addition, Python 3.4 introduced native EDA support.

2

like Node.cure. An application’s JavaScript code is ex-ecuted using Google’s V8 JavaScript engine [3], its pro-grammability is supported by Node.js core JavaScriptmodules with C++ bindings for system calls, and theevent-driven architecture is implemented in C usinglibuv [10].

2.3 Algorithmic complexity attacksOur work is inspired by Algorithmic Complexity (AC)attacks ([75, 52]), a form of Denial of Service attack. Inan AC attack, a malicious client crafts input that trig-gers the worst-case complexity of the victim server’salgorithms, causing execution resources to be wasted.Well-known examples of AC attacks include attacks onhash tables [52] as well as Regular expression Denial ofService (ReDoS) attacks, which exploit the worst-caseexponential-time behavior typical of regular expression(regexp) engines [51].

As will be made clear in §3, EHP attacks are not sim-ply the application of AC attacks to the EDA. The firstdistinction is a matter of perspective: where AC attacksfocus on the complexity of the algorithms the service em-ploys, EHP attacks target the software architecture usedby the service, and are only concerned with time. Thesecond distinction is one of definition: AC attacks relyon CPU-bound activities to achieve DoS, while EHP at-tacks may use either CPU-bound or I/O-bound activitiesto poison an Event Handler.

2.4 Preliminary work on EHP attacksDavis et al.’s workshop paper [53] was the first to sketchEHP attacks. Their description was superficial, lackinga threat model or a formal description. Their (unimple-mented) solution was the “C-WCET Principle”, whichwould incur significant refactoring costs at the language,framework, and application levels.

Our work offers a formal treatment of the EHP prob-lem (§3), and introduces criteria for EHP-safety (§5) thatexplain why the C-WCET Principle is both ad hoc andunsuited to dealing with I/O-based EHP attacks (§6). Wethen propose and prototype the Timeout Approach inour Node.cure extension of Node.js (sections 7 and 8),and engage with the Node.js developer community to in-crease awareness of EHP attacks (§9).

3 Event Handler Poisoning AttacksIn this section we provide our threat model (§3.1), for-mally define Event Handler Poisoning (EHP) attacks(§3.2), and present an attack taxonomy (§3.5). To illus-trate the problem, we demonstrate minimal EHP attacksusing ReDoS and “ReadDoS” (§3.3).

3.1 Threat modelWe assume the following. The victim is an EDA-basedserver, e.g. a Node.js server, with an EHP vulnerabil-

ity. The attacker knows how to exploit this vulnerability:they know the victim feeds user input to a VulnerableAPI, and they know evil input that will cause the Vulner-able API to block the Event Handler executing it. Lastly,once identified, the victim will blacklist the attacker.

3.2 A formal definition of an EHP attackTotal/synchronous complexity and time. Before wecan define EHP attacks, we must introduce a few def-initions. First, recall the standard EDA formulation il-lustrated in Figure 1. Each client request is handled bya Lifeline [41] partitioned into one or more Callbacksand Tasks. A Lifeline is a DAG whose vertices are Call-backs or Tasks and whose edges are events or Task sub-missions.

We define the total complexity of a Lifeline as the cu-mulative complexity of all of its vertices as a functionof their cumulative input. The synchronous complexityof a Lifeline is the greatest individual complexity amongits vertices. A Lifeline’s total time and synchronous timeare defined analogously. Since the EDA relies on cooper-ative multitasking, a Lifeline’s synchronous complexityand synchronous time provide theoretical and practicalbounds on how vulnerable it is. Note that a Lifeline withlarge total time is not vulnerable so long as each vertex(Callback/Task) has a small synchronous time; only syn-chronous time matters for EHP.

EHP attacks. An EHP attack exploits an EDA-basedservice with an incorrect implementation of cooperativemultitasking. Here is how it works. The attacker iden-tifies an exploitable Lifeline, one with large worst-casesynchronous complexity, and poisons the correspondinglarge-complexity Callback or Task with evil input. Thisevil input causes the Event Handler executing it to block,starving pending events or Tasks.

An EHP attack can be carried out against either theEvent Loop or the Workers in the Worker Pool. A poi-soned Event Loop brings the server to a halt, while foreach poisoned Worker the responsiveness of the WorkerPool degrades. Thus, an attacker’s aim is to poison eitherthe Event Loop or enough of the Worker Pool to harm thethroughput of the server. Remember, the Worker Pool issmall enough that poisoning it will not attract the atten-tion of network-level defenses.

Trends in software development [88] have made EHPattacks relatively easy both to find and to launch. Whencommercial applications embrace open-source software,including open-source package ecosystems, vulnerabili-ties in these (open-source) libraries may become vulner-abilities in the application. In §4.2 we show that manynpm modules have exploitable EHP vulnerabilities, andthat hundreds of real Node.js-based websites have beenaffected. Even worse, these example EHP attacks areasymmetric, requiring a few small evil inputs from an

3

1 def serveFile(name):

2 if name.match (/(\/.+)+$/): # ReDoS

3 data = await readFile(name) # ReadDoS

4 client.write(data)

Figure 2: Gist of our simple server. It is vulnerable to two EHP attacks:ReDoS (line 2) and ReadDoS (line 3).

attacker to poison an entire EDA-based server.

3.3 Illustrating EHP attacks: ReDoS and ReadDoS

To illustrate EHP attacks, we developed a minimal vul-nerable file server with EHP vulnerabilities common inreal npm modules (§4.2). Figure 2 shows pseudocode,with the EHP vulnerabilities indicated: ReDoS on line2, and ReadDoS on line 3. In Figure 3 you can see theimpact of EHP attacks on baseline Node.js, as well asthe effectiveness of Node.cure. In a real website, theseattacks would result in partial or complete DoS. WithoutNode.cure the only remedy would be to restart the server,dropping all existing client connections.

ReDoS attacks have been well documented in the lit-erature [51, 89, 95, 70, 87, 96]. A string composed of /’sfollowed by a newline triggers exponential-backtrackingbehavior in Node.js’s regular expression engine, poison-ing the Event Loop in a CPU-bound EHP attack.

The second EHP vulnerability might be more sur-prising. Our server has a directory traversal vulner-ability, permitting clients to read arbitrary files. Inthe EDA, directory traversal vulnerabilities can be par-layed into I/O-bound EHP attacks, “ReadDoS”, providedthe attacker can identify a Slow File2 from which toread. Since line 3 uses the asynchronous framework APIreadFile, each ReadDoS attack on this server will poi-son a Worker in an I/O-bound EHP attack.

The architecture-level behavior of the ReDoS attack isillustrated in Figure 1. After client A’s benign request issanitized (CBA1), the readFile Task goes to the WorkerPool (TaskA1), and when the read completes the Callbackreturns the file content to A (CBA2). Then client B’s ma-licious request arrives and triggers ReDoS (CBB1), drop-ping the server throughput to zero. The ReadDoS attackhas a similar effect on the Worker Pool, with the sameunhappy result.

3.4 Aren’t EHP attacks possible in the OTPCA?

EHP attacks are only possible when clients share exe-cution resources; they are not possible when clients areisolated as in the OTPCA. In the EDA, all clients shareone Event Loop and a small Worker Pool. For example,

2In addition to files exposed on network file systems,/dev/random is a good example of a Slow File: “[r]eads from/dev/random may block” [36].

Figure 3: This figure shows the effect of evil input on the throughput ofa server based on Figure 2, with realistic vulnerabilities. Legitimate re-quests came from 80 clients using ab [1]. The attacks are against eitherbaseline Node.js (grey) or our prototype, Node.cure (black). For Re-DoS (triangles), evil input was injected after three seconds, poisoningthe baseline Event Loop. For ReadDoS (circles), evil input was injectedfour times at one second intervals beginning after three seconds, even-tually poisoning the baseline Worker Pool. The lines for Node.cureshows its effectiveness against these EHP attacks. When attacked,Node.cure’s throughput dips until the timeout threshold is reached, af-ter which its throughput temporarily rises as it bursts through the built-up queue of pending events or Tasks.

Node.js has a maximum of 128 Workers [19]. By con-trast, in the OTPCA a similar attack poisons only oneof the thousands [62] of “Event Handlers”. We believeEHP attacks have not previously been explored becausethe EDA has only recently seen popular adoption by theserver-side community.

3.5 A taxonomy of EHP attacksWe turn now to a precise taxonomy of the root causes ofEHP vulnerabilities. At a high level, large synchronoustime can be attributed to the use of a Vulnerable API thatperforms computation or I/O.

Table 1 classifies Vulnerable APIs along two axes.Along the first axis, a Vulnerable API affects either theEvent Loop or a Worker, and it might be CPU-bound orI/O-bound. Along the second axis, a Vulnerable API canbe found in the language, the framework, or the applica-tion. In our evaluation we provide an exhaustive list ofVulnerable APIs for Node.js (§8.1). Although our exam-ples are specific to Node.js, the same general classifica-tion applies to any EDA framework.

4 EHP Attacks In the WildWith a definition of EHP attacks in hand, we now assessthe awareness and incidence of EHP vulnerabilities in theNode.js ecosystem. We found that the Node.js documen-tation does not carefully outline the need for cooperativemultitasking (§4.1), which might contribute to the factthat 26% of known npm module vulnerabilities can beused for EHP attacks (§4.2); indeed, some already have

4

Vuln. APIs Event Loop (§7.2) Worker Pool (§7.1)CPU-bound I/O-bound CPU-bound I/O-bound

Language Regexp, JSON N/A N/A N/AFramework Crypto, zlib FS Crypto, zlib FS, DNSApplication while(1) DB query Regexp [14] DB query

Table 1: Taxonomy of Vulnerable APIs in Node.js, with examples.An EHP attack through a Vulnerable API poisons the Event Loop ora Worker, and its synchronous time is due to CPU-bound or I/O-boundactivity. A Vulnerable API might be part of the language, framework,or application, and might be largely synchronous (Event Loop) or asyn-chronous (Worker Pool). zlib is the Node.js compression library. N/A:JavaScript has no native Worker Pool nor any I/O APIs.

been [93].

4.1 The Node.js docs are quiet

We believe that examining the documentation and guidesfor JavaScript and Node.js should tell us whether thiscommunity is aware of EHP attacks.

There are three places to look for Node.js documenta-tion. First, there is the JavaScript language specification.Second, Node.js maintains documentation for the APIsof its core modules [21]. Third, the nodejs.org websiteoffers a set of guides for new developers [17].

Although there are potential EHP vulnerabilities in animplementation of JavaScript (like ReDoS or large JSONobject manipulation), language specifications do not al-ways discuss their risks. For example, in MDN’s docu-mentation only eval has warnings [13].

The Node.js documentation does not indicate any vul-nerabilities (like ReDoS) in its JavaScript engine. How-ever, it does give hints about avoiding EHP attacks onthe Node.js framework APIs. The Node.js APIs in-clude several modules with Vulnerable APIs, and de-velopers are warned away from the synchronous ver-sions. The asynchronous versions, which could poisonthe Worker Pool, bear the warning: “[These] APIs uselibuv’s threadpool, which can have surprising and neg-ative performance implications for some applications,”and refer to another page reading “libuv’s threadpool hasa fixed size...other...APIs that run in libuv’s threadpool[may] experience degraded performance.” While techni-cally sound, we feel that this level of documentation maybe unhelpful for the average Node.js developer.

The most critical shortcoming we identified is in theNode.js new developer guides, which skip directly from“Hello world” to deep dives on HTTP and profiling.These guides do not advise developers on the design ofNode.js applications, which must fit the EDA paradigmand avoid EHP vulnerabilities. Later we describe theguide we wrote on these topics (§9), now available onnodejs.org.

Figure 4: Classification of the 838 npm module vulnerabilities, by cat-egory and by usefulness in EHP attacks. Data from 29 January 2018.

4.2 EHP vulnerabilities are common

While documentation can tell us about communityawareness, vulnerability databases tell us about the stateof practice. Although the community documentationdoes not discuss EHP attacks, we found that EHP vul-nerabilities are common in npm modules, thus affectingany Node.js applications that rely on these modules.

We systematically reproduced the analysis of Davis etal. [53] on the Snyk.io vulnerability database [25]. Daviset al. used a manual categorization of the 353 npm vul-nerabilities reported by Snyk.io as of February 2017. Wereproduced their analysis on the 838 npm vulnerabilitiesreported as of January 2018, using regular expressionsfor a consistent classification scheme. Figure 4 shows thedistribution of vulnerability types, absorbing categorieswith fewer than 10 vulnerabilities into Other. A high-level CWE number is given next to each class.

The dark bars in Figure 4 show the 223 vulnerabili-ties (26%) that can be employed in an EHP attack underour threat model (§3.1). The 155 EHP-relevant DirectoryTraversal vulnerabilities are exploitable because they al-low arbitrary file reads, which can poison the Event Loopor the Worker Pool through ReadDoS (§3.3). The 59EHP-relevant Denial of Service vulnerabilities poisonthe Event Loop; 48 are ReDoS, and the remaining 11 cantrigger infinite loops or worst-case performance in inef-ficient algorithms. In Other are 9 Arbitrary File Writevulnerabilities that, like ReadDoS, can be used for EHPattacks by writing to Slow Files.

Due to the frequent practice of using untrusted third-party npm modules in production code [39], EHP vulner-abilities in npm translate directly into EHP vulnerabili-ties in Node.js servers. For example, Staicu and Pradelrecently showed how low the bar is for attackers. Af-ter remarking that “a skilled individual can attack real-world websites with moderate effort,” they used ReDoSvulnerabilities in popular npm modules to DoS hundredsof websites from the Alexa Top Million [93].

5

5 What Does it Mean to be EHP-Safe?Having defined the EDA (§2), explained EHP attacks(§3), and surveyed their reality (§4), we now ponder whatit means to be EHP-Safe.

The fundamental cause of EHP vulnerabilities shouldbe clear: EHP vulnerabilities stem from Vulnerable APIsthat fail to honor cooperative multitasking. As catego-rized in Table 1, Vulnerable APIs can poison the EventLoop or the Worker Pool, they can be CPU-bound orI/O-bound, and they occur at any level of the applicationstack: language (vulnerable constructs), framework (vul-nerable core modules), or application (vulnerable code inthe application or libraries).

To be EHP-safe, an application must use APIs whosesynchronous time (§3.2) is (small and) bounded. If an ap-plication cannot bound the synchronous time of its APIs,it is vulnerable to EHP attack; conversely, if an applica-tion can bound the synchronous time of its APIs, then itis EHP-safe. This application-level guarantee must spanthe application’s full stack: the language constructs ituses, the framework APIs it invokes, and the applicationcode itself.

In §6, we outline several approaches to EHP-safety. Tochoose between them, we suggest three criteria:1. General. A developer must be able to use existing

APIs or slight modifications thereof. This ensures thatapplications are general, that they can solve meaning-ful problems.

2. Developer-friendly. A developer should not need ex-pertise in topics outside of their application domain.

3. Composable. If a developer uses only EHP-safe APIs,they should be unable to create a Vulnerable API.In a composably EHP-safe system, an API contain-ing while(1); would not be Vulnerable, because itis composed only of non-Vulnerable language con-structs. In contrast, without composability a sys-tem has only ad hoc EHP safety, because in addi-tion to making language- and framework-level APIsnon-Vulnerable, all application-level APIs composedof them must also be assessed.

6 Antidotes for Event Handler PoisoningHere we discuss four schemes by which to guaranteeEHP-safety: removing Vulnerable APIs (§6.1), only call-ing Vulnerable APIs with safe input (§6.2), refactoringVulnerable APIs into safe ones (§6.3), and bounding aCallback or Task’s synchronous time at runtime (§6.4).We evaluate these schemes using the criteria from §5.

6.1 Remove calls to Vulnerable APIsTo become EHP-safe, an application might eliminatecalls to Vulnerable APIs. Obviously, this Blacklist Ap-proach fails the generality criterion.

6.2 Sanitize input to Vulnerable APIsMany Vulnerable APIs are only problematic if they arecalled with unsafe input. Another approach to EHP-safety, then, is the Sanitary Approach: ensure that everyVulnerable API is always called with a safe input. TheSanitary Approach is developer-unfriendly, because it re-quires developers to identify evil input for the APIs theycall. And when Vulnerable APIs like regexps are used tofilter input, quis custodiet ipsos custodes?

6.3 Refactor Vulnerable APIsA more promising path to EHP-safety is to refactor Vul-nerable APIs into safe ones, as proposed by Davis etal. [53]. Since the goal of EHP-safety is to bound the syn-chronous time of a Lifeline, a developer could restrict thecomplexity of each of its Callbacks and Tasks, perhaps toConstant Worst-Case Execution Time (C-WCET). Thiswould bound the synchronous complexity of the Life-line. If all Vulnerable APIs were replaced with APIs fol-lowing the C-WCET Principle, the application would beEHP-safe. The C-WCET Principle is the logical extremeof cooperative multitasking, extending input sanitizationfrom the realm of data into the realm of the algorithmsused to process it.

Evaluating the C-WCET Principle. The C-WCETPrinciple has two benefits. First, by bounding the syn-chronous complexity of all Callbacks and Tasks, therewould be no such thing as evil input. Every client re-quest could be handled. Second, the C-WCET Princi-ple can be applied largely without changing the languagespecification. For example, as has previously been pro-posed [50], a non-exponential-time regexp engine couldbe used in place of Node.js’s exponential-time Irregexp

engine [49], and most applications would be none thewiser.

The C-WCET Principle meets the generality criterion;every API can be partitioned towards C-WCET. It is alsosomewhat developer-friendly: language- and framework-level APIs can be C-WCET partitioned by frameworkdevelopers, leaving developers responsible for C-WCETpartitioning their own APIs. One difficulty, though, isthat application developers rely heavily on third-partynpm modules that might not be C-WCET-partitioned.

Critically, like the Blacklist and Sanitary Approaches,the C-WCET Principle is not composable. Since Vulner-able APIs can always be composed from non-VulnerableAPIs3, developers would need to take responsibility forapplying and maintaining the C-WCET Principle at theapplication level.

It is worth noting that while the C-WCET Principleapplies readily to CPU-bound algorithms, it is unclear

3As noted in §5, an API consisting of a while(1); loop is Vulner-able in the Blacklist, Sanitary, and C-WCET Approaches, even thoughit only calls the constant-time “language APIs” while(1) and ;.

6

how to achieve C-WCET Partitioning for I/O. Computa-tion can be partitioned to the instruction granularity, butthe granularity of I/O is poorly defined. For example, theC-WCET Principle would have no trouble with ReDoS,but cannot cleanly combat ReadDoS.

6.4 Dynamically bound the running timeThe goal of the C-WCET Principle was to bound a Life-line’s synchronous complexity as a way to bound its syn-chronous time, and would require refactoring every Vul-nerable API. But instead of statically bounding an API’ssynchronous complexity, what if we could dynamicallybound its synchronous time? Then the worst-case com-plexity of each Callback and Task would become irrel-evant, because they would be unable to take more thanthe quantum provided by the runtime. In this TimeoutApproach, the runtime detects and aborts long-runningCallbacks and Tasks by emitting a TimeoutError, thrownfrom Callbacks and returned from Tasks.

The Timeout Approach says that in the EDA, pure co-operative multitasking is unsafe. Just as safe general-purpose languages offer null pointer exceptions andbuffer overflow exceptions, so a safe EDA frameworkmust offer timeout exceptions, and developers must beprepared to deal with them. Developers should not haveto explicitly wrap sensitive code in timers or offload itto separate threads or processes; in the EDA, timeoutsshould be provided by the framework just like any othersecurity-relevant exception.

The Timeout Approach provides EHP-safety. Like theC-WCET Principle, the Timeout Approach is general. Itis more developer-friendly because it only requires de-velopers to handle TimeoutErrors in their own APIs.And where the C-WCET Principle was ad hoc, the Time-out Approach is composable. If the EDA runtime had asense of time, then a long-running Callback/Task couldbe interrupted no matter where it was, whether in the lan-guage, the framework, or the application.

Although the Timeout Approach fulfills all of theEHP-safety criteria, like C-WCET Partitioning it re-quires application-level refactoring. Because the pro-posed TimeoutErrors emitted by the runtime are not cur-rently part of the language and framework specification,existing applications would need to be ported. We do notanticipate this to be a heavy burden for well-written ap-plications, whose Callbacks should already be exception-aware to catch errors like null pointers (ReferenceError)and buffer overflows (RangeError), and which shouldtest the result of Tasks for errors.

Though the C-WCET Principle and the Timeout Ap-proach both meet the generality criterion, the TimeoutApproach is more developer-friendly, and is the onlyEDA-centric solution we analyzed that is composable4.

4We discuss alternative approaches to achieve EHP-safety in §9.

Objections. One objection to the Timeout Approachis that “timeouts are hardly novel.” We disagree. Tothe best of our knowledge, existing timeouts take oneof two approaches. The first is on a per-API basis: the.NET framework has used timeouts to combat ReDoSsince 2012 [22]. Unfortunately, such ad hoc timeoutswill always be non-composable. The second approachis on a per-thread basis: OSes commonly use a heart-beat mechanism to detect and restart unresponsive ap-plications, and in the OTPCA a client thread can easilybe killed and replaced if it exceeds a timeout. But thesame approach fails in the EDA. Detecting and restart-ing a blocked Event Loop will break all existing clientconnections, achieving the very DoS we seek to defeat.Remember the double-edged sword of the EDA: scala-bility at the cost of client isolation. Because clients arenot isolated on separate execution resources, our Time-out Approach makes timeouts a first-class member ofJavaScript and Node.js, non-destructively guaranteeingthat no Event Handler can block on an event or Task.

Another objection to the Timeout Approach is that“someone must select a timeout,” and there is some evi-dence that little thought has been given to the choice oftimeouts [84]. For the purpose of avoiding EHP attacksunder our threat model, however, this does not pose a se-rious problem. Remember that a typical web server han-dles hundreds or thousands of clients per second (Fig-ure 3). If so, simple arithmetic tells us that in a Node.jsserver, individual Callbacks and Tasks must be taking nolonger than milliseconds to complete. Thus, a univer-sal Callback-Task timeout on the order of 1 second willnot discomfit normal Callbacks and Tasks, will certainlyensure that an EHP attack is detected and defeated expe-diently, and might briefly annoy existing clients but notsignificantly undermine their experience. It then falls tothe application to blacklist the attacker.

The last objection is “it’s trivial!” We report, however,that though the Timeout Approach is conceptually sim-ple, realizing it in a complex real-world framework likeNode.js is difficult. The challenges that face a sound im-plementation are:

1. Enforcing timeouts on both Callbacks and Tasks.2. Enforcing timeouts in both the language (V8) and the

framework (Node.js core modules and libuv).3. Ensuring that timeouts are low-overhead.

7 First-Class Timeouts in Node.cure

Our Node.cure prototype implements the Timeout Ap-proach for Node.js by bounding the synchronous time ofevery Callback and Task. To do so, Node.cure makestimeouts a first-class member of Node.js, extending theJavaScript specification by introducing a TimeoutError

to abort long-running Callbacks and Tasks.

7

Figure 5: This figure illustrates Node.cure’s timeout-aware WorkerPool, including the roles of Event Loop, Executors (Worker Pool andPriority), and Hangman. Grey entities were present in the originalWorker Pool, black are new. The Event Loop can synchronously accessthe Priority Executor, or asynchronously offload Tasks to the WorkerPool. If an Executor’s Manager sees its Worker time out, it creates areplacement Worker and passes the Dangling Worker to a Hangman.

At a high level, here is the timeout behaviorNode.cure enforces. A long-running Callback poisonsthe Event Loop; in Node.cure these Callbacks throwa TimeoutError whether they are in JavaScript or in aNode.js C++ binding (§7.2). A long-running Task poi-sons its Worker; in Node.cure, such a Task is abortedand fulfilled with a TimeoutError (§7.1).

As a result, Node.cure meets the composability crite-rion of §5: the Node.js language and framework APIs aretimeout-aware, and an application whose APIs are com-posed of these APIs will be EHP-safe (§7.3). Node.curealso has an exploratory Slow Resource Policy to reducetimeout overheads (§7.4).

We describe the Timeout Approach for Tasks first, be-cause it introduces machinery used to apply the TimeoutApproach to Callbacks.

7.1 Timeout-aware TasksEHP attacks targeting the Worker Pool use VulnerableAPIs to submit long-running Tasks that poison a Worker.Node.cure defends against such attacks by bounding thesynchronous time of Tasks.

Timeout-aware Worker Pool. We modified thelibuv Worker Pool to be timeout-aware, replacing libuv’sWorkers with Executors that combine a permanent Man-ager with a disposable Worker. If a Task times out, theManager uses a Hangman to dispose of the poisonousTask and its Worker, and creates a new Worker to resumehandling Tasks. These roles are illustrated in Figure 5.

Here is a slightly more detailed description of ourtimeout-aware Worker Pool. Node.js’s Worker Pool isimplemented in libuv, exposing a Task submission APIuv queue work, which we extended as shown in Table 2.The original Workers of the Worker Pool would simplyinvoke work and then notify the Event Loop to invokedone. This is also the typical behavior of our timeout-aware Workers. When a Task takes too long, however,the potentially-poisoned Worker’s Manager invokes theTask’s timed out callback. If the submitter does not

Callback Descriptionvoid work Perform Task.

int timed out* When Task has timed out. Can request extension.void done When Task is done. Special error code for timeout.

void killed* When a timed out Task’s thread has been killed.

Table 2: Summary of the Worker Pool API. work is invoked on theWorker. done is invoked on the Event Loop. The new callbacks,timed out and killed, are invoked on the Manager and the Hang-man, respectively. On a timeout, work, timed out, and done areinvoked, in that order; there is no ordering between the done andkilled callbacks, which sometimes requires reference counting forsafe memory cleanup. *New callbacks.

request an extension, the Manager creates a replace-ment Worker so that it can continue to process subse-quent Tasks, creates a Hangman thread for the poisonedWorker, and notifies the Event Loop that the Task timedout. The Event Loop then invokes its done Callback witha TimeoutError, permitting a rapid response to evil in-put. Concurrently, once the Hangman successfully killsthe Worker thread, it invokes the Task’s killed callbackfor resource cleanup, and returns.

Differentiating between timed out and killed per-mits more flexible error handling, but introduces tech-nical challenges. If a rapid response to a timeout is un-necessary, then it is simple to defer done until killed

finishes. If a rapid response is necessary, then done mustbe able to run before killed finishes, resulting in a Dan-gling Worker problem: an API’s work implementationmay access externally-visible state after the Event Loopreceives the associated TimeoutError. We addressed theDangling Worker problem in Node.js’s Worker Pool cus-tomers using a mix of killed-waiting, message passing,and blacklisting.

Timeout-aware Worker Pool Customers. TheNode.js APIs affected by this change (i.e. those that cre-ate Tasks) are in the encryption, compression, DNS, andfile system modules. In all cases we allowed timeouts toproceed, killing the long-running Worker. Handling en-cryption and compression was straightforward, while theDNS and file system APIs were more complex.

Node.js’s asynchronous encryption and compressionAPIs are implemented in Node.js C++ bindings by in-voking APIs from openssl and zlib, respectively. If theWorker Pool notifies these APIs of a timeout, they waitfor the Worker to be killed before returning, to ensureit no longer modifies state in these “black-box” librariesnor accesses memory that might be released after done

is invoked. Since openssl and zlib are purely computa-tional, the Dangling Worker is killed immediately.

Node.js implements its file system and DNS APIs byrelying on libuv’s file system and DNS support, whichon Linux make the appropriate calls to libc. Because thelibuv file system and DNS implementations share mem-

8

ory between the Worker and the submitter, we modifiedthem to use message passing for memory safety of Dan-gling Workers — wherever the original implementation’swork accessed memory owned by the submitter, e.g. forread and write, we introduced a private buffer for workand added copyin/copyout steps. In addition, we usedpthread setcancelstate to ensure that Workers will notbe killed while in a non-cancelable libc API [6]. DNSis read-only so there is no risk of the Dangling Workermodifying external state. In the file system, write mod-ifies external state, but we avoid any Dangling Workerstate pollution via blacklisting. Our blacklisting-basedSlow Resource policy is discussed in more detail in §7.4.

At the top of the Node.js stack, when the Event Loopsees that a Task timed out, it invokes the application’sCallback with a TimeoutError.

7.2 Timeouts for CallbacksNode.cure defends against EHP attacks that target theEvent Loop by bounding the synchronous time of Call-backs. To make Callbacks timeout-aware, we introducea TimeoutWatchdog that monitors the start and end ofeach Callback and ensures that no Callback exceeds thetimeout threshold. We time out JavaScript instructionsusing V8’s interrupt mechanism (§7.2.1), and we mod-ify Node.js’s C++ bindings to ensure that Callbacks thatenter these bindings will also be timed out (§7.2.2).

7.2.1 Timeouts for JavaScript

TimeoutWatchdog. Our TimeoutWatchdog instru-ments every Callback using the experimental Node.jsasync-hooks module [16], which allows an applicationto register special Callbacks before and after a Callbackis invoked.

Before a Callback begins, our TimeoutWatchdog startsa timer. If the Callback completes before the timer ex-pires (“good path”), we erase the timer. If the timer ex-pires, the watchdog signals V8 to interrupt JavaScript ex-ecution by throwing a TimeoutError. The watchdog thenstarts another timer, ensuring that timeouts while han-dling the previous TimeoutError are also detected.

Although a precise TimeoutWatchdog can be imple-mented to carefully honor the timeout threshold, theresulting communication overhead between the EventLoop and the TimeoutWatchdog can be non-trivial(§8.2). A cheaper alternative is a lazy TimeoutWatch-dog, which simply wakes up at intervals of the timeoutthreshold and checks whether the Callback it last ob-served is still executing; if so, it emits a TimeoutError.A lazy TimeoutWatchdog reduces the overhead of mak-ing a Callback, but decreases the precision of theTimeoutError threshold.

V8 interrupts. To handle the TimeoutWatchdog’s re-quest for a TimeoutError, Node.cure extends the inter-

rupt infrastructure of Node.js’s V8 JavaScript engine [3]to support timeouts. In V8, low priority interrupts likea pending garbage collection are checked regularly (e.g.each loop iteration, function call, etc.), but no earlier thanafter the current JavaScript instruction finishes. Highpriority interrupts take effect immediately, interruptinglong-running JavaScript instructions. Timeouts requirethe use of a high priority interrupt because they must beable to interrupt long-running individual JavaScript in-structions like str.match(regexp) (possible ReDoS).

To support a TimeoutError, we modified V8 as fol-lows: (1) We added the definition of a TimeoutError

into the Error class hierarchy; (2) We added aTimeoutInterrupt into the list of high-priority in-terrupts; and (3) We added a V8 API to raise aTimeoutInterrupt. The TimeoutWatchdog calls thisAPI, which interrupts the current JavaScript stack bythrowing a TimeoutError.

The only JavaScript instructions that V8 instrumentsto be interruptible are regexp matching and JSONparsing; these are the language-level Vulnerable APIs.Other JavaScript instructions are viewed as effectivelyconstant-time, so these interrupts are evaluated e.g. atthe end of basic blocks. We agreed with the V8 devel-opers in this5, and did not attempt to instrument otherJavaScript instructions to poll for pending interrupts.

7.2.2 Timeouts for the Node.js C++ bindings

The TimeoutWatchdog described in §7.2.1 will inter-rupt any Vulnerable APIs implemented in JavaScript, in-cluding language-level APIs like regexp and application-level APIs that contain blocking code like while(1);. Itremains to give a sense of time to the Node.js C++ bind-ings that allow the JavaScript code in Node.js applica-tions to interface with the broader world.

Node.js has asynchronous and synchronous C++ bind-ings. The asynchronous bindings are safe because theydo a fixed amount of work synchronously to submit aTask and then return. However, the synchronous C++bindings complete the entire operation on the Event Loopbefore returning, and therefore must be given a senseof time. The relevant Vulnerable synchronous APIs arethose in the file system, cryptography, and compressionmodules. The execSync API is also Vulnerable, but isonly intended for scripting purposes.

Because the Event Loop holds the state of all pend-ing clients, we cannot use the Hangman pthread cancel

approach, as this would result in the DoS the at-tacker desired. Another alternative is to offload therequest to the Worker Pool and await its completion,but this would incur high request latencies when the

5For example, we found that string operations complete in millisec-onds even when a string is hundreds of MBs long.

9

Worker Pool’s queue is not empty. Instead, we ex-tended the Worker Pool paradigm with a dedicated Pri-ority Executor whose queue is exposed via a new API:uv queue work prio (Figure 5). This Executor followsthe same Manager-Worker-Hangman paradigm as theExecutors in Node.cure’s Worker Pool. To make theseVulnerable synchronous APIs timeout-aware, we offloadthem to the Priority Executor using the existing asyn-chronous implementation of the API, and had the EventLoop await the result. Because these synchronous APIsare performed on the Event Loop as part of a Callback,we propagate the Callback’s remaining time to this Ex-ecutor’s Manager to ensure that the TimeoutWatchdog’stimer is honored.

7.3 Timeouts for application-level Vulnerable APIsLet us revisit Node.cure’s composability guarantee. Asdescribed above, Node.cure makes Tasks (§7.1) andCallbacks (§7.2) timeout-aware to defeat EHP attacksagainst language and framework APIs. The Timeout Ap-proach is composable, so an application composed ofcalls to these APIs will be EHP-safe.

However, applications can still escape the reach of theTimeout Approach by defining their own C++ bindings.These bindings would need to be made timeout-aware,following the example we set while making Node.js’sVulnerable C++ bindings timeout-aware (file system,DNS, encryption, and compression). Without refactor-ing, applications with their own C++ bindings may not beEHP-safe. In our evaluation we found that application-defined C++ bindings are rare (§8.3).

7.4 Exploring policies for slow resourcesOur Node.cure runtime detects and aborts long-runningCallbacks and Tasks executing on Node.js’s Event Han-dlers. For unique evil input this is the best we can do, asaccurately predicting whether a not-yet-seen input willtime out is difficult. If an attacker might re-use the sameevil input multiple times, however, we can track whetheror not an input led to a timeout and short-circuit subse-quent requests that use this input with an early timeout.

While evil input memoization could in principle be ap-plied to any API, the size of the input space to track is alimiting factor. The evil inputs that trigger CPU-boundEHP attacks like ReDoS exploit properties of the vulner-able algorithm and are thus usually not unique. In con-trast, the evil inputs that trigger I/O-bound EHP attackslike ReadDoS must name a particularly slow resource,presenting an opportunity to short-circuit requests on thisslow resource.

In Node.cure we implemented a slow resource man-agement policy for libuv’s file system APIs, targetingthose that reference a single resource (e.g. open, read,write). When one of the APIs we manage times out, we

mark the file descriptor and the associated inode num-ber as slow. We took the simple approach of perma-nently blacklisting these aliases by aborting subsequentaccesses6, with the happy side effect of solving the Dan-gling Worker problem for write. This policy is appropri-ate for the file system, where access times are not likelyto change7. For DNS queries, timeouts are likely due to anetwork hiccup, and a temporary blacklist might be moreappropriate.

7.5 Prototype detailsNode.cure is built on top of Node.js LTS v8.8.18, a re-cent long-term support version of Node.js. Our proto-type is for Linux, and added 4,000 lines of C, C++,and JavaScript code across 50 files spanning V8, libuv,the Node.js C++ bindings, and the Node.js JavaScript li-braries.

Node.cure is a complete and correct implementationof the Timeout Approach. It passes the core Node.js testsuite, with a handful of failures due to bad interactionswith experimental or deprecated features. In addition,several cases fail when they invoke rarely-used file sys-tem APIs we did not make timeout-aware. Real applica-tions run on Node.cure without difficulty (Table 3).

In Node.cure, timeouts for Callbacks and Tasks arecontrolled by environment variables. Our implementa-tion would readily accommodate a fine-grained assign-ment of timeouts for individual Callbacks and Tasks.

8 Evaluating Node.cureWe evaluated Node.cure in terms of its effectiveness(§8.1), costs (§8.2), and security guarantees (§8.3). Insummary: with a lazy TimeoutWatchdog, Node.cure de-feats all known EHP attacks with low overhead on the“good path”, estimated at 1.3x using micro-benchmarksand manifesting at 1.0x-1.24x using real applications.Node.cure guarantees EHP-safety to all Node.js appli-cations that do not define their own C++ bindings, a rarepractice.

All measurements provided in this section were ob-tained on an otherwise-idle desktop running Ubuntu16.04.1 (Linux 4.8.0-56-generic), 16GB RAM, Intel i7@3.60GHz, 4 physical cores with 2 threads per core.For a baseline we used Node.js LTS v8.8.1 from whichNode.cure was derived, compiled with the same flags.We used a default Worker Pool (4 Workers).

8.1 EffectivenessTo evaluate the effectiveness of Node.cure, we devel-oped an EHP test suite that makes EHP attacks of all

6To avoid fd leaks, we do not eagerly abort close.7Of course, if the slow resource is in a networked file system like

NFS or GPFS, slowness might be due to a network hiccup, and incorpo-rating temporary device-level blacklisting might be more appropriate.

8Node.js v8.8.1 commit dc6bbb44da on Oct. 25, 2017.

10

types shown in Table 1. Our suite is comprehensive andconducts EHP attacks using every Vulnerable API weidentified, including the language level (regexp, JSON),framework level (all Vulnerable APIs from the file sys-tem, DNS, cryptography, and compression modules),and application level (infinite loops, long string opera-tions, array sorting, etc.). This test suite includes eachtype of real EHP attack from our study of EHP vulner-abilities in npm modules (§4.2). Node.cure defeats all92 EHP attacks in this suite: each synchronous Vulnera-ble API throws a TimeoutError, and each asynchronousVulnerable API returns a TimeoutError.

To finish our suite, we ported a vulnerable npm mod-ule to Node.cure. We selected the node-oniguruma [14]module, which offers asynchronous regexp APIs. Sincethe Oniguruma regexp engine is vulnerable to ReDoS,its APIs are Vulnerable, but they evaluate the regexps in aTask rather than in a Callback, poisoning a Worker ratherthan the Event Loop. We made node-oniguruma timeout-aware by using the modified Worker Pool uv queue work

API (Table 2). Node.cure times out ReDoS attacksagainst this module’s Vulnerable APIs.

8.2 CostsThe Timeout Approach introduces runtime overheads,which we evaluated using micro-benchmarks and macro-benchmarks. It may also require some refactoring, and achoice of timeout.

Overhead: Micro-benchmarks. Whether or not theytime out, Node.cure introduces several sources of over-heads to monitor Callbacks and Tasks. We evaluated thefollowing overheads using micro-benchmarks:1. Every time V8 checks for interrupts, it now tests for a

pending timeout as well.2. Both the lazy and precise versions of the Timeout-

Watchdog instrument every asynchronous Callbackusing async-hooks, with relative overhead dependenton the complexity of the Callback.

3. To ensure memory safety for Dangling Workers,Workers operate on buffered data that must be al-located when the Task is submitted. For example,Workers must copy the I/O buffers supplied to read

and write twice.New V8 interrupt. We found that the overhead of our

V8 Timeout interrupt was negligible, simply a test forone more interrupt in V8’s interrupt infrastructure.

TimeoutWatchdog’s async hooks. We measured theadditional cost of invoking a Callback due to Timeout-Watchdog’s async hooks. A lazy TimeoutWatchdog in-creases the cost of invoking a Callback by 2.4x, and aprecise TimeoutWatchdog increases the cost by 7.9x. Ofcourse, this overhead is most noticeable in Callbacks thatare empty. As the number of instructions in a Callbackincreases, the cost of the hooks amortizes. For exam-

ple, if the Callback executes 500 empty loop iterations,the lazy overhead drops to 1.3x and the precise overheaddrops to 2.7x; at 10,000 empty loop iterations, the lazyand precise overheads are 1.01x and 1.15x, respectively.

Worker buffering. Our timeout-aware Worker Pool re-quires buffering data to accommodate Dangling Work-ers, affecting DNS queries and file system I/O. Whilethis overhead will vary from API to API, our micro-benchmark indicated a 1.3x overhead using read andwrite calls with a 64KB buffer.

Overhead: Macro-benchmarks. Our micro-benchmarks suggested that the overhead introduced byNode.cure may vary widely depending on what an ap-plication is doing. Applications that make little use ofthe Worker Pool will only pay the overhead of the ad-ditional V8 interrupt (minimal) and the TimeoutWatch-dog’s async hooks, whose cost is strongly dependenton the size of the Callbacks. Applications that use theWorker Pool will also pay the overhead of Worker buffer-ing (variable, perhaps 1.3x).

We chose macro-benchmarks using a GitHub pot-pourri technique: we searched GitHub for “lan-guage:JavaScript”, sorted by “Most starred”, and iden-tified server-side projects from the first 50 results. Toadd additional complete servers, we also included Lok-iJS [11], a popular Node.js-based key-value store, andIBM’s Acme-Air airline simulation [2].

Table 3 lists the macro-benchmarks we used and theperformance overhead for each type of TimeoutWatch-dog. These results show that Node.cure introduces min-imal overhead on real server applications, and they con-firm the value of a lazy TimeoutWatchdog. Matching ourmicro-benchmark assessment of the TimeoutWatchdog’sasync-hooks overhead, the overhead from Node.cure in-creased as the complexity of the Callbacks used in themacro-benchmarks decreased — the middleware bench-marks sometimes used empty Callbacks to handle clientrequests. In non-empty Callbacks like those of the realservers, this overhead is amortized.

Refactoring. Node.cure adds a TimeoutError to theJavaScript and Node.js specifications. See §9.

Choice of timeout. See §6.4 and §9.

8.3 Security GuaranteesWe discussed the general security guarantees of theTimeout Approach in §6.4. Here we discuss the precisesecurity guarantees of our Node.cure prototype. As de-scribed in §7, we gave a sense of time to JavaScript (in-cluding interrupting long-running regexp and JSON op-erations) as well as to framework APIs identified by theNode.js developers as long-running (file system, DNS,cryptography, and compression).

Because the Timeout Approach is composable,application-level APIs composed of these timeout-aware

11

Benchmark Description OverheadsLokiJS [11] Server, Key-value store 1.00, 1.00

Node Acme-Air [2] Server, Airline simulation 1.02, 1.03webtorrent [29] Server, P2P torrenting 1.02, 1.02

ws [30] Utility, websockets 1.00, 1.00*Three.js [26] Utility, graphics library 1.08, 1.09Express [5] Middleware 1.06, 1.24Sails [24] Middleware 1.14, 1.23*

Restify [23] Middleware 1.14, 1.63*Koa [9] Middleware 1.24, 1.60

Table 3: Results of our macro-benchmark evaluation of Node.cure’soverhead. Where available, we used the benchmarks defined by theproject itself. Otherwise, we ran its test suite. Overheads are reportedas “lazy, precise”, and are the ratio of Node.cure’s performance to thatof the baseline Node.js, averaged over several steady-state runs. Wereport the average overhead because we observed no more than 3%standard deviation in all but LokiJS, which averaged 8% standard de-viation across our samples of its sub-benchmarks. *: Median of sub-benchmark overheads.

language and framework APIs are also timeout-aware.However, Node.js also permits applications to add theirown C++ bindings, and these will not be timeout-awarewithout refactoring.

To evaluate the extent of this limitation, we measuredhow frequently developers use C++ bindings. To thisend, we examined a sample of npm modules. We npm

install’d 125,173 modules (about 20% of the ecosys-tem) using node v8.9.1 (npm v5.5.1), resulting in 23,070successful installations9. Of these, 695 (3%) had C++bindings10.

From this we conclude that the use of user-definedC++ bindings is uncommon in npm modules, unsur-prising since many developers in this community comefrom client-side JavaScript and may not have strong C++skills. This implies, but does not directly indicate, thatC++ bindings are unusual in Node.js applications. Weconclude that the need to refactor C++ bindings to betimeout-aware would not place a significant burden onthe community. As a template, we performed severalsuch refactorings ourselves in the Node.js framework andour port of node-oniguruma.

9 DiscussionWhat should the EDA community do without time-outs? Although they lack first-class timeouts, develop-ers in the EDA community must still be concerned aboutEHP attacks. We believe their best approach is the C-WCET Principle (§6.3).

We have pursued a two-pronged approach to help de-velopers in the Node.js community follow the C-WCET

9Module installations failed for reasons including “No such mod-ule”, “Unsupported OS”, and “Unsupported Node.js version”.

10We determined the presence of C++ bindings by searching a mod-ule’s directory tree for files with endings like “.h” and “.c[pp]”.

Principle11. First, we submitted a PR with a guideto building EHP-safe EDA-based applications. It wasmerged and can be found on nodejs.org, where newNode.js developers go to learn best practices for Node.jsdevelopment. We believe that it will give developers in-sights into secure Node.js programming practices.

Second, we studied the Node.js implementationand identified several unnecessarily Vulnerable APIsin Node.js (fs.readFile, crypto.randomFill, andcrypto.randomBytes, all of which submit a single un-partitioned Task). Our PRs warning developers aboutthe risks of EHP attacks using these APIs have beenmerged. We also submitted a trial pull request repair-ing the simplest of these, by partitioning fs.readFile. Itwas been merged after a multi-month discussion on theperformance-security tradeoff involved.

What might timeout-aware programs look like? Asdiscussed in §7, applying the Timeout Approach whilepreserving the EDA changes the language and frame-work specifications. In particular, all synchronous APIsmay now throw a TimeoutError, and all asynchronousAPIs may now be fulfilled with a TimeoutError. Thesechanges have two implications for application develop-ers: Timeout-aware applications must be able to toler-ate arbitrary TimeoutErrors (just like any other excep-tion), and developers should pursue low-variance Call-backs and Tasks (to permit the choice of a tighter timeoutthreshold).

Are there other avenues toward EHP-safety? In§6 we discussed several EHP-safe designs. There are ofcourse other approaches, like significantly increasing thesize of the Worker Pool, performing speculative concur-rent execution [47], or using explicitly preemptable Call-backs and Tasks. However, each of these is a variationon the same theme: dedicating resources to every client,i.e. the One Thread Per Client Architecture. If the servercommunity wishes to use the EDA, which offers highresponsiveness and scalability through the use of coop-erative multitasking, we believe the Timeout Approachis a good path to EHP-safety.

10 Related WorkThroughout the paper we have referred to specific relatedwork. Here we place our work in its broader context, sit-uated at the intersection of the Denial of Service litera-ture and the Event-Driven Architecture community.

Denial of Service attacks. Research on DoS canbe broadly divided into network-level attacks (e.g. dis-tributed DoS attacks) and application-level attacks [40].Since EHP attacks exploit the semantics of the appli-cation, they are application-level attacks, not easily de-feated by network-level defenses.

11We omit references to meet the double-blind requirement.

12

DoS attacks seek to exhaust the resources critical tothe proper operation of a server, and various kinds ofexhaustion have been considered. The brunt of the lit-erature has focused on exhausting the CPU. Some haveexamined the gap between common-case and worst-caseperformance in algorithms and data structures, for ex-ample in quicksort [75], hashing [52], and exponentiallybacktracking algorithms like ReDoS [51, 89] and rulematching [91]. Other CPU-centric DoS attacks have tar-geted more general programming issues, showing how totrigger infinite recursion [48] and how to trigger [92] ordetect [44] infinite loops. But the CPU is not the onlyvulnerable resource, as shown by Olivo et al.’s work pol-luting databases to increase the cost of queries [79]. Weare not aware of prior research work that incurs DoS us-ing the file system, as do our ReadDoS attacks, thoughwe have found a handful of CVE reports to this effect12

Our work identifies and shows how to exploit themost limited resource of the EDA: Event Handlers. Tolaunch a similar attack in the OTPCA, attackers mustsubmit enough queries to overwhelm the OS’s preemp-tive scheduler, no mean feat. In contrast, in the EDAthere are only a few Event Handlers to be poisoned. Al-though we prove our point using previously-reported at-tacks like ReDoS, the underlying resource we are ex-hausting is not the CPU but the small, fixed-size set ofEvent Handlers deployed in EDA-based services.

Security in the EDA. Though researchers have stud-ied security vulnerabilities in different EDA frameworks,most prominently client-side applications, the securityproperties of the EDA itself have not been investigatedin detail.

Our work is most closely related to the workshop pa-per of Davis et al. [53], discussed earlier (§2.4). Lessimmediately relevant is the Node.js-specific high-levelsurvey of Ojamaa et al. [78], which mentioned the rule“Don’t block the event loop”, and Staicu and Pradel’sstudy on code injection vulnerabilities in npm [94],which can be used for EHP attacks. DeGroef et al. [56]’sproposed method to securely integrate third-party mod-ules from npm is not effective for EHP attacks becauseNode.js lacks a sense of time.

More broadly, other security research in the EDA hasstudied client-side JavaScript/Web [71, 69, 55, 76] andJava/Android [59, 58, 43, 68] applications. These haveoften focused on platform-specific issues like DOM issuesin web browsers [71].

EHP attacks. The server-side EDA practitioner com-munity is aware of the risk of DoS due to (synchronous)EHP on the Event Loop. A common rule of thumb is

12For Slow Files (/dev/random), see CVE-2012-1987 and CVE-2016-6896. For a related DOS by reading Large Files, CVE-2001-0834, CVE-2008-1353, CVE-2011-1521, and CVE-2015-5295 men-tion DoS by ENOMEM using /dev/zero.

“Don’t block the Event Loop”, advised by many tuto-rials as well as recent books about EDA programmingfor Node.js [97, 46]. Wandschneider suggests worst-caselinear-time partitioning on the Event Loop [97], whileCasciaro advises developers to partition any computationon the Event Loop, and to offload computationally ex-pensive tasks to the Worker Pool [46]. Our work offers amore rigorous taxonomy and evaluation of EHP attacks,and in particular we extend the rule of “Don’t block theEvent Loop” to the Worker Pool.

EHP attacks on the server side may correspond to per-formance bugs in client-side EDA programs. Liu et al.studied such bugs [73], and Lin et al. proposed an au-tomatic refactoring to offload expensive tasks from theEvent Loop to the Worker Pool [72]. This approach issound on a client-side system like Android, where thedemand for threads is limited, but is not applicable tothe server-side EDA because the small Worker Pool isshared among all clients. For the server-side EDA, Lin etal.’s approach would need to be extended to incorporateautomatic C-WCET partitioning.

As future work, we believe that research into compu-tational complexity estimation ([80, 66, 85]) and mea-surement ([86, 64, 45]) might be adapted to the Node.jscontext for EHP vulnerability detection and automaticrefactoring using the C-WCET Principle. This may bedifficult because of the complexity of statically analyz-ing JavaScript and the EDA ([74, 42, 65, 98, 60]).

11 Conclusion

The Event-Driven Architecture (EDA) holds greatpromise for scalable web services, and it is increasinglypopular in the software development community. In thispaper we formally defined Event Handler Poisoning at-tacks, which exploit the the cooperative multitasking atthe heart of the EDA. The Node.js community has en-dorsed our expression of this problem, hosting our guideat nodejs.org.

We proposed several defenses against EHP attacks,and prototyped the most promising: first-class time-outs. Our prototype, Node.cure, defends Node.js appli-cations against all known EHP attacks. It is available onGitHub13.

Our findings can be directly applied by the EDA com-munity, and we hope they influence the design of existingand future EDA frameworks. With the rise of popularityin the EDA, EHP attacks will become an increasinglycritical DoS vector, a vector that can be defeated withfirst-class timeouts.

13We omit the reference to meet the double-blind requirement.

13

References[1] ab – apache http server benchmarking tool. https://httpd.

apache.org/docs/2.4/programs/ab.html.

[2] acmeair-node. https://github.com/acmeair/

acmeair-nodejs.

[3] Chrome V8.

[4] Cylon.js. https://cylonjs.com/.

[5] express. https://github.com/expressjs/express.

[6] Gnu libc – posix safety concepts. https://www.

gnu.org/software/libc/manual/html_node/

POSIX-Safety-Concepts.html.

[7] Ibm node-red. https://nodered.org/.

[8] iot-nodejs. https://github.com/ibm-watson-iot/

iot-nodejs.

[9] Koa. https://github.com/koajs/koa.

[10] libuv. https://github.com/libuv/libuv.

[11] Lokijs. https://github.com/techfort/LokiJS.

[12] Module Counts.

[13] Mozilla developer network: Javascript. https://developer.

mozilla.org/en-US/docs/Web/JavaScript.

[14] Node-oniguruma regexp library. https://github.com/atom/node-oniguruma.

[15] Node.js. http://nodejs.org/.

[16] Nodejs async hooks. https://nodejs.org/api/async_

hooks.html.

[17] Node.js developer guides. https://nodejs.org/en/docs/

guides/.

[18] Node.js foundation members. https://foundation.nodejs.org/about/members.

[19] Node.js thread pool documentation. http://docs.libuv.

org/en/v1.x/threadpool.html.

[20] Node.js usage: Statistics for websites using node.js technologies.https://trends.builtwith.com/framework/node.js.

[21] Node.js v8.9.1 documentation. https://nodejs.org/dist/

latest-v8.x/docs/api/.

[22] Regex.matchtimeout property. https://msdn.

microsoft.com/en-us/library/system.text.

regularexpressions.regex.matchtimeout.

[23] restify. https://github.com/restify/node-restify.

[24] sails. https://github.com/balderdashy/sails.

[25] Snyk.io. https://snyk.io/vuln/.

[26] three.js. https://github.com/mrdoob/three.js.

[27] Twisted.

[28] Vert.x. http://vertx.io/.

[29] webtorrent. https://github.com/webtorrent/

webtorrent.

[30] ws: a node.js websocket library. https://github.com/

websockets/ws.

[31] The Calendar and Contacts Server. https://github.com/

Apple/Ccs-calendarserver, 2007.

[32] Ubuntu One: Technical Details. https://wiki.ubuntu.com/UbuntuOne/TechnicalDetails, 2012.

[33] New node.js foundation survey reports new “full stack” indemand among enterprise developers. https://nodejs.org/

en/blog/announcements/nodejs-foundation-survey/,2016.

[34] 2017 User Survey Executive Summary. The Linux Foundation,2017.

[35] The linux foundation: Case study: Node.js. https:

//www.linuxfoundation.org/wp-content/uploads/

2017/06/LF_CaseStudy_NodeJS_20170613.pdf, 2017.

[36] Random(4). http://man7.org/linux/man-pages/man4/

random.4.html, 2017.

[37] This is what node.js is used for in 2017 – sur-vey results. https://blog.risingstack.com/

what-is-node-js-used-for-2017-survey/, 2017.

[38] How cond nast used node.js to unify brands and create cus-tomer faith. https://www2.thelinuxfoundation.org/

node-casestudies-condenast, 2018.

[39] ABDALKAREEM, R., NOURRY, O., WEHAIBI, S., MUJAHID,S., AND SHIHAB, E. Why Do Developers Use Trivial Packages?An Empirical Case Study on npm. In Foundations of SoftwareEngineering (FSE) (2017).

[40] ABLIZ, M. Internet Denial of Service Attacks and DefenseMechanisms. Tech. rep., 2011.

[41] ALIMADADI, S., MESBAH, A., AND PATTABIRAMAN, K. Un-derstanding Asynchronous Interactions in Full-Stack JavaScript.ICSE (2016).

[42] ARZT, S., RASTHOFER, S., FRITZ, C., BODDEN, E., BARTEL,A., KLEIN, J., LE TRAON, Y., OCTEAU, D., AND MCDANIEL,P. Flowdroid: Precise context, flow, field, object-sensitive andlifecycle-aware taint analysis for android apps. In PLDI (2014).

[43] BARRERA, D., KAYACIK, H. G., VAN OORSCHOT, P. C.,AND SOMAYAJI, A. A methodology for empirical analysis ofpermission-based security models and its application to android.In CCS (2010).

[44] BURNIM, J., JALBERT, N., STERGIOU, C., AND SEN, K.Looper: Lightweight detection of infinite loops at runtime. InInternational Conference on Automated Software Engineering(ASE) (2009).

[45] BURNIM, J., JUVEKAR, S., AND SEN, K. WISE: AutomatedTest Generation for Worst-Case Complexity. In InternationalConference on Software Engineering (ICSE) (2009).

[46] CASCIARO, M. Node.js Design Patterns, 1 ed. 2014.

[47] CHADHA, G., MAHLKE, S., AND NARAYANASAMY, S. Ac-celerating Asynchronous Programs Through Event Sneak Peek.In International Symposium on Computer Architecture (ISCA)(2015).

[48] CHANG, R., JIANG, G., IVANCIC, F., SANKARANARAYANAN,S., AND SHMATIKOV, V. Inputs of coma: Static detection ofdenial-of-service vulnerabilities. In IEEE Computer SecurityFoundations Symposium (CSF) (2009).

[49] CORRY, E., HANSEN, C. P., AND NIELSEN, L. R. H. Irregexp,Google Chrome’s New Regexp Implementation, 2009.

[50] COX, R. Regular Expression Matching Can Be Simple And Fast(but is slow in Java, Perl, PHP, Python, Ruby, ...), 2007.

[51] CROSBY, S. Denial of service through regular expressions.USENIX Security work in progress report (2003).

[52] CROSBY, S. A., AND WALLACH, D. S. Denial of Service viaAlgorithmic Complexity Attacks. In USENIX Security (2003).

[53] DAVIS, J., KILDOW, G., AND LEE, D. The Case of the PoisonedEvent Handler: Weaknesses in the Node.js Event-Driven Archi-tecture. In European Workshop on Systems Security (EuroSec)(2017).

14

[54] DAVIS, J., THEKUMPARAMPIL, A., AND LEE, D. Node.fz:Fuzzing the Server-Side Event-Driven Architecture. In EuropeanConference on Computer Systems (EuroSys) (2017).

[55] DE GROEF, W., DEVRIESE, D., NIKIFORAKIS, N., ANDPIESSENS, F. Flowfox: A web browser with flexible and pre-cise information flow control. CCS.

[56] DE GROEF, W., MASSACCI, F., AND PIESSENS, F. NodeSen-try: Least-privilege library integration for server-side JavaScript.In Annual Computer Security Applications Conference (ACSAC)(2014).

[57] DESAI, A., GUPTA, V., JACKSON, E., QADEER, S., RAJA-MANI, S., AND ZUFFEREY, D. P: Safe asynchronous event-driven programming. In ACM SIGPLAN Conference on Pro-gramming Language Design and Implementation (PLDI) (2013).

[58] ENCK, W., OCTEAU, D., MCDANIEL, P., AND CHAUDHURI,S. A study of android application security. In USENIX Security(2011).

[59] ENCK, W., ONGTANG, M., AND MCDANIEL, P. Understandingandroid security. IEEE Security and Privacy (2009).

[60] FENG, Y., ANAND, S., DILLIG, I., AND AIKEN, A. Ap-poscopy: Semantics-based detection of android malware throughstatic analysis. In FSE (2014).

[61] FERG, S. Event-driven programming: introduction, tutorial, his-tory. 2006.

[62] FOUNDATION, A. S. The Apache web server.

[63] FREES, S. C++ and Node.js Integration. 2016.

[64] GOLDSMITH, S. F., AIKEN, A. S., AND WILKERSON, D. S.Measuring Empirical Computational Complexity. In Foundationsof Software Engineering (FSE) (2007).

[65] GORDON, M. I., KIM, D., PERKINS, J., GILHAMY, L.,NGUYENZ, N., , AND RINARD, M. Information flow analysisof android applications in droidsafe. In NDSS (2015).

[66] GULWANI, S., MEHRA, K. K., AND CHILIMBI, T. SPEED:Precise and Efficient Static Estimation of Program ComputationalComplexity. In Principles of Programming Languages (POPL)(2009).

[67] HARRELL, J. Node.js at PayPal, 2013.

[68] HEUSER, S., NADKARNI, A., ENCK, W., AND SADEGHI, A.-R. Asm: A programmable interface for extending android secu-rity. In Proceedings of the 23rd USENIX Conference on SecuritySymposium (2014), SEC’14.

[69] JIN, X., HU, X., YING, K., DU, W., YIN, H., AND PERI, G. N.Code injection attacks on html5-based mobile apps: Characteri-zation, detection and mitigation. In CCS (2014).

[70] KIRRAGE, J., RATHNAYAKE, A., AND THIELECKE, H. StaticAnalysis for Regular Expression Denial-of-Service Attacks. Net-work and System Security 7873 (2013), 35–148.

[71] LEKIES, S., STOCK, B., AND JOHNS, M. 25 million flows later:Large-scale detection of dom-based xss. In CCS (2013).

[72] LIN, Y., RADOI, C., AND DIG, D. Retrofitting Concurrencyfor Android Applications through Refactoring. In ACM Interna-tional Symposium on Foundations of Software Engineering (FSE)(2014).

[73] LIU, Y., XU, C., AND CHEUNG, S.-C. Characterizing and de-tecting performance bugs for smartphone applications. In Inter-national Conference on Software Engineering (ICSE) (2014).

[74] MADSEN, M., TIP, F., AND LHOTAK, O. Static analysis ofevent-driven Node. js JavaScript applications. In ACM SIGPLANInternational Conference on Object-Oriented Programming, Sys-tems, Languages, and Applications (OOPSLA) (2015), ACM.

[75] MCILROY, M. D. Killer adversary for quicksort. Software -Practice and Experience 29, 4 (1999), 341–344.

[76] NIKIFORAKIS, N., INVERNIZZI, L., KAPRAVELOS, A.,VAN ACKER, S., JOOSEN, W., KRUEGEL, C., PIESSENS, F.,AND VIGNA, G. You are what you include: Large-scale evalua-tion of remote javascript inclusions. In CCS (2012).

[77] O’DELL, J. Exclusive: How LinkedIn used Node.js and HTML5to build a better, faster app, 2011.

[78] OJAMAA, A., AND DUUNA, K. Assessing the security ofNode.js platform. In 7th International Conference for InternetTechnology and Secured Transactions (ICITST) (2012).

[79] OLIVO, O., DILLIG, I., AND LIN, C. Detecting and Exploit-ing Second Order Denial-of-Service Vulnerabilities in Web Ap-plications. ACM Conference on Computer and CommunicationsSecurity (CCS) (2015).

[80] OLIVO, O., DILLIG, I., AND LIN, C. Static Detection of Asymp-totic Performance Bugs in Collection Traversals. PLDI (2015).

[81] PADMANABHAN, S. How We Built eBays First Node.js Appli-cation, 2013.

[82] PAI, V. S., DRUSCHEL, P., AND ZWAENEPOEL, W. Flash: AnEfficient and Portable Web Server. In USENIX Annual TechnicalConference (ATC) (1999).

[83] PARIAG, D., BRECHT, T., HARJI, A., BUHR, P., SHUKLA, A.,AND CHERITON, D. R. Comparing the performance of webserver architectures. In European Conference on Computer Sys-tems (EuroSys) (2007), ACM.

[84] PETER, S., BAUMANN, A., ROSCOE, T., BARHAM, P., ANDISAACS, R. 30 seconds is not enough! In European Conferenceon Computer Systems (EuroSys) (2008).

[85] PETSIOS, T., ZHAO, J., KEROMYTIS, A. D., AND JANA, S.SlowFuzz: Automated Domain-Independent Detection of Algo-rithmic Complexity Vulnerabilities. In Computer and Communi-cations Security (CCS) (2017).

[86] PUSCHNER, P. P., AND KOZA, C. Calculating the MaximumExecution Time of Real-Time Programs. Real-Time Systems 1, 2(1989), 159–176.

[87] RATHNAYAKE, A., AND THIELECKE, H. Static Analysis forRegular Expression Exponential Runtime via Substructural Log-ics. CoRR (2014).

[88] RAYMOND, E. S. The Cathedral and the Bazaar. No. July 1997.2000.

[89] ROICHMAN, A., AND WEIDMAN, A. VAC - ReDoS: RegularExpression Denial Of Service. Open Web Application SecurityProject (OWASP) (2009).

[90] SILBERSCHATZ, A., GALVIN, P. B., AND GAGNE, G. Operat-ing System Concepts, 9th ed. Wiley Publishing, 2012.

[91] SMITH, R., ESTAN, C., AND JHA, S. Backtracking AlgorithmicComplexity Attacks Against a NIDS. In ACSAC (2006), pp. 89–98.

[92] SON, S., AND SHMATIKOV, V. SAFERPHP Finding SemanticVulnerabilities in PHP Applications. In Workshop on Program-ming Languages and Analysis for Security (PLAS) (2011), pp. 1–13.

[93] STAICU, C.-A., PRADEL, M., AND DARMSTADT, T. Freezingthe Web: A Study of ReDoS Vulnerabilities in JavaScript-basedWeb Servers.

[94] STAICU, C.-A., PRADEL, M., AND LIVSHITS, B. Understand-ing and Automatically Preventing Injection Attacks on Node.js.Tech. rep., 2016.

[95] SULLIVAN, B. Security Briefs - Regular Expression Denial ofService Attacks and Defenses. Tech. rep., 2010.

15

[96] VAN DER MERWE, B., WEIDEMAN, N., AND BERGLUND, M.Turning Evil Regexes Harmless. In SAICSIT (2017).

[97] WANDSCHNEIDER, M. Learning Node.js: A Hands-on Guideto Building Web Applications in JavaScript. Pearson Education,2013.

[98] WEI, F., ROY, S., OU, X., AND ROBBY. Amandroid: A preciseand general inter-component data flow analysis framework for se-

curity vetting of android apps. In Proceedings of the 2014 ACMSIGSAC Conference on Computer and Communications Security(2014), CCS ’14.

[99] WELSH, M., CULLER, D., AND BREWER, E. SEDA : An Ar-chitecture for Well-Conditioned, Scalable Internet Services. InSymposium on Operating Systems Principles (SOSP) (2001).

16