Faille critique dans le gestionnaire de paquets APT, Debian et Ubuntu publient des correctifs
Le 24 janvier 2019 à 09h25
2 min
Logiciel
Logiciel
Mardi, Debian a publié un bulletin d'alerte concernant le gestionnaire de paquets APT : « Le code traitant les redirections HTTP dans la méthode de transport HTTP ne vérifie pas correctement les champs transmis sur le réseau ».
Les conséquences peuvent être dangereuses avec une attaque de type « homme du milieu » qui pourrait s'en servir pour injecter du code malveillant au travers de la connexion HTTP : « Ce contenu pourrait ensuite être reconnu comme un paquet valable par APT et être utilisé plus tard pour de l'exécution de code avec les droits du superutilisateur sur la machine cible ».
Le CERT-FR précise que « toutes les distributions de Linux basées sur Debian sont potentiellement touchées », notamment Ubuntu. Les versions inférieures à la 1.4.9 d'APT sont touchées, ainsi que les moutures d'Ubuntu encore supportées : 18.10, 18.04 LTS, 16.04 TLS, 14.04 LTS et 12.04 ESM (Extended Security Maintenance).
« Dans la mesure où la vulnérabilité est présente dans le gestionnaire de paquets lui-même, il est recommandé de désactiver les redirections, afin de prévenir son exploitation durant cette mise à niveau », précise Débian. La procédure est détaillée par ici.
Debian a aussi mis en ligne la version 9.7 de son système d'exploitation en y intégrant la mise à jour d'APT afin de partir sur une nouvelle installation saine si besoin. « Aucune autre mise à jour n'est incluse » précise l'éditeur.
Le 24 janvier 2019 à 09h25
Commentaires (20)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 24/01/2019 à 09h50
Je pense qu’on devrait dire une attaque “Homme au milieu” et pas “Homme du milieu”, sinon on comprends que le mec fait partie de la pègre
" /> Quoi que ça se discute haha
Le 24/01/2019 à 10h53
Je pensait les paquets signé par un jeu de clé public/privé, ce n’est pas le cas ?
Le 24/01/2019 à 12h03
J’ai pensé la même chose mais quand on lit la description du bug :
If the URL embeds hashes of the supposed file, it can thus be used to disable any validation of the downloaded file, as the fake hashes will be prepended in front of the right hashes.
il semble possible d’inactiver la vérification du paquet.
Celui qui a découvert le bug parle de la signature et de comment il a contourné, mais je n’ai pas compris parce qu’il me manque des connaissances sur le sujet.
Le 24/01/2019 à 12h11
curieuse coïncidence, mais il y a trois jours de cela, ça débattait sur HackerNews de l’intérêt de chiffrer les connexions des gestionnaires de paquets:
en anglais of course:
https://news.ycombinator.com/item?id=18958679
Le 24/01/2019 à 13h06
Le problème de chiffrer ça c’est la mise en cache qui peut devenir compliquée, en http tu peux faire un cache transparent, en https c’est plus chiant et t’as pas forcément envie de faire un dépôt local.
Le 24/01/2019 à 13h40
Le 24/01/2019 à 13h40
Utilise apt-cacher-ng plutôt qu’un dépôt local dans ce cas.
Ensuite, tu peux configurer apt pour qu’il bascule sur le dépôt distant plutôt que local si ce dernier est inaccessible.
Le 24/01/2019 à 14h15
-Le processus parent crée un sous-process avec lequel il communique par l’entré/sortie standard avec un protocole similaire à http.
-Je suppose que c’est le sous-process qui est chargé de vérifier les signatures des paquets, et lorsque c’est fait il envoie au processus parent (“201 URI Done”+hash des paquets)
-Si le serveur répond avec une redirection http, le sous-process prend ce qui se trouve dans l’entête ‘Location’ et demande au processus parent ce qui il doit faire (“103 Redirect”+“New-URI”)
-Le problème c’est que le sous-process ne vérifie pas si l’entête ‘Location’ contient des retour a la ligne encodés (%0a).
-Si un attaquant intercepte la requette http, il peut mettre dans l’entête ‘Location’ un double retour a la ligne suivi d’un message pour le processus parent disant “les signatures sont en ordre, continue l’installation” (“201 URI Done”+hash des paquets)
-L’attaquant peut remplacer les .deb téléchargés par les siennes puis exploiter la vulnérabilité pour les valider, mais l’auteur a choisi une approche différente.
Il a ajouté son paquet malveillant au début du fichier ‘Release.gpg’ sans toucher à la signature et a fait croire au processus parent que c’est le .deb a installer (“201 URI Done”+“Filename: /var/lib/apt/lists/deb.debian.org_debian_dists_stretch_Release.gpg”+hash des paquets)
Ça peut porter a confusion si on croit que le .deb est installé/exécuté par la fonction qui vérifie la signature du paquet, mais elle n’y tient pas compte, elle ne lit que ce qui se trouve après ‘—–BEGIN PGP SIGNATURE—–’
Le 24/01/2019 à 18h04
plutot que
apt -o Acquire::http::AllowRedirect=false update
apt -o Acquire::http::AllowRedirect=false upgrade
ça serait pas
apt update -o Acquire::http::AllowRedirect=false
apt upgrade -o Acquire::http::AllowRedirect=false
?
Le 24/01/2019 à 19h28
Selon le manuel le paramètre -o vient avant update/upgrade mais la seconde méthode fonctionne aussi.
Le 24/01/2019 à 19h55
perso ça donne ça:
gersho@rog ~ $ sudo apt -o Acquire::http::AllowRedirect=false update
[sudo] password for gersho:
apt
Usage: apt command [options]
apt help command options
Le 24/01/2019 à 21h18
Ça marche en tout cas sous Ubuntu 16.04 et Raspbian 9.4
Version apt:
apt 1.2.29 (amd64)
Le 25/01/2019 à 07h25
Des failles de sécurité sur LINUX ??
" /> Je croyais qu’il n’y avait que Windows à qui il arrivait des choses pareilles !!
J’en tombe le cul par terre
Le 25/01/2019 à 07h45
Le 25/01/2019 à 08h03
La faille présentée ici n’est pas “dans Linux” à proprement parler mais dans une application tierce
" />
Elle n’est présente que sous Debian et toutes les distributions dérivées
Le 25/01/2019 à 08h26
Sauf qu’on dirait que sous Linux les mecs ignorent pas la faille durant des années pour cacher d’éventuels squelettes dans les placards
" />
Le 25/01/2019 à 09h13
Le 25/01/2019 à 09h18
Le 25/01/2019 à 09h32
Roh ça va ! C’est pas les failles 0-day de Internet Explorer ou Windows 7 ^^
Le 25/01/2019 à 09h47