We are happy to report that this latest iSEC audit did not turn up any serious security vulnerabilities. Of the ten vulnerabilities reported, there were no high severity issues. One was medium severity, two were low, and the rest were informational. In addition, all of the issues were considered to have a high level of difficulty for successful exploitation, due to SecureDrop’s security-first design and defense in depth measures. We have implemented all of iSEC’s short term solutions from the report in SecureDrop 0.3.4, and have filed follow-up issues to address their long term recommendations in a future release. For more information, see the 0.3.4 changelog.

Overall, the iSEC team strongly approved of SecureDrop’s architecture and hardening measures. We are proud of their conclusion:

SecureDrop’s extensive hardening places it well above industry standards due to its emphasis on security and privacy. Overall, the newly introduced components do not add to the already limited attack surface, as the SecureDrop architecture remains the same. The addition of a Grsecurity-enabled kernel significantly raises the bar for attackers who manage to successfully exploit the application server via various memory corruption style attacks. Additionally, all interfaces except the one used by sources are only available over authenticated Tor hidden services. These factors, combined with SecureDrop’s existing defense in depth measures, make traditional forms of server compromise significantly difficult.

Our standard release policy for SecureDrop is to have every major release (0.2, 0.3, ...) audited by an independent security firm before release. Minor releases (0.3.1, 0.3.2, ...) are meant only to deliver fixes for bugs or security vulnerabilities.

We decided to get another audit done early because we experienced our first publicly reported security vulnerability on April 1st, 2015. The vulnerability was reported in an email to the Bugtraq mailing list without any prior notice to the Freedom of the Press Foundation. We confirmed that the issue was legitimate, developed a fix, and released it in an automatic upgrade that went out to all of the production SecureDrop installations within 24 hours of the issue being reported. Fortunately, the bug did not affect any of the existing production installations due to the defense-in-depth techniques that are an important part of the design of SecureDrop. For more information, see the GitHub issue.

Out of an abundance of caution, we took several additional steps. First, we did an internal audit of the codebase to make sure there were no other security issues which were obvious in retrospect. Second, we commissioned another external security audit, with a focus on the changes that were made between the last audited release and the current release in order to catch any similar issues. Since iSEC performed the last SecureDrop audit, was already familiar with the codebase, and was familiar with the mitigations we had implemented in response to their last audit, we engaged them again for the follow-up audit.

We agree with iSec’s conclusion that focus should now turn to improving the usability and security of the Tails workstations used by journalists to view and analyze submissions, and on the usability and security of the airgapped workflow as a whole. That will be our primary goal for the remainder of 2015.

Finally, we want to emphasize that we are always striving to enhance the security of SecureDrop and protect those who are currently using it. If you are a security researcher and think you have found a vulnerability in SecureDrop, please consider responsibly disclosing the issue to us first so we can take steps to mitigate the issue and update any affected production installations. You can report security issues to us through our bug bounty program (operated by Bugcrowd), or you can send an encrypted email to [email protected] (with our GPG key, fingerprint: 734F 6E70 7434 ECA6 C007 E1AE 82BD 6C96 16DA BB79).