Rétro-portage des correctifs de sécurité
Le rétro-portage est une méthode d'application des mises à jour logicielles importantes de sécurité.
Nous utilisons l'expression rétro-portage pour décrire le procédé par lequel nous prenons le correctif d'un défaut de sécurité de la version la plus récente d'un paquetage logiciel amont et l'appliquons pour corriger une ancienne version du paquetage que nous distribuons.
Le rétro-portage est courant chez les fournisseurs comme Red Hat et garantit le déploiement de mises à jour automatiques aux clients avec un minimum de risque. Il s'agit d'un concept nouveau pour ceux qui sont plutôt habitués aux mises à jour logicielles privées.
Voici un exemple de la raison pour laquelle nous effectuons le rétro-portage des correctifs de sécurité :
Red Hat a envoyé la version 2.0.40 du serveur Apache HTTP Server avec Red Hat Linux 8.0. Peu après sa commercialisation, l'Apache Software Foundation a trouvé et divulgué quelques problèmes de sécurité. Cette entreprise a publié une nouvelle version, Apache HTTP Server 2.0.43, contenant les correctifs pour ces problèmes. Toutefois, d'autres changements (correctifs de bogues et nouvelles fonctions), en plus de correctifs de sécurité, ont été effectués entre les versions 2.0.40 et 2.0.43.
Une de ces fonctions a modifié l'interface du module. Dans ce cas, si Red Hat avait publié une mise à jour de sécurité avec la version 2.0.43 d'Apache HTTP Server qui remplace la version 2.0.40, il aurait fallu mettre à jour (recompiler) tous les modules utilisés par les clients pour les adapter à la nouvelle interface du module. Les clients qui utilisaient les modules d'autres fournisseurs auraient dû obtenir des mises à jour pour ces modules auprès de ces fournisseurs. Les administrateurs de système devraient effectuer manuellement le transfert de la version 2.0.40 à la version 2.0.43 d'Apache HTTP Server. Cette mise à jour ne conviendrait pas pour les systèmes à mise à jour automatique comme Red Hat Network.
Dans de tels cas, nous pouvons rétro-porter les mises à jour. Lorsque nous utilisons cette méthode pour les correctifs de sécurité, nous :
- identifions les correctifs et les isolons des autres modifications,
- vérifions que les correctifs n'engendrent pas d'effets secondaires indésirables,
- appliquons les correctifs à nos versions précédentes.
Pour la plupart des produits, notre politique par défaut est de rétro-porter les correctifs de sécurité, mais il nous arrive de publier des mises à jour pour certaines versions de paquetages, après avoir effectué des tests et des analyses approfondis. Cela concerne généralement des paquetages n'ayant aucune interaction avec d'autres ou ceux servant aux utilisateurs finals comme les navigateurs Web et les clients de messagerie instantanée.
Quelques mots sur le numérotage des versions
Le rétro-portage présente un certain nombre d'avantages pour les clients mais il peut porter à confusion s'il n'est pas compris. Les clients doivent savoir que le numéro de version d'un paquetage ne suffit pas pour savoir si vous êtes vulnérable ou non. Par exemple, la presse peut utiliser des phrases comme « passez à la version Apache httpd 2.0.43 pour corriger le problème », qui ne mentionnent que le numéro de la version en amont. Ceci peut porter à confusion, car même après avoir installé les paquetages mis à jour d'un fournisseur, vous n'aurez probablement pas la dernière version en amont, mais plutôt une ancienne version en amont modifiée par le rétro-portage de correctifs.
En outre, certains outils d'analyse et antivirus prennent des décisions quant aux vulnérabilités sur la seule base du numéro de version des composants qu'ils trouvent. Il en résulte des faux positifs, car les outils ne prennent pas en compte le rétro-portage des correctifs de sécurité appliqués.
Depuis la sortie de Red Hat Enterprise Linux, nous prenons soin d'expliquer si nous corrigeons un problème particulier en passant à une nouvelle version en amont ou par rétro-portage de correctifs appliqués à la version actuelle. Depuis janvier 2000, les noms CVE accompagnent toutes nos alertes. Les clients peuvent ainsi se référer aux vulnérabilités pour vérifier de quelle façon et à quel moment nous les avons corrigées, indépendamment des numéros de version.
Nous fournissons également les définitions OVAL (versions de nos alertes exploitables par l'ordinateur) que les outils d'autres fournisseurs peuvent utiliser pour déterminer l'état des vulnérabilités, même lorsque le rétro-portage des correctifs de sécurité a été effectué. Ce faisant, nous espérons atténuer la confusion quant au rétro-portage et faciliter le maintien de la sécurité des clients.