Des vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 identifi\u00e9es dans le gestionnaire de paquets Guix (CVE non attribu\u00e9s) dans l'impl\u00e9mentation de la commande interne \u00ab guix substitute \u00bb, automatiquement appel\u00e9e par le processus en arri\u00e8re-plan guix-daemon lors des op\u00e9rations d'installation de paquets. Cette commande est utilis\u00e9e pour t\u00e9l\u00e9charger des paquets binaires d\u00e9j\u00e0 construits depuis des serveurs externes, avec v\u00e9rification de leur int\u00e9grit\u00e9 \u00e0 l'aide d'une signature num\u00e9rique. La vuln\u00e9rabilit\u00e9 la plus grave permet d'ex\u00e9cuter \u00e0 distance du code sur le syst\u00e8me de l'utilisateur avec les droits du processus en arri\u00e8re-plan guix-daemon. <\/p>\n
Le probl\u00e8me concerne toutes les configurations avec le processus guix-daemon, que celui-ci soit ex\u00e9cut\u00e9 avec les privil\u00e8ges root ou sous un utilisateur non privil\u00e9gi\u00e9. Pour exploiter la vuln\u00e9rabilit\u00e9, il suffit d'une tentative de t\u00e9l\u00e9chargement de paquets binaires pr\u00eats depuis de serveurs<\/a>, contr\u00f4l\u00e9 par l'attaquant. Le fichier malveillant serveur<\/a> il n'est pas n\u00e9cessaire qu'il soit explicitement choisi ou indiqu\u00e9 dans les param\u00e8tres de l'utilisateur \u2014 il peut \u00eatre d\u00e9termin\u00e9 \u00e0 l'aide de l'option \u00ab --discover \u00bb, ce qui permet de substituer le serveur lors d'une attaque MITM. Dans les configurations o\u00f9 guix-daemon est lanc\u00e9 avec des privil\u00e8ges \u00e9lev\u00e9s, un utilisateur local peut mener une attaque s'il a la possibilit\u00e9 de se connecter au processus en arri\u00e8re-plan via un socket Unix (qui est accessible par d\u00e9faut \u00e0 tous les utilisateurs). <\/p>\n La vuln\u00e9rabilit\u00e9 est pr\u00e9sente dans le gestionnaire \u00ab restore-file \u00bb, utilis\u00e9 pour d\u00e9compresser \u00e0 la vol\u00e9e un paquet, sans attendre son t\u00e9l\u00e9chargement complet et la v\u00e9rification de l'archive t\u00e9l\u00e9charg\u00e9e par signature num\u00e9rique. Le probl\u00e8me provient de l'absence de v\u00e9rification des caract\u00e8res \u00ab . \u00bb, \u00ab \/ \u00bb et \u00ab .. \u00bb dans les chemins de fichiers contenus dans l'archive. Par une substitution de noms de fichiers malveillants dans l'archive, l'attaquant peut parvenir \u00e0 \u00e9crire un fichier arbitraire dans n'importe quelle zone du syst\u00e8me de fichiers, selon les droits sous lesquels le processus en arri\u00e8re-plan guix-daemon est ex\u00e9cut\u00e9. <\/p>\n Pour organiser l'ex\u00e9cution de son code sur le syst\u00e8me, par exemple, on peut ajouter un script \u00e0 ex\u00e9cution automatique, tel que \u00ab ~\/.bashrc \u00bb ou \u00ab ~\/.profile \u00bb, ou modifier le fichier \u00ab ~\/.ssh\/authorized_keys \u00bb contenant les cl\u00e9s SSH. Si dans un syst\u00e8me multi-utilisateurs guix-daemon s'ex\u00e9cute sous l'utilisateur root, l'attaquant peut \u00e9craser le fichier contenant les mots de passe ou les scripts syst\u00e8me. <\/p>\n La possibilit\u00e9 de cr\u00e9er des serveurs interm\u00e9diaires pour la distribution de paquets malveillants est due au fait que la proc\u00e9dure de chargement des m\u00e9tadonn\u00e9es (narinfo) sur les paquets binaires disponibles (fetch-narinfos) ne v\u00e9rifiait pas le certificat du serveur, se fiant au fait que la majeure partie des m\u00e9tadonn\u00e9es est sign\u00e9e num\u00e9riquement. Il s'est av\u00e9r\u00e9 que la signature n'incluait pas l'URL de t\u00e9l\u00e9chargement du paquet, ce qui permettait de la remplacer sans compromettre l'int\u00e9grit\u00e9 des m\u00e9tadonn\u00e9es. En fin de compte, le paquet falsifi\u00e9 serait rejet\u00e9 en raison de l'\u00e9chec de la v\u00e9rification de son contenu par le hachage, valid\u00e9 par la signature num\u00e9rique, mais cette v\u00e9rification \u00e9tait effectu\u00e9e apr\u00e8s la phase de d\u00e9compression, o\u00f9 le probl\u00e8me avec les caract\u00e8res sp\u00e9ciaux dans les noms de fichiers se manifestait. <\/p>\n En plus de la commande «guix substitute», le gestionnaire vuln\u00e9rable «restore-file» est \u00e9galement utilis\u00e9 par les commandes «guix offload», «guix archive —extract» et «guix challenge», par lesquelles la vuln\u00e9rabilit\u00e9 peut \u00e9galement \u00eatre exploit\u00e9e. Comme solution de contournement pour bloquer la vuln\u00e9rabilit\u00e9, il est conseill\u00e9 de sp\u00e9cifier explicitement l'option «—no-substitutes» dans toutes les commandes guix. Le correctif de cette vuln\u00e9rabilit\u00e9 a \u00e9t\u00e9 int\u00e9gr\u00e9 \u00e0 la base de code de Guix. Il est recommand\u00e9 aux utilisateurs d'installer sans d\u00e9lai les mises \u00e0 jour fournies par les d\u00e9veloppeurs pour guix et guix-daemon. <\/p>\n En plus du probl\u00e8me signal\u00e9 dans Guix, trois autres vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 corrig\u00e9es : <\/p>\n\n