8 ms·

A New Development for Coverity and Heartbleed

125 points by neuroo 12y ago

vladd 12y ago
In case you want to try out static analysis on your own code-base, here's a link with the list of most popular tools in this field, grouped by language: http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis http://en.wikipedia.org/wiki/List_of_tools_for_static_code_a...
- LVB 12y ago
  Visual Studio now ships with a reasonably good static analyzer built in. We're using it more than our aging copy of PC-Lint. (Carmack's review: http://www.altdevblogaday.com/2011/12/24/static-code-analysis/ http://www.altdevblogaday.com/2011/12/24/static-code-analysi...)
  - TwoBit 12y ago
    VC++ analysis is useful aside from the fact that it mistakenly thinks every pointer usage is a potential null pointer, but I've gotten better results with clang static analysis.
    - marshray 12y ago
      Every pointer is potentially null, until proven otherwise (which in the general case means solving the halting problem).
  - ygra 12y ago
    Can you tell VS by now to ignore warnings in 3rd-party libs? Everything that's in Qt's headers is pretty much out of my control but those were by far the most common warnings (or at least I didn't see many real warnings amidst them). At least that's how it's in VS 2010 and it kept me from turning code analysis on more often.
- Joeri 12y ago
  I configured jshint inspection in a pre-commit hook on my team's code repository. Yesterday I checked the logs and in the last 10 days it prevented 15 commits, a few of which were actual bugs. For me static analysis is a no-brainer. The only challenge is finding the right set of settings that you don't get too many false positives.
- Eridrus 12y ago
  Coverity also has a free trial you can do online with your own code: http://softwareintegrity.coverity.com/free-trial-coverity.html http://softwareintegrity.coverity.com/free-trial-coverity.ht...
kyberias 12y ago
Interesting: "As you might guess, additional locations in OpenSSL are also flagged by this analysis, but it isn’t my place to share those here."
- nodata 12y ago
  Anyone know if these have been bug reported?
  - neuroo 12y ago
    Not yet, we are looking at them right now.
apaprocki 12y ago
Is this implemented in Coverity by a local model? (There is reference to a model being applied) Or was the actual product modified to support this? Can Coverity customers get ahold of this now?
- neuroo 12y ago
  The "model" makes reference of the model injection for memcpy. The modification made by the team is referenced in John's blog post "Their insight is that we might want to consider byte-swap operations to be sources of tainted data". As Andy said (and quoted), that's a modification that we need to evaluate overall to look at its impact in term of false positives (FP). It will probably be made available however under some options if it doesn't pass our acceptance tests for FP rate though... a bit too early to say.
  - apaprocki 12y ago
    Thanks, I was just curious if customers could play with these kind of experiments if they understood the FP potential. I really like Coverity's output and always like new ways to tease out potential bugs.
lbarrow 12y ago
It's super cool to see the power of advanced static analysis these days. Props to the Coverity team for using the Heartbleed trainwreck to motivate new research on these problems. That said, are there other ways to fix this class of problem? We have choices. We can continue to build ever-more-advanced tools for patching over the problems of C and C++, or we can start using languages that simply do not have those problems. There will always be a need for C and C++ in device drivers, microcontrollers, etc. But there's no compelling reason why SSL implementations in 2014 should use languages designed to run on mainframes in 1973.
- hf 12y ago
  Trevor Perrin (of TACK fame) wrote TLS Lite in Python. I submitted a link to TLS Lite a few days ago, but, alas, showed poor judgement in timing: https://news.ycombinator.com/item?id=7564740 https://news.ycombinator.com/item?id=7564740 Direct link: http://trevp.net/tlslite/ http://trevp.net/tlslite/ I'm actually rather anxious to hear the knowledgeable crowd discuss this fine project.
  - tptacek 12y ago
    It's fantastic if you want to build TLS testing tools, or if you want a codebase to reason about TLS with.
    - hf 12y ago
      A stamp of approval if ever there was one. Thank you. What, however, hinders adoption as a "working man's" TLS library? Neglecting performance and variety of cipher support, would or should anything prevent me from using Tiny TLS to secure channels between "inner circle machines" (that talk to a set of well-known participants)?
      - tptacek 12y ago
        My advice is not to use obscure TLS libraries in production. Look at the recent Frankencerts paper to see what goes wrong: only OpenSSL, NSS, and Bouncycastle (the mainstream libraries) properly rejected pathological X.509 certificates. If you're trying to deploy pure-Python applications, I like tlslite. Of course, I have to say that, because Trevor is much smarter than me. Personally, I think your realistic production choices are OpenSSL or NSS.
jdp23 12y ago
Interesting approach! Kudos to Coverity for jumping on it so quickly. Taint analysis is notoriously prone to false positives; as well as the reasons listed in this post, there are many situations where relations between variables mean that tainted data doesn’t cause problems. [For example, the size of the memcpy target (bp) is known to be greater than payload; so even though payload is tainted, there isn't a risk of a write overrun.] But even noisy warnings can be very useful — when we first implemented simple taint analysis in PREfix a decade ago, the first run was 99% false positives but one of the real bugs we found was in a system-level crypto module. So with the increased attention to these kinds of bugs after Heartbleed, seems like a great time for more attention to these classes of bugs.
- skybrian 12y ago
  I think it works even better if you can get help from the type system. For example, the SafeHtml interface in GWT [1] gives you some safety from Java's type checking and can also make additional static analysis easier. (Then it becomes an exercise in making sure the API is used as intended.) Perhaps something similar could be done using typedefs in C? [1] http://www.gwtproject.org/javadoc/latest/com/google/gwt/safehtml/shared/SafeHtml.html http://www.gwtproject.org/javadoc/latest/com/google/gwt/safe...
  - dbaupp 12y ago
    Typedefs in C are just aliases, so given `typedef int foo;` one can freely use `int`s and `foo`s interchangeably, i.e. no checking by the compiler. That said, one could use actual wrapper structs around the various types.
    - skybrian 12y ago
      A static analysis framework could treat certain typedefs specially since it's parsing the C code anyway.
      - marshray 12y ago
        Great idea! Too bad openssl uses #define instead
pjungwir 12y ago
> additional locations in OpenSSL are also flagged by this analysis, but it isn’t my place to share those here. Why do I get the feeling that we're going to see three months of new OpenSSL vulnerabilities, like we saw with Rails last year? I'm sure Heartbleed plus all the bad press about code quality means a lot of people are suddenly looking. Assuming there is more to find, does anyone have any advice for how we might prepare for it?

125 points by neuroo 12y ago

vladd 12y ago

In case you want to try out static analysis on your own code-base, here's a link with the list of most popular tools in this field, grouped by language: http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis http://en.wikipedia.org/wiki/List_of_tools_for_static_code_a...

LVB 12y ago
Visual Studio now ships with a reasonably good static analyzer built in. We're using it more than our aging copy of PC-Lint. (Carmack's review: http://www.altdevblogaday.com/2011/12/24/static-code-analysis/ http://www.altdevblogaday.com/2011/12/24/static-code-analysi...)
- TwoBit 12y ago
  VC++ analysis is useful aside from the fact that it mistakenly thinks every pointer usage is a potential null pointer, but I've gotten better results with clang static analysis.
  - marshray 12y ago
    Every pointer is potentially null, until proven otherwise (which in the general case means solving the halting problem).
- ygra 12y ago
  Can you tell VS by now to ignore warnings in 3rd-party libs? Everything that's in Qt's headers is pretty much out of my control but those were by far the most common warnings (or at least I didn't see many real warnings amidst them). At least that's how it's in VS 2010 and it kept me from turning code analysis on more often.
Joeri 12y ago
I configured jshint inspection in a pre-commit hook on my team's code repository. Yesterday I checked the logs and in the last 10 days it prevented 15 commits, a few of which were actual bugs. For me static analysis is a no-brainer. The only challenge is finding the right set of settings that you don't get too many false positives.
Eridrus 12y ago
Coverity also has a free trial you can do online with your own code: http://softwareintegrity.coverity.com/free-trial-coverity.html http://softwareintegrity.coverity.com/free-trial-coverity.ht...

kyberias 12y ago

Interesting: "As you might guess, additional locations in OpenSSL are also flagged by this analysis, but it isn’t my place to share those here."

nodata 12y ago
Anyone know if these have been bug reported?
- neuroo 12y ago
  Not yet, we are looking at them right now.

apaprocki 12y ago

Is this implemented in Coverity by a local model? (There is reference to a model being applied) Or was the actual product modified to support this? Can Coverity customers get ahold of this now?

neuroo 12y ago
The "model" makes reference of the model injection for memcpy. The modification made by the team is referenced in John's blog post "Their insight is that we might want to consider byte-swap operations to be sources of tainted data". As Andy said (and quoted), that's a modification that we need to evaluate overall to look at its impact in term of false positives (FP). It will probably be made available however under some options if it doesn't pass our acceptance tests for FP rate though... a bit too early to say.
- apaprocki 12y ago
  Thanks, I was just curious if customers could play with these kind of experiments if they understood the FP potential. I really like Coverity's output and always like new ways to tease out potential bugs.

lbarrow 12y ago

It's super cool to see the power of advanced static analysis these days. Props to the Coverity team for using the Heartbleed trainwreck to motivate new research on these problems. That said, are there other ways to fix this class of problem? We have choices. We can continue to build ever-more-advanced tools for patching over the problems of C and C++, or we can start using languages that simply do not have those problems. There will always be a need for C and C++ in device drivers, microcontrollers, etc. But there's no compelling reason why SSL implementations in 2014 should use languages designed to run on mainframes in 1973.

hf 12y ago
Trevor Perrin (of TACK fame) wrote TLS Lite in Python. I submitted a link to TLS Lite a few days ago, but, alas, showed poor judgement in timing: https://news.ycombinator.com/item?id=7564740 https://news.ycombinator.com/item?id=7564740 Direct link: http://trevp.net/tlslite/ http://trevp.net/tlslite/ I'm actually rather anxious to hear the knowledgeable crowd discuss this fine project.
- tptacek 12y ago
  It's fantastic if you want to build TLS testing tools, or if you want a codebase to reason about TLS with.
  - hf 12y ago
    A stamp of approval if ever there was one. Thank you. What, however, hinders adoption as a "working man's" TLS library? Neglecting performance and variety of cipher support, would or should anything prevent me from using Tiny TLS to secure channels between "inner circle machines" (that talk to a set of well-known participants)?
    - tptacek 12y ago
      My advice is not to use obscure TLS libraries in production. Look at the recent Frankencerts paper to see what goes wrong: only OpenSSL, NSS, and Bouncycastle (the mainstream libraries) properly rejected pathological X.509 certificates. If you're trying to deploy pure-Python applications, I like tlslite. Of course, I have to say that, because Trevor is much smarter than me. Personally, I think your realistic production choices are OpenSSL or NSS.

jdp23 12y ago

Interesting approach! Kudos to Coverity for jumping on it so quickly. Taint analysis is notoriously prone to false positives; as well as the reasons listed in this post, there are many situations where relations between variables mean that tainted data doesn’t cause problems. [For example, the size of the memcpy target (bp) is known to be greater than payload; so even though payload is tainted, there isn't a risk of a write overrun.] But even noisy warnings can be very useful — when we first implemented simple taint analysis in PREfix a decade ago, the first run was 99% false positives but one of the real bugs we found was in a system-level crypto module. So with the increased attention to these kinds of bugs after Heartbleed, seems like a great time for more attention to these classes of bugs.

skybrian 12y ago
I think it works even better if you can get help from the type system. For example, the SafeHtml interface in GWT [1] gives you some safety from Java's type checking and can also make additional static analysis easier. (Then it becomes an exercise in making sure the API is used as intended.) Perhaps something similar could be done using typedefs in C? [1] http://www.gwtproject.org/javadoc/latest/com/google/gwt/safehtml/shared/SafeHtml.html http://www.gwtproject.org/javadoc/latest/com/google/gwt/safe...
- dbaupp 12y ago
  Typedefs in C are just aliases, so given `typedef int foo;` one can freely use `int`s and `foo`s interchangeably, i.e. no checking by the compiler. That said, one could use actual wrapper structs around the various types.
  - skybrian 12y ago
    A static analysis framework could treat certain typedefs specially since it's parsing the C code anyway.
    - marshray 12y ago
      Great idea! Too bad openssl uses #define instead

pjungwir 12y ago

> additional locations in OpenSSL are also flagged by this analysis, but it isn’t my place to share those here. Why do I get the feeling that we're going to see three months of new OpenSSL vulnerabilities, like we saw with Rails last year? I'm sure Heartbleed plus all the bad press about code quality means a lot of people are suddenly looking. Assuming there is more to find, does anyone have any advice for how we might prepare for it?