La signature des paquets ne devrait‐elle pas protéger contre tout paquet illégitime ?
Si quelqu’un substitue un paquet signé par un paquet malveillant, à moins qu’il n’ait récupéré une clé publique de la distribution ou cassé l’algorithme de signature, son paquet ne peut pas avoir de signature valide.
Ou alors les paquets .deb ne seraient‐ils pas signés ?
J’avais pourtant cru comprendre avant qu’Arch mette en place la signature de ses paquets en 2012 qu’elle était en retard à ce sujet sur les distributions majeures.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
En pratique, ce ne sont pas les paquets qui sont signés, mais les listes de paquets. Si j'ai bien compris le fonctionnement d'APT et de la faille, celle-ci se situe entre la vérification de la liste et l'installation des paquets demandés.
Ça donne :
- apt update : APT télécharge les listes de paquets et leur signature <- Première étape : l'attaquant ajoute un fichier .deb avant la signature dans le fichiers Release.gpg contenant les signatures (il peut, il est au milieu de la connexion et celle-ci n'est pas chiffrée). APT valide la signature, il s'en fiche du .deb ajouté (ou de tout autre contenu ajouté).
- apt install xxx : APT commence à télécharger le paquet voulus <- Seconde étape: l'attaquant fait croire à APT qu'il y a une redirection vers une URL qui ne sera pas correctement traitée par APT, et qui fera croire à APT que le fichier a bien été téléchargé et qu'il est à la place du fichier Release.gpg
- APT installe le fichier Release.gpg, croyant que c'est le fichier .deb demandé par l'utilisateur.
# Informations techniques
Posté par Flavien . Évalué à 3.
Remote Code Execution in apt/apt-get
# Signature des paquets ???
Posté par Arthur Accroc . Évalué à 4.
La signature des paquets ne devrait‐elle pas protéger contre tout paquet illégitime ?
Si quelqu’un substitue un paquet signé par un paquet malveillant, à moins qu’il n’ait récupéré une clé publique de la distribution ou cassé l’algorithme de signature, son paquet ne peut pas avoir de signature valide.
Ou alors les paquets .deb ne seraient‐ils pas signés ?
J’avais pourtant cru comprendre avant qu’Arch mette en place la signature de ses paquets en 2012 qu’elle était en retard à ce sujet sur les distributions majeures.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Signature des paquets ???
Posté par Samuel (site web personnel) . Évalué à 6.
En pratique, ce ne sont pas les paquets qui sont signés, mais les listes de paquets. Si j'ai bien compris le fonctionnement d'APT et de la faille, celle-ci se situe entre la vérification de la liste et l'installation des paquets demandés.
Ça donne :
- apt update : APT télécharge les listes de paquets et leur signature <- Première étape : l'attaquant ajoute un fichier .deb avant la signature dans le fichiers Release.gpg contenant les signatures (il peut, il est au milieu de la connexion et celle-ci n'est pas chiffrée). APT valide la signature, il s'en fiche du .deb ajouté (ou de tout autre contenu ajouté).
- apt install xxx : APT commence à télécharger le paquet voulus <- Seconde étape: l'attaquant fait croire à APT qu'il y a une redirection vers une URL qui ne sera pas correctement traitée par APT, et qui fera croire à APT que le fichier a bien été téléchargé et qu'il est à la place du fichier Release.gpg
- APT installe le fichier Release.gpg, croyant que c'est le fichier .deb demandé par l'utilisateur.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.