There has been a lot of concern about the Heartbleed vulnerability in OpenSSL lately. In earlier posts, we’ve talked about how Coverity does not find Heartbleed in its stock configuration.
We’ve been feverishly working to protect our users from this type of problem, and have identified a few possibilities. Using existing releases, we can find Heartbleed specifically through some common modeling. By modeling the n2s() macro as tainting the output variable, our existing TAINTED_SCALAR checker will flag the defect. The problem is that this requires the user to specifically tell the analysis to treat n2s (and any other important user-defined functions or macros) as tainting data. It’s easy to do that now that we know there is a problem, but only the most paranoid organizations would likely have created these models proactively. We can do better.
We identified another approach that holds much more promise, which is described in this earlier blog post. This approach also leverages our proven TAINTED_SCALAR checker, but instead of relying on manual modeling of custom macros and functions, it treats values that go through byte swap operations as tainted. Such operations are usually the result of marshaling data from the network or filesystem, which are reasonable to consider as tainted. The nice thing about this approach is that it automatically handles user-defined code without significant configuration:
Given the obvious interest and the promising early results of our experiments, we’ll be releasing a hotfix shortly that provides this capability to our users. If you’d like to hear more about the modeling approach, please add a comment.
To learn more about how Coverity can help you protect your code from defects like Heartbleed and how we’ve helped open source projects remove almost 100,000 defects, please join our webcast on May 1 at 8:30am Pacific Daylight Time.