> 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.
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 IsNotGood . En réponse au journal La sécurité des gestionnaires de paquets. É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...