CSPN TrueCrypt : rapport d'évaluation et mise à jour du logiciel

Fri 05 December 2008 by fred

Pour faire bref, la CSPN est un test de sécurité formalisé par la DCSSI. Il s'agit, en temps contraint (20 jours s'il n'y a pas de crypto, 30 s'il y en a), de donner un avis sur la sécurité d'un produit. Dans ce contexte, nous avons évalué le logiciel TrueCrypt (version 6.0a). Ce billet porte sur la mise à jour 6.1a, qui corrige certains problèmes relevés lors de l'évaluation.

Dans ce billet, vous trouvez le rapport d'évaluation et quelques remarques sur le passage à la version 6.1a.

Une petite citation pour commencer :

6.1a

December 1, 2008

Improvements, bug fixes, and security enhancements:

- Minor improvements, bug fixes, and security enhancements. (Windows, Mac OS X, and Linux)

Note: If you are using an older version of TrueCrypt, it is
highly recommended that you upgrade to the latest stable version.

L'évaluation réalisée par l'équipe a permis de noter certains soucis de sécurité. Mais avant tout, apportons quelques précisions.

  • La cible de sécurité portait essentiellement sur les nouvelles fonctionnalités de la version 6 (i.e. le chiffrement de bout en bout).
  • Nous avons bien sûr prévenu la TrueCrypt Foundation de ce que nous avions trouvé, mais "il ne s'agit pas de problèmes de sécurité" (citation) ... rien de neuf sous les tropiques.
  • TrueCrypt reste un bon produit, pratique et simple à utiliser.

Il est amusant (ou désespérant) de noter la réponse de TrueCrypt lors de la dernière faille qui leur a été communiquée :

* Vendor denies the vulnerability
* Fixed in updated versions

Rien n'a donc changé ... et pour les gens pressés, voici les 5 problèmes relevés lors de l'évaluation du logiciel :

  • la mémoire du BIOS révèle la taille du mot de passe d'une partition système (modulo 16) (not fixed) ;
  • il est possible de faire un DoS dans le driver truecrypt (enfin, au moins un, et au moins un DoS, peut-être plus si affinités) (fixed) ;
  • le chemin des keyfiles est toujours présent en mémoire (not fixed) ;
  • on peut retrouver en mémoire une clé de chiffrement d'un volume lorsqu'on sauvegarde son entête (fixed) ;
  • les mots de passe restent en mémoire lors de la création d'un nouveau volume (not fixed mais ce n'est pas de leur faute).

Et au niveau crypto :

  • possibilité de générer des collisions assez facilement avec les keyfiles (not fixed).

Puisqu'il ne s'agit pas de problèmes de sécurité, nous présentons les résultats de l'analyse.

Bugs et corrections (ou pas)

Taille du mot de passe d'une partition système

Lorsque la partition système est chiffrée, l'utilisateur doit saisir son mot de passe au boot afin de déchiffrer la partition. Le buffer du BIOS contenant le mot de passe a déjà été source d'un problème puisqu'il n'était pas effacé après utilisation [iviz, bugtraq]. Là où c'est dommage, c'est que la taille du mot de passe (i.e. le nombre de touches pressées) peut toujours être devinée, alors qu'il s'agit simplement de remettre à 0 deux entiers (l'adresse du premier caractère et l'adresse du dernier).

DoS dans le driver

Les données traitées par le pilote TrueCrypt lors de l'envoi de l'IRP TC_IOCTL_REOPEN_BOOT_VOLUME_HEADER ne sont pas gérées correctement. Le paramètre d'entrée est une structure Password, constituée du mot de passe de volume et de sa taille.

La taille est un entier signé. La borne supérieure de la taille du mot de passe est vérifiée par la fonction ReopenBootVolumeHeader. La borne inférieure n'est pas vérifiée.

La correction est relativement immédiate en forçant la taille à être non signée :

--- 6.1/Common/Password.h       2008-10-30 19:39:28.000000000 +0100
+++ 6.1a/Common/Password.h      2008-11-07 12:28:54.000000000 +0100
@@ -25,7 +25,7 @@
 typedef struct {
        // Modifying this structure can introduce incompatibility with previous versions
-       __int32 Length;
+       unsigned __int32 Length;
        unsigned char Text[MAX_PASSWORD + 1];
        char Pad[3]; // keep 64-bit alignment
 } Password;

Chemin des keyfiles en mémoire

Il est possible de monter des volumes TrueCrypt à l'aide de keyfiles. La liste en est spécifiée par l'utilisateur lors du montage d'un volume. Une représentation interne de la liste est construite par la fonction SelectMultipleFiles. Cette fonction copie la liste des fichiers dans une variable globale SelectMultipleFilesPath. Cette variable n'est jamais effacée.

Clé de chiffrement en mémoire lors de la sauvegarde des entêtes

Lors de la sauvegarde, l'en-tête est déchiffré avec le mot de passe utilisateur, puis de nouveau chiffré. Les clés de chiffrement ne sont pas modifiées. Seul un nouveau sel est généré. Lors de la création du fichier de sauvegarde, le contenu du buffer recevant le nouvel en-tête, non initialisé, est préalablement chiffré avec des clés temporaires, afin d'obtenir des données pseudo-aléatoires. Ceci est utilisé pour donner un aspect aléatoire à l'en-tête de volume caché, s'il n'y a pas de volume caché. Pour cela, deux clés temporaires sont générées.

La clé secondaire de chiffrement du volume est sauvegardée dans un buffer originalK2. La clé maitre temporaire est stockée dans temporaryKey. Ces deux variables ne sont jamais effacées.

La correction est effectuée de la même manière qu'est géré le problème avec les autres buffers, c'est-à-dire par un appel à la fonction burn :

--- ./6.1/Mount/Mount.c    2008-10-30 19:39:28.000000000 +0100
+++ ./6.1a/Mount/Mount.c   2008-11-27 09:23:14.000000000 +0100
@@ -6887,6 +6882,8 @@

        burn (&VolumePassword, sizeof (VolumePassword));
        burn (&hiddenVolPassword, sizeof (hiddenVolPassword));
+       burn (temporaryKey, sizeof (temporaryKey));
+       burn (originalK2, sizeof (originalK2));

        RestoreDefaultKeyFilesParam();
        NormalCursor();

Mot de passe en mémoire lors de la création d'un nouveau volume

La fonction VerifyPasswordAndUpdate est appelée lorsque l'utilisateur rentre le mot de passe de son nouveau volume. Le mot de passe doit être entré deux fois, afin que l'utilisateur ne puisse pas faire d'erreur de frappe. Cette fonction compare les deux mots de passe entrés, et active un bouton afin de passer à l'étape suivante s'ils sont identiques.

Cette fonction appelle les fonctions GetWindowTextLength et GetWindowText de Windows pour récupérer la longueur des mots de passe entrés et leur valeur. Ces deux fonctions n'effacent pas correctement le contenu de leur tampon mémoire sur la pile, et donc le mot de passe utilisateur. Ceci est dû au fonctionnement de Windows et n'est pas directement lié à l'utilisation de TrueCrypt.

Collision sur les keyfiles

Les fichiers de clé sont dérivés en une structure Password. Ce mot de passe est un buffer de 64 caractères obtenu en hachant les données du fichier clé avec plusieurs CRC32. Générer deux fichiers clés produisant la même mot de passe est très simple. Un exemple est disponible dans le rapport. Il devient alors possible de monter un volume avec deux fichiers clés différents. Cela n'entraîne pas de problème de sécurité direct sur un volume protégé par un fichier clé. Néanmoins, l'utilisation d'une fonction de hachage cryptographique aurait été à notre avis un meilleur choix.