Interesting report here from Microsoft Research entitled “Concurrency at Microsoft – An Exploratory Survey”. Somewhat surprising: the respondents to the internal survey were fairly senior, with a mean of roughly seven years at the company. Not so surprising conclusion despite that: even experienced developers are challenged by concurrency bugs, and developer tools haven’t really been keeping up.

That report is from two years ago, though, and two years does make a difference. One notable new concurrency debugging tool: Corensic. In summary, Corensic’s main product, Jinx, installs as a hypervisor which attempts to force concurrency bugs to occur. That addresses one of the big challenges with that type of bugs: if they happen infrequently, and only in production, identifying and fixing them can be a real pain. By forcing them to happen, and allowing that to occur in a development environment, significant cost savings can be achieved.

What’s the security angle here? Well, there are a couple. First, any bug, concurrency or otherwise, becomes a “security bug” under certain conditions. For example, a concurrency bug which results in memory corruption may be remotely exploitable. Similarly, if a security feature (e.g., an authentication service) is implemented as multi-threaded, and it has a concurrency bug which renders it unavailable, that’s a problem.

But, more broadly, security can be thought of as risk management. To software companies, bugs are a risk because they drive up development cost. They also pose a reputation risk. So get the right tools and get ‘em fixed!

No Comments »