Late 2024, Radically Open Security conducted another security audit of critical parts of Tails.

To better protect our users, we addressed the security vulnerabilities as soon as they were discovered and reported to us, without waiting for the audit to be complete and public.

We can now share with you the final report.

The auditors concluded that:

The Tails operating system leaves a strong security impression, addressing most anonymity-related concerns. We did not find any remote code execution vulnerabilities, and all identified issues required a compromised low-privileged amnesia user – the default user in Tails.

Looking back at the previous audit, we can see the Tails developers have made significant progress, demonstrating expertise and a serious commitment to security.

Findings

The auditors did not identify any vulnerability in:

• The creation of the Persistent Storage with LUKS2, introduced in Tails 5.14 (June 2023)

• Our security improvements to Thunderbird

• The random seed feature, introduced in Tails 6.4 (June 2024)

The auditors found 4 issues in:

• The automatic upgrade mechanism

• Other important changes since Tails 5.8 (November 2023)

Postmortem

Our team went further than simply fixing these issues. We conducted a postmortem to understand how we introduced these vulnerabilities in our releases and what we could do to avoid similar vulnerabilities in the future. This analysis led to technical, policy, and culture changes.

This analysis was useful and we'll definitely consider doing postmortems again after future audits. It might also be useful for other projects to understand how we worked on these long-lasting improvements.

Technical improvements

• Postmortem of OTF-001

  While preparing a major Tails release based on a new version of Debian, for example, Tails 7.0, we will look for Perl code included in Tails that modifies @INC in a dangerous way. (#19627)

  Furthermore, we now automatically check for potentially vulnerable Mite code and fail the build if we find any.

• Postmortem of OTF-002 (#20719 and !1911)

  Our CI now ensures that all our custom Python software runs in isolated mode.

• Postmortem of OTF-003 (#20711 and !1979)

  Our sudo configuration is now generated from a higher-level description, which has safer defaults and demands explanations when diverging from them.

• Postmortem of OTF-004 (#20817 and !2040)

  Our CI now ensures that we don't write software that does unsafe .desktop file lookup.

  We will also periodically audit the configuration of onion-grater, our firewall for the Tor control port. (#20821)

Policy and culture improvements

• During the audit, we noticed that we lacked a policy about when we should make confidential security issues public.

  This was problematic because:

  • We have sometimes been too secretive.

    As a temporary measure, this protected our users by erring on the safe side. But, without a disclosure process, we were not meeting our own standards for transparency and openness to third-party reviews.

  • Different team members were working with different assumptions, which caused communication issues.

  To have better guidelines for confidentiality and disclosure, we created our security issue response policy, based on the policy of the Tor Project's Network Team.

• We will be more intentional about when it's worth the effort and risk to do large code refactoring.

  While refactoring is necessary for a healthy software development process, this postmortem showed that large refactoring can also introduce security vulnerabilities.

• When changing security-sensitive code, such as our sudo configuration or any code that elevates privileges, we now require an extra review focused on security.

• We will communicate about security issues more broadly within our team when we discover them so that every team member can learn along the way.