SBN

Race Condition Vulnerabilities

Introduction to race conditions

Race condition vulnerabilities are an artifact of parallel processing. The ability to run multiple different execution threads in parallel can create vulnerabilities that would not exist in single-threaded programs. The impact of these vulnerabilities range from exploitable errors to leakage of sensitive information via side effects, like in the Meltdown vulnerability.

Multithreading and parallel processing

A lot of modern computing is dependent upon software running quickly. Humans are impatient, to the point where even a second-long delay in a web page loading causes a significant drop in the number of people that actually visit a page. Since there are limits on how quickly a single execution thread can run on a computer, especially if memory accesses and I/O are required, modern computers contain multiple processes and support multi-threading. 

As a result, the assumptions that a developer’s code will be the only program running on a machine at one time and that two adjacent instructions within a program will be executed one after another are invalid. While many developers are still stuck in a single-threaded mindset in development, the use of parallel programming is growing. However, this can create vulnerabilities.

Race condition vulnerabilities

Race condition vulnerabilities are created when assumptions about execution order and lack of concurrency are invalid. In general, it is best to never assume that a single thread of execution will be the only one accessing certain resources. If this assumption is proven invalid (and there are several ways that it can be), then things can break.

One example of this is the Denial of Service attack described in the classic Dining Philosophers Problem. The philosophers are sitting around a table, as shown above, and there are a number of chopsticks equal to the number of philosophers at the table. A philosopher needs (Read more...)

*** This is a Security Bloggers Network syndicated blog from Infosec Resources authored by Howard Poston. Read the original post at: http://feedproxy.google.com/~r/infosecResources/~3/7ClHFwqn1ks/