First Phase Of Security Audit Finds Vulnerabilities But No Backdoors In TrueCrypt Encryption Software

from the more-work-needed,-and-more-donations dept

In the wake of the serious Heartbleed flaw in OpenSSL, more people are becoming aware of how widely used and important open source encryption tools are, and how their security is too often taken for granted. Some people were already worrying about this back in September last year, when we learned that the NSA had intentionally undermined encryption by weakening standards and introducing backdoors. As Techdirt reported, that led to a call for a security audit of TrueCrypt, a very popular open source disk encryption tool. Fortunately, the Open Crypto Audit Project raised a goodly sum of money through FundFill and IndieGogo, which allowed the first phase of the audit to be funded. Here's what's now been done (pdf):

The Open Crypto Audit Project engaged iSEC Partners to review select parts of the TrueCrypt 7.1a disk encryption software. This included reviewing the bootloader and Windows kernel driver for any system backdoors as well as any other security related issues.
The good news:
iSEC found no evidence of backdoors or otherwise intentionally malicious code in the assessed areas.
However, it did still find vulnerabilities in the code it examined:
the iSEC team identified eleven (11) issues in the assessed areas. Most issues were of severity Medium (four (4) found) or Low (four (4) found), with an additional three (3) issues having severity Informational (pertaining to Defense in Depth).

Overall, the source code for both the bootloader and the Windows kernel driver did not meet expected standards for secure code. This includes issues such as lack of comments, use of insecure or deprecated functions, inconsistent variable types, and so forth.
Because of that, among the recommendations that iSEC made was the following:
Improve code quality. Due to lax quality standards, TrueCrypt source is difficult to review and maintain. This will make future bugs harder to find and correct. It also makes the learning curve steeper for those who wish to join the TrueCrypt project.
That's an important point, and probably something that other open source projects might take to heart, too. Some have called into question whether Linus's Law -- that "all bugs are shallow, given enough eyeballs" -- is really true for free software (although Eric Raymond, author of "The Cathedral and the Bazaar", has offered a robust defense of that claim.) One reason why those eyeballs may not be finding the bugs is that the code, though open, is unnecessarily hard to read.

The fact that vulnerabilities were found -- even if "all appear to be unintentional, introduced as the result of bugs rather than malice" as iSEC puts it -- is another reason why the second phase of the audit, which will look at the details of how the cryptographic functions have been implemented, is necessary. The discovery of "issues" in TrueCrypt's code also underlines why similar audits need to be conducted for all important open source security programs: if there are vulnerabilities in TrueCrypt, there are likely to be more elsewhere, perhaps much more serious. Finding them is largely a question of money, which is why companies currently free-riding on free software -- perfectly legally -- should start seriously thinking about making some voluntary contributions to help audit and improve them to prevent another Heartbleed.

Follow me @glynmoody on Twitter or, and +glynmoody on Google+

Hide this

Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.

Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.

While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.

–The Techdirt Team

Filed Under: encryption, open source, security audit, truecrypt

Reader Comments

Subscribe: RSS

View by: Time | Thread

  1. identicon
    Rich Kulawiec, 16 Apr 2014 @ 2:02am

    Brief comment on one of the associated problems

    Auditing code is tedious; it's not nearly as much fun as writing new code. Nor is it as gratifying or nearly as likely to raise one's profile in the community. It's much more tempting, rather than auditing TrueCrypt, to just write another one. Or fork the existing one.

    Of course the likely outcome of that would be two similar programs, both with some number of security issues. We don't need two (or fourteen) TrueCrypts, we need one that works and has had as much auditing done as possible.

    I'm not knocking the idea of forking code: it often yields interesting experiments and sometimes produces end results that surpass the originals. What I'm saying is that gratuitous forking isn't good for the software ecosystem. And further, I'm saying that the difficulty (and expense) of auditing code should cause at least some of the projects out there to consider merging their forks in order to shrink the corpus of code that needs checking. (Apache OpenOffice and LibreOffice, I'm looking at you.)

    Eric Raymond was right -- in a way he was merely restating one of the fundamental principles of science: peer review. The problem isn't the statement: the problem is that "many" is "VERY many" when millions of lines of code are involved, and we don't have "VERY many" eyeballs available. We could try to increase the pool, and no doubt we will, but another way to make the problem more tractable is to reduce the number of lines of code, when and where that makes sense.

    reply to this | link to this | view in thread ]

  2. icon
    Ninja (profile), 16 Apr 2014 @ 3:48am

    Ironically 2 severe events that threw almost deadly blows to the internet (so far we can't really tell if they were deadly) are actually fueling a good deal of greatly needed scrutiny which will lead to improvements overall.

    Ironic because maybe we should thank NSA and heartbleed timing...

    reply to this | link to this | view in thread ]

  3. identicon
    Anonymous Coward, 16 Apr 2014 @ 4:49am

    Of course being able to read the code is an issue. The bigger issue is that people have to look at it first. Reality is that the average size of a project(contributors) on github etc... is ONE.

    The premise and ideological theory about "free software" does have a real world advantage when realised. Realising the project potential is the issue.

    The fact that people are now starting to get involved with projects like truecrypt will make realising the potential of that "free software".

    Needs more Eyeballs. The code will get sorted by those eyeballs.

    reply to this | link to this | view in thread ]

  4. icon
    BentFranklin (profile), 16 Apr 2014 @ 6:54am

    Any bug that is intentional will be made to look accidental.

    reply to this | link to this | view in thread ]

  5. identicon
    Anonymous Coward, 16 Apr 2014 @ 6:57am

    This is a job the NSA should be doing. They have a huge budget and the eyeballs to audit open source security tools and recommend patches.

    The NSA might be doing this already, but keeping the findings to themselves. Its really a shame that we have to fund the audits twice, once for the "good guys" by donating and again for the NSA through tax dollars.

    reply to this | link to this | view in thread ]

  6. identicon
    Anonymous Coward, 16 Apr 2014 @ 7:22am


    The problem is any 'recommended patches' by the NSA, despite intentions, will be looked down upon as meddling so they can spy on more everything. At worst they'll be rejected outright or ignored entirely even if the patches are beneficial.

    reply to this | link to this | view in thread ]

  7. identicon
    Anonymous Coward, 16 Apr 2014 @ 7:24am

    Re: Re:

    that's the problem now, but if they were actually doing the job of protecting our country's networks then it would be a more efficient use of funds.

    reply to this | link to this | view in thread ]

  8. icon
    John Fenderson (profile), 16 Apr 2014 @ 7:46am

    Re: Re: Re:

    Woulda, shoulda, coulda. That horse is long gone from the barn. The NSA doesn't have the credibility to act in that role now, and likely never will.

    reply to this | link to this | view in thread ]

  9. identicon
    Pragmatic, 16 Apr 2014 @ 8:23am


    Franklin's Law?

    reply to this | link to this | view in thread ]

  10. identicon
    Anonymous Coward, 16 Apr 2014 @ 11:22am


    I don't think any person in their right mind would trust anything that comes from the NSA.

    reply to this | link to this | view in thread ]

  11. icon
    Mike Gale (profile), 16 Apr 2014 @ 5:13pm

    More than reading the code

    It's good to see that the review included compiling and testing and fuzzing.

    My contention is that it is, ultimately, more productive to publish tests for the project, than just source. (I haven't checked TrueCrypt distribution to see whether they do that.)

    1. More people can more easily test and add their own tests, and run them.
    2. Alternate implementations can arise, more easily. I think a function that can be switched between several independent versions can be more reliable.
    3. An NSA with the protection function separated should then participate too. IMHO

    reply to this | link to this | view in thread ]

Add Your Comment

Have a Techdirt Account? Sign in now. Want one? Register here

Subscribe to the Techdirt Daily newsletter

Comment Options:

  • Use markdown. Use plain text.
  • Make this the First Word or Last Word. No thanks. (get credits or sign in to see balance)    
  • Remember name/email/url (set a cookie)


Add A Reply

Have a Techdirt Account? Sign in now. Want one? Register here

Subscribe to the Techdirt Daily newsletter

Comment Options:

  • Use markdown. Use plain text.
  • Make this the First Word or Last Word. No thanks. (get credits or sign in to see balance)    
  • Remember name/email/url (set a cookie)

Follow Techdirt
Insider Shop - Show Your Support!

Essential Reading
Techdirt Deals
Report this ad  |  Hide Techdirt ads
Techdirt Insider Chat
Recent Stories

This site, like most other sites on the web, uses cookies. For more information, see our privacy policy. Got it

Email This

This feature is only available to registered users. Register or sign in to use it.