Audit de sécurité concernant les mises à jours automatiques et les changements récents

Fin 2024, Radically Open Security a effectué un nouvel audit de sécurité autour des parties critiques de Tails.

Pour mieux protéger les personnes utilisant Tails, nous avons traité les failles de sécurité dès qu'elles ont été découvertes et qu'elles nous sont parvenus, sans attendre que l'audit soit terminé et rendu public.

Nous pouvons maintenant vous partager le rapport final.

Les personnes ayant fait l'audit ont conclu que :

Le système d'exploitation Tails laisse l'impression d'une sécurité forte, réglant la majorité des préoccupations liées à l'anonymat. Nous n'avons pas trouvé de vulnérabilités d'execution à distance de code, et tous les problèmes identifiés exigaient un utilisateur à faible privilège amnesia compromis – l'utilisateur par défaut de Tails.

En regardant l'audit précédent, nous pouvons remarquer que les développeur.euses de Tails ont fait des progrès significatifs, démontrant une expertise et un investissement sérieux sur la sécurité.

Constatations

Les personnes ayant fait l'audit n'ont pas identifié de vulnérabilités dans :

  • La création du stockage persistant utilisant LUKS2, apparut dans Tails 5.14 (juin 2023)

  • Nos améliorations de sécurité dans Thunderbird

  • La fonctionnalité de graine aléatoire, apparut dans Tails 6.4 (juin 2024)

Les personnes ayant fait l'audit ont trouvé 4 problèmes dans :

  • Le mécanisme de mise à jour automatique

  • D'autres changements importants depuis Tails 5.8 (novembre 2023)

IDImpactDescriptionLienStatutVersion
OTF-001ÉlevéEscalation local de privilège dans Tails Upgrader#20701Résolu6.11
OTF-002ÉlevéExecution de code arbitraire dans les scripts Python#20702Résolu6.11
#20744Résolu6.12
OTF-003MoyenInjection d'argument dans un script privilégié GNOME#20709Résolu6.11
#20710Résolu6.11
OTF-004FaibleChemin de recherche non fiable dans le gestionnaire de Tor Browser#20733Résolu6.12

Postmortem

Notre équipe n'a pas seulement résolu ces problèmes. Nous avons créé un postmortem pour comprendre comment nous avons introduit ces vulnérabilités dans nos versions, et comment empêcher des vulnérabilités similaires dans le futur. Cette analyse a ammené des changements techniques, culturels et politiques.

Cette analyse a été utile et nous allons définitivement considérer faire plus de postmortem dans le futur. Il serait aussi intéressant pour d'autres projets de comprendre comment nous avons travaillé sur ces améliorations durables.

Améliorations techniques

  • Postmortem de OTF-001

    Durant la préparation d'une importante mise à jour de Tails se basant sur une nouvelle version de Debian, par exemple, Tails 7.0, nous regarderons le code Perl inclus dans Tails qui modifie @INC de façon dangereuse. (#19627)

    De plus, nous vérifions automatiquement la présence de potentielles vulnérabilités de code Mite et nous faisons échouer la construction si nous en trouvons un.

  • Postmortem de OTF-002 (#20719 et !1911)

    Notre intégration continue assure maintenant que notre logiciel Python personnalisé s'execute dans un mode isolé.

  • Postmortem de OTF-003 (#20711 et !1979)

    Notre configuration sudo est maintenant générée depuis une description haut niveau, qui a des valeurs par défauts plus sures et demande des explications quand elle diverge de ces derniers.

  • Postmortem de OTF-004 (#20817 et !2040)

    Notre intégration continue s'assure qu'on nous n'écrivions pas de logiciel effectuant une recherche de fichiers .desktopnon sécurisée.

    Nous auditerons aussi périodiquement la configuration de onion-grater, notre pare-feu pour le contrôle de port Tor. (#20821)

Améliorations politiques et culturels

  • Durant l'audit, nous avons remarqué un manque de politique autour de la diffusion au public des problèmes de sécurité.

    Ceci est problématique car :

    • Nous avons parfois été trop discrets.

      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.

    • Différents membres de l'équipe travaillaient avec des présomptions différentes, ce qui a causé des problèmes de communication.

    Afin d'avoir de meilleures lignes directrices concernant la confidentialité et la divulgation, nous avons créé une politique de réponse aux problèmes de sécurité, basée sur la politique de l'équipe réseau du projet Tor.

  • Nous serons plus explicite sur le ratio risque/effort lié à un remaniement profond du code.

    Si un remaniement du code est nécessaire pour un bon développement logiciel, ce postmortem a démontré qu'un remaniement important peut aussi entrainer des failles de sécurité.

  • Lors d'un changement autour de code lié à un point de sécurité, comme notre configuration sudo ou tout autre code lié à l'élévation de privilèges, nous demandons maintenant un avis supplémentaire centré sur la sécurité.

  • Nous communiquerons sur les problèmes de sécurité plus largement dans notre équipe lors de leur découverte, afin que chaque membre puisse apprendre tout du long.