A été identifié une vulnérabilité dans le gestionnaire de paquets APT (CVE-2019-3462), Quoi permet à un attaquant d'initier une usurpation du package installé si l'attaquant a le contrôle du miroir du référentiel ou peut perturber le trafic de transit entre l'utilisateur et le référentiel (attaque MITM).
Le problème a été identifié par le chercheur en sécurité Max Justicz, connu pour détecter des vulnérabilités dans le gestionnaire de packages APK (Alpine) et dans les référentiels Packagist, NPM et RubyGems.
Le problème Cela est dû à une vérification incorrecte des champs dans le code de traitement de la redirection HTTP.
Quel est le problème?
Cette vulnérabilité permet à un attaquant de substituer son propre contenu dans les données transmises au sein de la session HTTP (Debian et Ubuntu utilisent HTTP et non HTTPS pour accéder au référentiel, en supposant que la signature numérique est suffisante avec les métadonnées et la taille de paquet correspondantes.)
La vulnérabilité identifiée permet à l'attaquant de remplacez le paquet transmis, après quoi APT le percevra comme reçu du miroir officiel et commencera le processus d'installation.
Grâce à l'inclusion dans le package malveillant de scripts lancés lors de l'installation, un attaquant peut réaliser l'exécution de son code sur un système avec les privilèges root.
Pour télécharger les données du référentiel, APT démarre un processus enfant avec la mise en œuvre d'un transport spécifique et organise l'interaction avec ce processus à l'aide d'un protocole de texte simple avec la division des commandes par une ligne vide.
Comment détecter le problème?
L'essence du problème est que le gestionnaire de transport HTTP, à la réception d'une réponse du serveur HTTP avec l'en-tête "Location:", il demande la confirmation de la redirection du processus principal.
Transférer complètement le contenu de cet en-tête. En raison du manque de propreté des caractères spéciaux transmis, un attaquant peut spécifier un saut de ligne dans le champ "Location:"
Étant donné que cette valeur sera décodée et transmise via le canal de communication avec le processus principal, l'attaquant peut simuler une réponse différente du gestionnaire de transport HTTP et remplacer le bloc URI 201 factice.
Par exemple, si, lors de la demande d'un paquet, l'attaquant substitue la réponse, cette substitution se traduira par le transfert du bloc de données suivant vers le processus principal.
Le calcul des hachages pour les fichiers téléchargés est géré et le processus principal vérifie simplement ces données avec des hachages de la base de données des packages signés.
Parmi les métadonnées, un attaquant peut spécifier n'importe quelle valeur de hachages de test liés dans la base de données aux packages signés réels, mais cela ne correspond pas réellement aux hachages du fichier transféré.
Le processus principal acceptera le code de réponse remplacé par l'attaque, recherchera le hachage dans la base de données et considérera que le paquet pour lequel il existe une signature numérique correcte est chargé, bien qu'en réalité la valeur du champ avec le hachage soit substituée dans le canal de communication avec le processus principal utilisant l'attaque et le fichier spécifié dans les métadonnées remplacées.
Le téléchargement d'un package malveillant se fait en attachant le package au fichier Release.gpg, lors du transfert.
Ce fichier a un emplacement prévisible sur le système de fichiers et l'attachement d'un package à son démarrage n'affecte pas l'extraction de la signature numérique du référentiel.
Lors de l'obtention de données, apt désactive les processus de travail spécialisés dans les différents protocoles qui seront utilisés pour le transfert de données.
Le processus principal communique ensuite avec ces travailleurs via stdin / stdout pour leur dire quoi télécharger et où le mettre sur le système de fichiers en utilisant un protocole qui ressemble un peu à HTTP.
Le processus principal soumettra alors sa configuration et demandera une ressource et le processus de travail répondra.
Lorsque le serveur HTTP répond par une redirection, le processus de travail renvoie une redirection 103 au lieu d'un URI 201 Done, et le processus principal utilise cette réponse pour déterminer la ressource à demander ensuite.