Weak random generator use in fusiondirectory-setup
Weak random generator use in fusiondirectory-setup
À l'occasion d'une installation de Fusion Directory, j'ai vu qu'on pouvait chiffrer le mot de passe d'accès au serveur LDAP.
Le script qui fait cela dans fusiondirectory-1.3 est (contrib/bin/fusiondirectory-setup) tire une clé à l'aide de la fonction get_random_string, définie à partir de la ligne 228 :
sub get_random_string {
my ($size) = @_;
$size = 32 if !$size;
my @chars = ("A".."Z", "a".."z", '.', '/', 0..9);
my $string;
$string .= $chars[rand @chars] for 1..$size;
return $string;
}La fonction utilisée pour cela est rand (ligne juste au-dessus du return). Comme le dit la documentation de rand (https://perldoc.perl.org/functions/rand.html) :
rand is not cryptographically secure. You should not rely on it in security-sensitive situations. As of this writing, a number of third-party CPAN modules offer random number generators intended by their authors to be cryptographically secure, including: Data::Entropy, Crypt::Random, Math::Random::Secure, and Math::TrulyRandom.
Le problème est que le résultat d'une fonction comme rand peuvent relativement aisément se deviner. La vulnérabilité est ici relativement mineure mais je vous suggère de corriger car cela n'est pas très difficile : il suffit de faire appel à la fonction Random du module Crypt, déjà utilisé dans ce script.
Cela dit :
-
Je ne suis pas certain d'avoir bien compris toutes les implications de ce chiffrement et de l'utilisation du module header d'apache pour transmettre la clé de chiffrement à l'application. Est-ce que l'idée est de résister à une faille qui permettrait de faire de la lecture de fichiers arbitraires avec les droits du serveur mais pas de lire les entêtes HTTP ?
-
Dans tous les cas, stocker le mot de passe LDAP (chiffré ou non) n'est pas l'idéal en terme de sécurité (c'est plutôt une vulnérabilité importante) ; idéalement, c'est le mot de passe entré par l'utilisateur de Fusion Directory qui devrait être utilisé auprès du serveur LDAP et les droits devraient être gérés au niveau du serveur LDAP. J'ai l'impression que ce n'est pas ce qui a été fait mais j'imagine que c'est assez difficile à modifier après coup.
-
Merci pour ce projet et merci d'en avoir fait un logiciel libre ! (Je l'ai découvert en aidant une association à monter son serveur LDAP)
Très cordialement,
Judicaël Courant.
Activity
added PJ1802-0188 label
Je ne suis pas certain d'avoir bien compris toutes les implications de ce chiffrement et de l'utilisation du module header d'apache pour transmettre la clé de chiffrement à l'application. Est-ce que l'idée est de résister à une faille qui permettrait de faire de la lecture de fichiers arbitraires avec les droits du serveur mais pas de lire les entêtes HTTP ?
L’idée est d’éviter d’avoir un mot de passe en clair dans le fichier de configuration, et potentiellement de pouvoir donner le droit à quelqu’un de lire/éditer le fichier de configuration sans lui donner le mot de passe LDAP.
Dans tous les cas, stocker le mot de passe LDAP (chiffré ou non) n'est pas l'idéal en terme de sécurité (c'est plutôt une vulnérabilité importante) ; idéalement, c'est le mot de passe entré par l'utilisateur de Fusion Directory qui devrait être utilisé auprès du serveur LDAP et les droits devraient être gérés au niveau du serveur LDAP. J'ai l'impression que ce n'est pas ce qui a été fait mais j'imagine que c'est assez difficile à modifier après coup.
Ce n’est pas possible, parce que FusionDirectory fait en arrière-plan beaucoup de modifications que l’utilisateur n’a pas le droit de faire lui-même, notamment sauver des évènements d’audit si le plugin est installé, et appliquer les clés étrangères. Par exemple un utilisateur A peut avoir le droit de supprimer l’utilisateur X, auquel cas FD va retirer X de tous les groupes dont il fait partie, même si A n’a pas le droit de modifier ces groupes.
By Côme Chilliet on 2020-04-28T08:12:23 (imported from GitLab)
added Security label
changed milestone to %FusionDirectory 1.3.1
added FSA-0022 label
mentioned in commit b4eef767
By Côme Chilliet on 2020-12-15T10:51:05 (imported from GitLab)
added To Be Tested label
It seems this is causing this error on the test setup:
Can't locate Bytes/Random/Secure.pm in @INC (you may need to install the Bytes::Random::Secure module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.24.1 /usr/local/share/perl/5.24.1 /usr/lib/x86_64-linux-gnu/perl5/5.24 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.24 /usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /usr/sbin/fusiondirectory-setup line 47, <DATA> line 755.So I think
libbytes-random-secure-perlneeds to be added to dependances.By Côme Chilliet on 2021-01-12T08:41:59 (imported from GitLab)
added packaging label
added enhancement fusiondirectory-core labels
removed To Be Tested label
