Dans la livraison de février du magasine ;Login, un article au format pdf propose une intéressante analyse de la sécurité des différents gestionnaire de paquets de nos distributions Linux.
Les auteurs sont étudiants à l'université d'Arizona et post-doc à l'université de Washington et ils travaillent sur un tout nouveau gestionnaire de paquet nommé Stork (Cigogne). Dans le cadre de leur recherche ils se sont intéressés aux attaques qu'il était possible d'effectuer contre les gestionnaires de paquets déjà existants et ils ont entamé une étude assez générale.
Un site web récapitulant leurs résultats a également été mis en place et une FAQ est disponible.
Les gestionnaires examinés sont :
APT : Pour Debian et Ubuntu.
APT-RPM : Pour ALT Linux et PCLinuxOS.
Pacman : Pour Arch Linux.
Portage : Pour Gentoo.
Slaktool: Pour Slackware.
URPMI : Pour Mandriva.
YaST : Pour openSUSE et SUSE Linux Enterprise.
YUM : Pour Fedora, Red Hat Enterprise et CentOS.
En gros ils ont identifiés trois risques possibles :
- Les attaques de type "replay" ou "freeze" qui sont possibles car la signature cryptographique d'un paquet n'a pas de date d'expiration. Comme il n'y a pas de date d'expiration alors un paquet signé restera toujours valable et sera donc accepté par le gestionnaire de paquets. Il suffit alors à l'attaquant (qui peut gérer un miroir) de proposer au client des vieux paquets ayant des vulnérabilités connues et exploitables.
Cette attaque n'est possible que parce que l'attaquant a mis en place un miroir public (les miroirs sont utilisés par la plupart des distributions communautaires).
- Les attaques par modification des métadonnées qui deviennent possibles si les gestionnaires de paquets ne signent pas cryptographiquement le fichier racine des métadonnées de paquets. Dans ce cas c'est encore plus simple pour l'attaquant. Il lui suffit de modifier les métadonnées des paquets pour indiquer une nouvelle dépendance qui "embarquera" son logiciel trojané lors de toute nouvelle mise à jour demandée par le client. Par exemple il indiquera dans les métadonnées de tous les logiciels KDE que ces paquets dépendent du paquet "toto". Quand le client fera une mise à jour quelconque d'un logiciel KDE alors "toto" sera installé également.
Encore une fois cette attaque est possible car l'attaquant a le contrôle d'un miroir.
- Les attaques "bêtes et méchantes" par déni de service qui consistent essentiellement à répondre par un flux de données continu lors d'une requête de mise à jour d'un client.
Ce qui est étonnant c'est que les parades à ces vulnérabilités semblent assez simples à corriger et qu'il semble étonnant que les gestionnaires de paquets de nos distributions puissent se faire entourlouper par des ruses aussi naïves. Pour la première il est évident qu'il faut que les signatures des métadonnées ou des paquets ne soient plus valables ad vitam aeternam et il faut que le client vérifie la date d'expiration. La seconde se colmate en exigeant que les métadonnées soient signées et que le client vérifie cette signature. La troisième vulnérabilité est évité si un timeout est mis en place lors des téléchargements et que le client est apte à choisir un miroir différent si le premier envoir un flux continu de données.
Coté bilan , et même si des précautions méthodologiques doivent être prises puisque l'étude date de 2008, on peut dire ceci :
- L'utilisation de Slackware et de Pacman doit être évité car ces gestionnaires ne aucun effort spécifique de sécurité.
- YUM, URPMI et Portage ne signent pas le fichier racine des métadonnées des paquets mais seulement les paquets eux-mêmes. Ces gestionnaires sont donc vulnérables aux attaques par manipulation des métadonnées. YUM a depuis été modifié pour signer les métadonnées et cette fonction sera (peut-être) utilisée pour Fedora 11.
- APT-RPM a la possibilité de signer les métadonnées mais PCLinuxOS n'utilise pas cette fonction.
- YaST et APT sont les gestionnaires les plus sécurisés car ils signent en amont (le fichier racine des métadonnées) et pas en aval (seulement les paquets) mais ils restent vulnérables à l'attaque par déni de service et la signature des métadonnées n'a pas de date d'expiration (ce qui sera facile à corriger).
- Ce qui est le plus sécurisé c'est de ne pas utiliser du tout de miroir public et d'avoir seulement des dépots officiels. Les distribution de type "entreprise" comme Red Hat Enterprise Linux et SUSE Linux Enterprise n'utilisent pas le système des miroirs publics et sont donc immunisés contre la plupart des attaques. De plus le client dialogue en SSL avec le dépôt officiel ce qui évite également les attaques de type "homme au milieu". Les distributions communautaires n'utilisent pas SSL pour l'instant.
Il est évident pour quiconque réfléchit 5 minutes que le modèle à base de dépôts des distribution Linux est incomparablement meilleur que la lamentable errance de site en site à laquelle est condamné un utilisateur de Windows. Néanmoins les distributions doivent être prudentes et sérieuses dans la gestion effective de ce modèle centralisé. Peut-être que cette étude sera un salutaire rappel et permettra d'améliorer la sécurité de nos distributions.
Journal La sécurité des gestionnaires de paquets
10
avr.
2009
# Mouaif
Posté par IsNotGood . Évalué à -4.
C'est le problème classique de la chaine de confiance.
> - YUM, URPMI et Portage ne signent pas le fichier racine des métadonnées des paquets mais seulement les paquets eux-mêmes. Ces gestionnaires sont donc vulnérables aux attaques par manipulation des métadonnées.
Pour yum, bof.
Si tu manipules les métadonnées de Yum, ça n'ira pas loin. Ce qui est pris en compte pour l'installation sont les informations des paquets (pas de yum). Les informations de Yum sont seulement une optimation (afin de ne pas avoir à télécharger tous les paquets rpm). Les informations de yum sont (normalement) seulement l'extraction des informations des paquets rpm.
Si les métadonnées de Yum sont manipulées, il y aura échec de l'installation des paquets. Yum accèpte, mais rpm qui a le dernier mot refuse. Notons bien que Yum ne fait pas d'installation de paquet, il demande à rpm (librpm qui fera les vérifications avec les données des rpm et non de yum) de le faire.
C'est vraiment à mon avis un petit problème. Un problème que je juge grave et que malheureusement Fedora refuse de prendre en compte depuis des années, est la non-signature systématique des rpm de Rawhide. Certe Rawhide n'a pas à être utilisé en production. Mais Rawhide est souvent installé en parallèle avec un installation qui a des données sensibles (clée gpg, etc).
A moins de débrancher les disques avec des données sensibles ou de faire une installation sur une machine virtuelle, il n'y a pas de parade.
[^] # Re: Mouaif
Posté par tuXico . Évalué à 6.
C'est le problème classique de la chaine de confiance.
La bonne nouvelle, c'est que la réponse est dans la question.
[^] # Re: Mouaif
Posté par Pascal Terjan (site web personnel) . Évalué à 3.
Tu pense que yum après avoir vu qu'il faut installer ce package et l'avoir téléchargé ne demandera pas à rpm de l'installer parce qu'en fait la dependance n'est sur aucun des packages ?
Ca veut dire qu'il fait n fois la resolution de dépendances (à chaque fois qu'il ajoute dans la liste des packages à installer un rpm local et donc que ca change eventuellement les dependances connues de ce package), ca serait vraiment très très lent
[^] # Re: Mouaif
Posté par IsNotGood . Évalué à 1.
C'est même fait 3 fois...
- 1 fois par yum afin de savoir ce qu'il faut télécharger. Ben oui, et tout le monde doit le faire, ça n'a rien de spécifique à Yum.
- 1 fois par rpmlib (demandé par yum) dans une transaction "à blanc" (pas de modification du système de fichier ou de la base rpm). Mieux vaut voir les problèmes au plus tôt que durant l'installation.
- 1 dernière fois par rpmlib qui fait enfin le boulot.
Mais en fait la résolution de dépendance pour déterminer les paquets nécessaires n'est faite qu'une fois. Les fois suivantes ne sont que des vérifications. Par mesure de sécurité, Yum ne demande pas à rpm (librpm) d'installer des paquets avec "--nodeps" ou autre (le comme fait (ou faisait ?) apt-rpm).
> ca serait vraiment très très lent
Le seul truc que fait Yum en plus des autres, c'est la transaction de test. Si elle échoue, il y a un bug au niveau de Yum.
Yum ne cherche pas à être rapide au détriment de la sécurité/fiabilité.
[^] # Re: Mouaif
Posté par Pascal Terjan (site web personnel) . Évalué à 7.
L'utilisateur va demander A et B
Les meta données vont dire A a besoin de C et B a besoin de C alors que c'est faux
yum va télécharger A B et C et demander à rpm de les installer donc tu auras le C avec les failles que tu n'avais pas demandé
La solution n fois dont je parlais aurait consisté après download a regarder les deps de A et B et ajouter à la liste ceux des rpm téléchargés nécessaires, et ainsi de suite, pour pas dépendre des meta données et ne rien installer d'inutile...
[^] # Re: Mouaif
Posté par IsNotGood . Évalué à 0.
> Les meta données vont dire A a besoin de C et B a besoin de C alors que c'est faux
Mais A, B et C doivent être des paquets signés.
Imaginons que C est httpd, ben httpd (comme presque tous les services) n'est pas activé par défaut. Il faut une opération manuelle.
Et pour les bécanes qui ont déjà httpd, ça ne change rien (le downgrade sera refusé). On peut trouver quelques cas spéciaux. Par exemple l'ajout de php active son support dans httpd.
Tu as raison, mais c'est assez la galère...
# PiSI ?
Posté par vida18 . Évalué à 1.
http://www.pardus-fr.org/
[^] # Re: PiSI ?
Posté par patrick_g (site web personnel) . Évalué à 5.
A noter que j'ai rédigé ce journal suite à la lecture d'un article du site LWN qui sera libéré jeudi prochain : http://lwn.net/Articles/327847/
[^] # Re: PiSI ?
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 1.
Some package managers don’t make any pretense of being secure in the first place (such as Slaktool on Slackware and Pacman on Arch Linux). We strongly recommend against using package managers that don’t try to be secure.
Et pourquoi ? J'ai toujours pas compris la raison de vouloir "sécuriser" un système de paquets.
J'utilise Zenwalk, dérivé de Slackware (les packages sont compatibles de Slackware => Zenwalk). Le gestionnaire officiel est "netpkg" qui contient une liste de miroir fiables (doit y'en avoir 6 ou 7 max).
Quand on utilise le gestionnaire de paquets, on choisi parmi ces 6 ou 7 mirroirs fiables. En quoi est-ce un problème ? Les 6 ou 7 personnes/entreprises/assoc derrière ces 6 miroirs ont été jugé comme personnes de confiance. C'est le même principe que SSL, faut bien faire confiance à quelqu'un au départ.
Ces 6 miroirs font un rsync sur le miroir principal à intervalles qui appartient aux administrateurs de ces miroirs.
Faut savoir aussi si on fait confiance au packagers ... et au mec qui met les paquets sur le miroir officiel etc...
C'est pas une histoire de gestionnaire de paquets mais de chaîne de confiance entre le source disponible sur le gestionnaire de version du logiciel jusqu'au paquet binaire installé sur le poste client.
Si je veux utiliser un dépot compatible slackware ou zenwalk, mais non listé dans le fichier de conf de netpkg, je le peux, mais je le fais en âme et conscience, et la sécurité n'a rien à voir là dedans !
[^] # Re: PiSI ?
Posté par bubar🦥 (Mastodon) . Évalué à 3.
"pourquoi s' embeter avec des path ? on colle /home$USER/bin d' abord et ensuite toute la / et hop ça roule". "pourquoi s' embeter avec chattr puisqu' on peux déchattr si on est root ?" etc etc etc... pour finalement conduire à "pourquoi s' embêter avec la sécurité puisque de toute façon le plus gros problème se situe entre la chaise et le clavier" (pas très loin de moi le troll sur dodoz).
Oui sur le fond, mais réduire au maximum les fuites de confiance, c' est pas un mal, si ? ;)
[^] # Re: PiSI ?
Posté par Pascal Terjan (site web personnel) . Évalué à 5.
Avoir un moyen que les machines des utilisateurs ne soient pas corrompues dans ce cas est important (le mec qui prend controle d'un miroir a la liste des ip des mecs qui l'utilisent...)
[^] # Re: PiSI ?
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 4.
Je réagissais surtout aux "conseils" des deux mecs de ne pas utiliser Slackware ou Arch car leur gestionnaire de paquet de sont pas "sécurisé" (ce qui ne veut toujours rien dire).
Faut ptre prendre le contexte aussi...
[^] # Re: PiSI ?
Posté par Guillaume D. . Évalué à 4.
Donc il est plus facile (charge serveur) de faire une infrastructure d'une distribution en rolling-release que les autres.
[^] # Re: PiSI ?
Posté par Ozz . Évalué à 1.
http://fr.wikipedia.org/wiki/Paralogisme
[^] # Re: PiSI ?
Posté par Guillaume D. . Évalué à 3.
rolling-release -> 100000 telechargment de 3Mo / jours -> petit serveur
autre : tp de free est saturé quand elles sortes
la version 8 sort -> 100000 telechargement de 600Mo sur 1 jour -> gros serveur.
[^] # Re: PiSI ?
Posté par BAud (site web personnel) . Évalué à 2.
à la mise à jour de KDE ou GNOME, ce n'est que 3 Mo qui sont récupérés sur une rolling-release ? :D
[^] # Re: PiSI ?
Posté par Guillaume D. . Évalué à -2.
[^] # Re: PiSI ?
Posté par Kerro . Évalué à 3.
une liste de miroir fiablesCette liste ne peut pas garantir que le miroir sera fiable éternellement. Une manipulation sur une dns, et hop ton miroir n'est plus celui que tu crois. Une étourderie de l'administrateur, et hop ton miroir est sous le contrôle d'une autre personne. Etc.
[^] # Re: PiSI ?
Posté par Raphaël SurcouF (site web personnel) . Évalué à 3.
[^] # Re: PiSI ?
Posté par Spyhawk . Évalué à 2.
Je crois que l'article en question a déjà fait le tour du net (j'ai du le lire il y a quelques semaines). PDF dispo ici :
http://www.usenix.org/publications/login/2009-02/openpdfs/sa(...)
[^] # Re: PiSI ?
Posté par Spyhawk . Évalué à 2.
[^] # Re: PiSI ?
Posté par bubar🦥 (Mastodon) . Évalué à 3.
# Modif de métadonnées
Posté par Enoch (site web personnel) . Évalué à 1.
Encore une fois cette attaque est possible car l'attaquant a le contrôle d'un miroir."
Dans ce cas, le fameux paquet "toto" pleins de de vilains malwares n'est pas signé donc le gestionnaire de paquets affichera un avertissement de sécurité ... du coup ce genre d'attaque ne me semble pas possible avec les systèmes actuels de signature de paquets (sauf dans le cas d'un bug au niveau de l'interface chaise-clavier) ...
[^] # Re: Modif de métadonnées
Posté par patrick_g (site web personnel) . Évalué à 3.
"As mentioned, the lack of signed metadata allows attackers to lie to clients about what each package provides and requires.
By lying to clients about this information, an attacker can significantly increase the chances of a client installing a vulnerable package.
For example, if package foo has a vulnerability the attacker knows how to exploit, the attacker can provide metadata that says every package depends on package foo, in order to ensure that the client installs it when installing any other package."
Donc l'idée c'est que quand tu sait qu'un paquet quelconque du dépôt a un trou de sécurité tu peux forcer son installation lors de l'installation de n'importe quel autre paquet.
[^] # Re: Modif de métadonnées
Posté par tuXico . Évalué à 3.
Donc l'idée c'est que quand tu sait qu'un paquet quelconque du dépôt a un trou de sécurité tu peux forcer son installation lors de l'installation de n'importe quel autre paquet.
sous entendu forcer l'installation d'un paquet officiel contenant déjà un bug de sécu et qui était signé à la base (avant la découverte de la faille).
Ce type d'attaque est d'autant plus mali(g)ne que l'attaquant aura la liste des IP "infectées"
[^] # Re: Modif de métadonnées
Posté par bubar🦥 (Mastodon) . Évalué à -7.
private joke 2 :
tuXico, buvez une binouze pour moi, avec Fred, ce midi chez les bonn***** ;)
[^] # Re: Modif de métadonnées
Posté par Enoch (site web personnel) . Évalué à 1.
Mais dans ce cas le problème ne viendrais il pas plutôt de la "non-expiration" de la signature des paquets ?
Quoi qu'il en soit, ça serais aussi bien de signer les métadatas, on jamais trop prudent ...
[^] # Re: Modif de métadonnées
Posté par IsNotGood . Évalué à 1.
Certes, mais ce n'est que du théorique.
S'il y a une faille, il y a une mise à jour rapidement (si la faille est sérieuse).
Celui qui veut exploiter ce type de faille n'est pas plus en avance que ceux qui maintiennent la distribution.
La distribution met à jour, j'installe la mise à jour.
Le mirroir fait un "downgrade" (pour annuler la mise à jour). Yum refusera d'installer le vieux paquet. Il refuse par défaut tout downgrade. "Pire", si un paquet ne peut être mis à jour car un autre paquet l'empêche, Yum signale une erreur. Par exemple si le craket a mis un paquet avec "require kernel = 2.6.28.6-52" et qu'il y a un kernel supérieur, il y a alors une erreur. NB: dans ton scénario le cracker ne peut fixer la version, il doit utiliser une vieille version.
Yum récupère les mirroirs auprès de http://mirrors.fedoraproject.org/ . Le mirroir utilisé par yum varie d'une exécution à l'autre.
N'est pas dans la liste de mirrors.fedoraproject.org qui veut. Les mirroirs sont validés. Certes ce n'est pas une validation poussée, mais si un mirroir déconne, il est viré.
Dans tout ça, le cracker a bien meilleur temps d'attaquer les machines non encore à jour (et elles sont nombreuses !) que de se casser les couilles a faire un fake de mirroir.
Le problème des machines non à jour est BEAUCOUP plus grave. Les applets qui invitent à mettre à jour le système lorsque nécessaire sont indéniablement une avancée.
Enfin, contrairement à d'autre, Yum ne tolère pas qu'un paquet ne soit pas mis à jour.
Exemple qui marche avec apt (ou smartrpm) :
- installation de titi qui demande "kernel = 2.6.28"
- arrivée de la mise à jour de kernel vers 2.6.29
- apt ne dit rien alors qu'il ne peut appliquer une mise à jour ! Yum gueule.
Ceci est un problème bien plus grave que celui que tu donnes.
Certes Yum a tendance à pester souvent. Mais c'est intentionnel, c'est pour des raisons de sécurité. Ce rapport n'a fait que survoler les problèmes de système de paquet et sous un angle bien classique...
[^] # Re: Modif de métadonnées
Posté par kikicnrv . Évalué à 5.
apt-get ne devrait plus être utilisé pour la gestion des paquets .deb normalement.
Sur les distributions dont le format de paquets par défaut est le .deb, le gestionnaire par défaut est maintenant aptitude, et celui ci gère parfaitement ce dont tu parles.
Il faut comparer ce qui est comparable.
[^] # Re: Modif de métadonnées
Posté par barmic . Évalué à 5.
1 ) En production tu prend ton temps avant d'installer une mise à jour histoire de bien vérifier que ça s'intègre à ta configuration.
2 ) Prend en compte une mise à jour qui n'est pas "de sécurité". Elle apporteras de nouvelles fonctionnalités qui augmentent la probabilité de faille. Il arrive que Debian stable ne soit pas affecté par une faille de sécurité qui viens d'être découverte pour la simple raison que la version qui a introduit cette faille n'est pas inclus dans Debian stable.
Cette différence montre surtout la différence de philosophie entre les deux distributions : Fedora cherche à intégrer les dernières nouveautés, Debian c'est le contraire.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Modif de métadonnées
Posté par tuXico . Évalué à 5.
En effet, les dernières nouveautés cherchent à intégrer Debian ^^
[^] # Re: Modif de métadonnées
Posté par tuXico . Évalué à 3.
Evidemment, sinon il n'y a plus de morale, ma bonne dame.
Dans tout ça, le cracker a bien meilleur temps d'attaquer les machines non encore à jour (et elles sont nombreuses !) que de se casser les couilles a faire un fake de mirroir.
ça, ça m'a l'air plus vrai, encore que ce type d'attaque permet à l'attaquant de connaître à l'avance les machines vulnérables...
[^] # Re: Modif de métadonnées
Posté par IsNotGood . Évalué à 2.
Certes, mais ce n'est que du théorique.
S'il y a une faille, il y a une mise à jour rapidement (si la faille est sérieuse).
Celui qui veut exploiter ce type de faille n'est pas plus en avance que ceux qui maintiennent la distribution.
La distribution met à jour, j'installe la mise à jour.
Le mirroir fait un "downgrade" (pour annuler la mise à jour). Yum refusera d'installer le vieux paquet. Il refuse par défaut tout downgrade. "Pire", si un paquet ne peut être mis à jour car un autre paquet l'empêche, Yum signale une erreur. Par exemple si le craket a mis un paquet avec "require kernel = 2.6.28.6-52" et qu'il y a un kernel supérieur, il y a alors une erreur. NB: dans ton scénario le cracker ne peut fixer la version, il doit utiliser une vieille version.
Yum récupère les mirroirs auprès de http://mirrors.fedoraproject.org/ . Le mirroir utilisé par yum varie d'une exécution à l'autre.
N'est pas dans la liste de mirrors.fedoraproject.org qui veut. Les mirroirs sont validés. Certes ce n'est pas une validation poussée, mais si un mirroir déconne, il est viré.
Dans tout ça, le cracker a bien meilleur temps d'attaquer les machines non encore à jour (et elles sont nombreuses !) que de se casser les couilles a faire un fake de mirroir.
Le problème des machines non à jour est BEAUCOUP plus grave. Les applets qui invitent à mettre à jour le système lorsque nécessaire sont indéniablement une avancée.
Enfin, contrairement à d'autre, Yum ne tolère pas qu'un paquet ne soit pas mis à jour.
Exemple qui marche avec apt (ou smartrpm) :
- installation de titi qui demande "kernel = 2.6.28"
- arrivée de la mise à jour de kernel vers 2.6.29
- apt ne dit rien alors qu'il ne peut appliquer une mise à jour ! Yum gueule.
Ceci est un problème bien plus grave que celui que tu donnes.
Autre problème grave, l'exécutions des scripts rpm. Ces scripts sont exécutés sous root. Il serait bon que ses scripts ne soient autorisés que pour certaines signatures. Dans le même esprit, ses paquets ne pourraient pas installer de fichiers dans /etc/rc.d/ , etc, ni de fichier sid, etc.
Certes Yum a tendance à pester souvent. Mais c'est intentionnel, c'est pour des raisons de sécurité. Ce rapport n'a fait que survoler les problèmes de système de paquet et sous un angle bien classique...
[^] # Re: Modif de métadonnées
Posté par Étienne . Évalué à 2.
Ou alors le cracker rajoute une dépendance que tu n'as pas installée, dans une vieille version trouée et empêche ceux qui l'avaient de faire la mise à jour.
Je ne sais pas si c'est réaliste, mais il me semble que pour quelqu'un de motivé (qui veut se faire un petit réseau de zombies à revendre), il pourrait :
- monter un serveur avec une bonne connexion et une bonne bande passante
- proposer ses services à fedora (ou un autre) pour fournir un miroir
- faire un miroir de fedora
- avec le plugin de yum permettant de sélectionner automatiquement le miroir qui répond le plus vite, le cracker n'a même pas besoin de faire la pub de son miroir, les utilisateurs de fedora qui sont proche de lui vont automatiquement l'utiliser
- lorsqu'un outil peu déployé voit une mise à jour de sécurité, il peut modifier les métadonnées par rapport au dépôt officiel pour faire installer le paquet dans la version trouée en tant que dépendance d'un paquet installé chez tout le monde (par exemple en dépendance de coreutils).
- ceux qui n'avaient pas ce paquet installé l'installent dans une version trouée
- pour ceux qui l'avaient déjà ils ne voient même pas qu'il y a une mise à jour à faire et gardent la version moisie
- en primer il se constitue automatiquement une liste des IP qui ont sa version vérolée
[^] # Re: Modif de métadonnées
Posté par genesis83 . Évalué à 1.
Comme tout les gestionnaires de paquets que je connais, d'où l'intérêt des epochs. C'est pour ça que quand l'auteur dit un paquet n'expire jamais, en pratique il expire à partir du moment où une révision supérieure du paquet est installée.
Maintenant le problème ne peut se poser que dans le cas d'une prise de contrôle au long cours d'un miroir. Une bonne pratique serait (je ne sais pas si c'est fait) que chaque distribution lance une vérification périodique de ses miroirs officiels, ce ne serait pas bien compliqué à mettre en oeuvre.
[^] # Re: Modif de métadonnées
Posté par IsNotGood . Évalué à 2.
Ce n'est pas le cas de smartrpm ni de apt (ou synaptic ?).
> d'où l'intérêt des epochs.
C'est un autre problème. On peut avoir une mise à jour qui diminue la version du logiciel si l'epoch est supérieur. Ça reste une mise à jour.
Afin ça ne peut pas être utilisé pour l'attaque donnée.
[^] # Re: Modif de métadonnées
Posté par genesis83 . Évalué à 1.
C'est vrai je viens de jeter un coup d'oeil, effectivement.
>> d'où l'intérêt des epochs.
> C'est un autre problème.
Ce n'est pas un autre problème. On peut avoir une mise à jour qui diminue la version, mais uniquement si c'est une mise à jour voulue.
C'était pour illustrer le fait que le scénario qui consiste à proposer un vieux paquet non sûr est impossible en pratique, en tout cas avec yum/urpmi.
[^] # Re: Modif de métadonnées
Posté par Thomas Douillard . Évalué à 2.
Connaissant la sensibilité et l'importance de cette interface dire que l'attaque est impossible est un tantinet exagéré.
Genre
* "ah ouais, nous on fait des solutions techniques bétons pour que l'utilisateur ne soit pas emmerdé. Théoriquement, c'est sans faille, prouvé et tout."
* "Comment ça l'utilisateur risque de pas se comporter comme on veut ? On l'emmerde l'utilisateur, c'est son problème la sécurité ! Nous on fait des solutions techniques"
* "Oui, parfaitement, pour que l'utilisateur ne soit pas emmerdé!"
Il y a comme une contradiction dans un sens ...
Sérieusement je crois que dans ce genre de cas il faudrait plutôt interdire la mise jour du paquet en question et lancer une alerte auprès du fournisseur de paquet. Un utilisateur lassé par les message de sécurité qui clique par réflexe ou sans lire le message, c'est pas vraiment rare comme situation.
[^] # Re: Modif de métadonnées
Posté par Enoch (site web personnel) . Évalué à 1.
C'est effectivement impossible est un peu exagéré ...
mais ce que je voulais dire surtout c'est
que dans ce cas précis (ajout d'un paquet modifié, et donc non-signé avec la clé de la distrib, en dépendance a un autre paquet) le système de sécurité par signature des paquets fonctionne ...
Après je ne dit pas que le système en question est parfait (même si ma formulation précédente peut le laisser penser ...).
Ces questions sont intéressantes et il y a effectivement pas mal de choses à faire pour améliorer les systèmes existants mais pour ce qui est de la non-signature des métadonnées, ça me semble pas si dangereux que ça.
Il reste le cas mentionné plus haut ou l'on peut forcer l'installation d'un ancien paquet signé comportant un faille de sécu connue ... mais dans ce cas le problème me semble plus en rapport avec le point précédent ("la signature cryptographique d'un paquet n'a pas de date d'expiration").
"Un utilisateur lassé par les message de sécurité qui clique par réflexe ou sans lire le message, c'est pas vraiment rare comme situation."
C'est ce que j'indiquais par "bug au niveau de l'interface chaise-clavier" ...
Mais je ne pense pas que ce soit au système de paquetage d'empêcher un utilisateur d'installer un paquet non signé.
Il me semble que c'est quand même à la charge de l'utilisateur/administrateur de faire un minimum attention à ce qu'il fait sur son système ...
Surtout que dans certains cas ça peut être utile de pouvoir forcer ce genre d'action (je pense notamment à certains pilotes fournis sur CD en rpm avec du matos serveur qui n'est pas forcément signé).
Donc je ne suis pas sûr que de bloquer complètement ce genre d'actions soit une solution (bon là il n'est plus vraiment question de mise à jour ... donc pas forcément contradictoire avec ce que tu dis)
"* "ah ouais, nous on fait des solutions techniques bétons pour que l'utilisateur ne soit pas emmerdé. Théoriquement, c'est sans faille, prouvé et tout."
* "Comment ça l'utilisateur risque de pas se comporter comme on veut ? On l'emmerde l'utilisateur, c'est son problème la sécurité ! Nous on fait des solutions techniques"
* "Oui, parfaitement, pour que l'utilisateur ne soit pas emmerdé!"
Il y a comme une contradiction dans un sens ..."
Pour moi le système de signature des paquet sert surtout à certifier que le paquet que l'on installe n'a pas été modifié pour rajouter un rootkit, trojan ou autre. C'est pas spécialement conçut pour rendre le système de paquet plus user-friendly mais pour le sécuriser.
[^] # Re: Modif de métadonnées
Posté par Thomas Douillard . Évalué à 4.
Oui et non, la sécurité c'est l'affaire de tous, une machine compromise a un pouvoir de nuisance qui dépasse largement la machine elle même.
Surtout quand on parle de ce type d'attaque : celui qui la lance espère le faire à grande échelle et compromettre un certain nombre de machines.
Dans ce cas, il vaut mieux amha faire en sorte de compliquer un tantinet la tâche du mec qui veut forcer l'installation du paquet, histoire de soi le décourager si il sait pas ce qu'il fait, le forcer à se renseigner, voir si il sait vraiment ce qu'il fait ...
Si tu veux assurer la sécurité de ta machine perso ça peut marcher, maisça ne marche qu'avec des utilisateurs un tantinets avertis et qui s'intéressent au sujet. Les autres risquent d'ignorer cet ennuyeux message d'erreur, ou avoir peur. Mais la sécurité, surtout du point de vue d'une distribution, c'est largement plus que ta machine perso ou le serveur de ta boîte. Et ça peut toucher aussi l'utilisateur non averti, qui n'a pas forcément que des mauvaises raisons de ne rien y connaître.
Pour le reste, il est évident que les signatures de paquets ça ne vaut que si tu fais confiance à la source de la signature des paquets ... dans le cas de la distribution ça veut juste dire "oui oui, c'est bien nous qui mettons ces mises à jour à dispo" (ou c'est censé). Donc la signature permet d'éviter que d'autres se fassent passer pour les fournisseurs officiels, pour des paquets ne venant pas d'eux officiellement t'as pas forcément de raisons de forcer la signature, ils n'essayent pas de frauder. Et même si ils signaient les paquets, ils peuvent signer des paquets compromis, tu dois donc leur faire confiance, et vérifier la signature pour éviter que d'autres ne fassent passer de faux paquets comme venant d'eux ...
Le blocage de l'installation, ce n'est vraiment intéressant qu'en cas de détection de fraude potentielle, bien sûr.
# Coool
Posté par tuXico . Évalué à -1.
Du coup, entre l'étude et la relativisation par les mouleurs, on pourra se faire un meilleur avis (plus nuancés que ceux des fans boys) !
# Évidence ?
Posté par Thomas Douillard . Évalué à 1.
Pas si naïve et évidentes que ça, les approches "traditionnelles" pour les vérifications de téléchargements vont pas beaucoup plus loins que le md5sum ou des signatures cryptographiques pour "authentifier" le fournisseur. Approches qui ont été transposées dans les gestionnaires de paquets.
Si tu veux aller plus loin, sécuriser l'accès à la distrib quand tu as des mirroirs ou quand les machines "sources" sont compromises, c'est une autre paire de manche ...
[^] # Re: Évidence ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: Évidence ?
Posté par MrLapinot (site web personnel) . Évalué à 5.
# Autosatisfaction, quand tu nous tiens...
Posté par liberforce (site web personnel) . Évalué à 1.
Juste en termes de sécurité alors... Parce que va expliquer à un débutant qui cherche un paquet qui n'est pas fourni par sa distrib qu'il doit apprendre à utiliser un shell + compilateur + installation des paquets de développement + logiciel de gestion de versions si les bibliothèques livrées par sa distro sont trop anciennes... Va lui expliquer qu'il ne peut pas avoir la dernière version de Wesnoth si personne n'a fourni de backport, alors qu'il peut l'avoir en 3 clicks sous Windows...
Donc côté sécurité, pourquoi pas, mais pour le reste, il y a encore de sévères limitations...
[^] # Re: Autosatisfaction, quand tu nous tiens...
Posté par patrick_g (site web personnel) . Évalué à 8.
Certaines distros figent leur dépôt pour une release particulière (par exemple le dépôt de la version Hardy Heron que j'utilise) alors que d'autres distros sont en mode "rolling release" comme Arch et ont donc toutes les nouvelles versions qui deviennent vite disponibles.
La sévère limitation que tu évoques n'est donc pas la conséquence du modèle centralisé. C'est simplement un choix de développement qui est fait par certaines distros et pas par d'autres.
[^] # Re: Autosatisfaction, quand tu nous tiens...
Posté par liberforce (site web personnel) . Évalué à 1.
De plus, les distro les plus connues (Debian, Ubuntu, Mandriva, Fedora, openSuSE, etc.) fonctionnent toutes selon ce modèle, sans fonctionnement en "rolling release". Ce sont donc des problèmes que madame Michu rencontrera.
Le modèle centralisé, je suis tout à fait d'accord avec toi, a de nombreux avantages. Rien que le fait d'avoir toutes les mises à jour disponibles de manière centralisé est super. Mais il ne faut pas oublier qu'il a des limitations pour tout ce qui est de la fourniture d'applications tierces.
[^] # Re: Autosatisfaction, quand tu nous tiens...
Posté par Raphaël SurcouF (site web personnel) . Évalué à 3.
D'un côté le dépôt stable pour le système avec mises à jour de sécurité uniquement.
De l'autre, le dépôt des applications tierces, avec des mises à jour régulières.
Tout est dans la définition des dites applications tierces car il faudrait pouvoir s'assurer que la mise à jour d'une application ne rende pas le système moins stable pour autant.
[^] # Re: Autosatisfaction, quand tu nous tiens...
Posté par Metzgermeister . Évalué à 3.
Oops.
[^] # Re: Autosatisfaction, quand tu nous tiens...
Posté par Naha (site web personnel) . Évalué à 2.
Mes deux centimes.
[^] # Re: Autosatisfaction, quand tu nous tiens...
Posté par liberforce (site web personnel) . Évalué à 4.
Reçu par SMS cette semaine.
ce qui est merveilleux, fantastique et sensas ...c que l'ordi fonctionne! bon ok g pas encore trouvé la touche point et numéro page sinon c idem que sous windows merci encore pour le temps que tu as passé et à bientôt
Elle est passée de Windows à Mandriva Linux/GNOME (je ne lui ai pas laissé la vue spatiale pour ne pas la perdre) et de Word à OpenOffice. Pour une psychotique de l'informatique (elle en a une peur bleu mais en a besoin), je trouve ça pas mal.
Bref, madame michu elle joue pas à wesnoth, mais elle veut installer la dernière version de MSN, et je pense que là tu pourras difficilement me contredire.
[^] # Re: Autosatisfaction, quand tu nous tiens...
Posté par Plouffe . Évalué à 1.
Pas étonnant si tu lui as donné la traduction du BSOD...
[^] # Re: Autosatisfaction, quand tu nous tiens...
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 5.
Il suffit (oui j'utilise le "il suffit", parce que c'est pas compliqué) de fournir un autoinstall avec toutes les libraires en statique.
Ils le font bien pour Windows, pourquoi ne pas le faire pour Linux (pour les impatients ou joueurs en lignes)
[^] # Re: Autosatisfaction, quand tu nous tiens...
Posté par pasBill pasGates . Évalué à -1.
# Drôle...
Posté par Pierre Carrier . Évalué à 6.
- L'utilisation de Slackware et de Pacman doit être évité car ces gestionnaires ne aucun effort spécifique de sécurité.
Implique, sauf erreur de ma part :
L'utilisation d'OpenBSD doit être évité car son gestionnaire ne fait aucun effort spécifique de sécurité.
[^] # Re: Drôle...
Posté par tuXico . Évalué à 2.
# slaktool ???
Posté par boq . Évalué à 5.
Dommage qu'ils se soient complètement plantés de gestionnaire de paquetages pour Slackware.
Ça les a pas choqués de voir que slaktool n'avait pas été mis à jour depuis 2002 ou qu'il n'était pas dans la distribution.
Pareil pour tous les fichiers .asc placés à coté des paquets, ou encore les CHECKSUMS.md5 et CHECKSUMS.md5.asc, ça doit servir à faire joli. Faudra prévenir les gens de slackpkg d'arreter de les utiliser alors. La clé GPG qui signe les annonces de sécurité doit également être un fake. Faudrait que PV arrète de fournir les hashs des paquets à mettre à jour dans ces mêmes annonce aussi d'ailleurs, puisqu'on vous dit que slaktool ne cherche pas à être sécurisé.
Ou alors ils ont pas vu que ça existait parce qu'ils n'y ont même pas jeté un oeil.
J'ai peut-être loupé un truc, mais quel est l'intéret de citer une distro si ils ont fait aucune recherche dessus, surtout si c'est pour raconter n'importe quoi? Ok ils ont pas dit que Slackware était pas sécurisée, c'est juste ce que tout le monde a compris.
[^] # Re: slaktool ???
Posté par thedude . Évalué à 0.
Texto, l'article dit:
Ca me parait tres clair comme phrase, non?
Ou alors c'est que certains ici ne supportent pas qu'on dise que linux (ou leur distro preferee) a des points a ameliorer?
[^] # Re: slaktool ???
Posté par boq . Évalué à 2.
Qu'est ce que c'est que ce delire de slackware doit pas etre utilise?
Bien vu: c'est la question que je me suis posée. Comme ce n'était peu-être pas clair dans mon précédent message:
- l'article liste les gestionnaires de paquets utilisés par les distros
Here we’ll look at the most common package man-
agers and the distributions using them, which are,
generally:
...
Slaktool: used by Slackware
Que vient foutre Slaktool ici? Ce truc n'est pas intégré par défaut, et n'est pas maintenu depuis 2002. Alors que slackpkg est dans l'install de base.
Sur la FAQ de leur site web, ils indiquent bien le site de slaktool quand on leur demande quel gestionnaires de paquets ils ont examinés.
- Plus loin:
Some package managers don’t make any pretense of being secure in the first place (such as Slaktool on Slackware and Pacman on Arch Linux).
We strongly recommend against using package managers that don’t try to be secure
Quel est l'interêt de citer un truc obsolète, et de ne même pas évoquer slackpkg, inclut par défaut et qui essaie d'être sécurisé? C'est très bien de conseiller de ne pas utiliser slaktool, probablement personne ne l'utilisait de toute façon alors ...
- ici même (et sûrement à plein d'autres endroits):
L'utilisation de Slackware et de Pacman doit être évité car ces gestionnaires ne aucun effort spécifique de sécurité.
Peut-être est-ce un complot de patrick_g et/ou de lwn? Où peut-être l'article a pu l'induire en erreur? Voir même c'est juste une faute d'inatention qui sait? N'empêche, c'est écrit noir sur gris clair. Et donc non, il y a des efforts de faits sur la sécurité, comme indiqué dans le message précédent.
Ca me parait tres clair comme phrase, non?
Content que tu n'aie pas douté une seule seconde. Moi ça m'a pris le temps d'une recherche sur google.
Ou alors c'est que certains ici ne supportent pas qu'on dise que linux (ou leur distro preferee) a des points a ameliorer?
Rien a voir avec la choucroute. Des défauts y'en as déjà suffisament, pas besoin d'en inventer. Et je comprend pas ce que tu veux dire par 'linux'. Je suppose que ce n'est pas le kernel seul mais j'ai du mal a cerner ce que tu englobe.
[^] # Re: slaktool ???
Posté par patrick_g (site web personnel) . Évalué à 3.
Faute d'inattention de ma part. J'aurai du écrire "L'utilisation de Slaktool et de Pacman doit être évité".
[^] # Re: slaktool ???
Posté par BAud (site web personnel) . Évalué à 2.
Àmha, faute admise à moitié pardonnée (fais gaffe au chauve quand même :D).
[^] # Re: slaktool ???
Posté par Kerro . Évalué à 0.
CHECKSUMS.md5 et CHECKSUMS.md5.ascCe ne sont pas des signatures, ce sont juste des sommes de contrôle.
Si on souhaite corrompre un paquet il suffit de recalculer sa somme de contrôle et tout est parfait. Ce qui n'est pas possible avec une signature (sauf si on possède la clef privée).
[^] # Re: slaktool ???
Posté par boq . Évalué à 3.
# En ce moment sur OpenBSD
Posté par Romeo . Évalué à 2.
From: Marc Espie <espie@cvs.openbsd.org>
initial implementation of package signatures, based on x509 certificates and
smime detached signatures.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.