Browse Prior Art Database

System, Method and Apparatus for Hybrid Prevention of Security Vulnerabilities due to Race Conditions

IP.com Disclosure Number: IPCOM000238065D
Publication Date: 2014-Jul-30
Document File: 4 page(s) / 51K

Publishing Venue

The IP.com Prior Art Database

Abstract

Race conditions are the cause of subtle functional bugs in multithreaded software systems. Beyond functional problems, race conditions can also potentially lead to security vulnerabilities. In a case of multiple possible interleavings, the decision which of the interleavings to execute is made nondeterministically by the runtime thread scheduler. Hence, it is legitimate to intervene in the case where the ?bad? interleaving arises. The resulting concurrent execution is an admissible one.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 39% of the total text.

Page 01 of 4

Method and Apparatus for Hybrid Prevention of Security Vulnerabilities due

      Method and Apparatus for Hybrid Prevention of Security Vulnerabilities due to Race Conditions

Background. Race conditions are the cause of subtle functional bugs in multithreaded software systems. A classic example is Canada's Therac-25 radiation therapy machine, which malfunctioned and delivered lethal radiation doses to patients because of a race condition that allowed the electron beam to fire in high-power mode without proper patient shielding [1].

    Beyond functional problems, race conditions can also potentially lead to security vulnerabilities. For example, [2] shows how races allow an attacker to read and alter protected files in the Unix file system. Another example is [3], which explores the security implications of race conditions arising due to interaction between a web-based application and an underlying relational database.

    A key problem with race conditions is that the conditions governing the race are subtle and complex. To illustrate this, we consider the example of two Java* web servlets, executed by concurrent threads T1 and T2, which both access the same portions of the web application's shared state.

We refer to two runs of the servlets*, given in Figures 1 and 2 below:

Figure 1. Safe execution with no risk of security attack

T1
T2

System, ,

String s = request.getParameter("name");

String s = request.getParameter("name");

String clean = sanitize(s);

session.setAttribute("name", clean);

session.setAttribute("name",
s);

String name = session.getAttribute("name");

response.getWriter().println(… + name + …);


Page 02 of 4

 Figure 2. Unsafe execution, which may lead to a security attack Both servlets* access a request parameter, with identifier "name", to obtain its value. Importantly, this value is considered untrusted, because it is provided by an external user of the web application. Both servlets* also insert the read value into the session object under an attribute bearing the same name. Only the second servlet* (i.e., that corresponding to thread T2), however, applies sanitization to the read value before proceeding to insert it into the web session. Later, the second servlet* reads the value mapped under attribute "name" via a getAttribute(…) call.

    The critical difference between the two figures, which is fairly subtle, is the order of execution of the two setter calls over the session object. In the first case (Figure 1), the servlet* executed by thread T2 is the last to assign a value to attribute "name" under the session object, and so when this attribute is later fetched by it and used in the security-sensitive println(…) operation (which renders content to the response HTML page), that value is benign. This is not true, however, of the second case (Figure 2), wherein thread T1 is the last to assign a value to the "name" attribute, and so the value stored in the session object is unsafe.

     Background Art. Past works have not...