ClickCease Les nombreux visages du rapiéçage

Table des matières

Rejoignez notre populaire bulletin d'information

Rejoignez 4 500+ professionnels de Linux et de l'Open Source !

2 fois par mois. Pas de spam.

Les nombreux visages du rapiéçage

Joao Correia

28 novembre 2022 - Évangéliste technique

La mise à jour de vos systèmes peut se faire de différentes manières, chacune ayant ses avantages et ses inconvénients. Certaines méthodes dites de "correction" ne sont même pas des corrections. Voici un guide unique pour vous aider à comprendre les différentes offres de correctifs disponibles.

La mise à jour est à la fois un processus informatique et une pratique de sécurité fondamentale. Il est généralement décrit comme le processus consistant à corriger des problèmes ou à ajouter des fonctionnalités à un système donné en ajoutant ou en remplaçant des composants existants par des composants mis à jour. Cela peut se faire à différents niveaux, par exemple en mettant à jour le code au niveau des sous-systèmes, des dépendances ou des fonctionnalités de base. De même, vous pouvez appliquer des correctifs à des applications spécifiques, à des systèmes d'exploitation, à des pilotes ou à tout autre composant.

Si l'objectif est toujours de disposer d'une version plus à jour de ce qui est corrigé, c'est la manière dont vous vous y prenez pour y parvenir qui fait la différence entre les différentes approches de correction. 

Comme d'autres termes de l'informatique, tels que le débogage, le patching est issu d'un processus physique. Il s'agissait de recouvrir les trous des cartes perforées, c'est-à-dire de "patcher" une section du code. Ce procédé semble être passé de mode, c'est pourquoi nous allons aborder les approches les plus modernes.

Rattrapage traditionnel

C'est ce que la plupart des gens reconnaissent sous le nom de "patching". Elle consiste à télécharger les versions mises à jour d'un logiciel donné, puis à remplacer les fichiers correspondants sur le disque par les nouvelles versions.

Il est relativement simple à mettre en œuvre et sa compréhension est aisée : vous avez une ancienne version d'un logiciel donné qui est remplacée par une nouvelle version, entièrement ou partiellement. Vous devez redémarrer l'application ou le système pour récupérer la nouvelle version, mais il n'y a pas d'autres parties mobiles. Bien entendu, c'est là que réside le plus gros inconvénient : le redémarrage des applications ou des systèmes entiers est une opération lente qui perturbe considérablement la charge de travail en cours. Pour cette raison, cette opération ne peut pas être effectuée de manière ad hoc, et elle a généralement lieu dans ce que l'on appelle une "fenêtre de maintenance", c'est-à-dire une période de temps pré-approuvée pendant laquelle les systèmes sont censés présenter des problèmes de disponibilité ou de performance. 

Encore une fois, cette solution est lente à mettre en place et susceptible de dépasser les délais prévus en cas de problème.

Patching virtuel

Il s'agit d'un produit dont le nom contient le mot "patching" et qui, à première vue, semble fournir des résultats de patching, mais qui, en fait, fonctionne à un niveau complètement différent. Il n'y a pas de remplacement ou de correction de code réel qui a lieu avec le patching virtuel. Il consiste à mettre en œuvre une détection des menaces au niveau du pare-feu, en bloquant les modèles d'attaque connus. Du point de vue de l'attaquant, l'attaque échoue et il peut donc supposer que le système est corrigé alors qu'il ne l'est pas.

Cette méthode de "correction" présente plusieurs inconvénients : le code corrigé n'est à aucun moment introduit dans les systèmes, car la protection ne couvre que les schémas d'attaque connus - ce qui ignore immédiatement les problèmes locaux et peut être trompé par des modifications du trafic réseau correspondant à une menace donnée. 

Si les inconvénients ne disqualifient pas immédiatement cette méthode de "correction", les avantages sont les suivants : aucune perturbation (puisque rien n'est réellement fait à l'intérieur d'un système), un seul déploiement peut couvrir plusieurs systèmes (il s'agit en fait d'un processus modifié de pare-feu applicatif) et, lorsque de nouvelles menaces à distance sont ajoutées, il protège immédiatement les systèmes derrière lui.

Mise à jour du micrologiciel

La mise à jour d'un micrologiciel est un cas particulier de correction traditionnelle, avec la réserve supplémentaire que vous corrigez un code contenu dans un support de stockage généralement difficile à mettre à jour - directement dans une EPROM (mémoire morte programmable et effaçable). C'était la norme pour les premiers appareils intelligents et les appareils IoT de première génération. Le logiciel était chargé en usine et ne recevait que rarement - voire jamais - de mises à jour. Cela était dû en partie au fait que la mise à jour et la sécurité n'étaient pas des préoccupations primordiales comme aujourd'hui, mais aussi parce que la façon dont le logiciel était stocké rendait la mise à jour difficile. Sur les appareils plus récents, le code est écrit, en totalité ou en partie, sur des supports plus standard, comme les disques SSD, les cartes SD ou autres, qui sont beaucoup plus faciles à modifier.

Lorsque le code s'exécute sur des puces qui doivent être connectées à du matériel d'écriture spécialisé avec des exigences logicielles et des câbles propriétaires, cela ajoute une couche de complexité qui rend l'ensemble du processus très peu attrayant pour la plupart des équipes informatiques. En conséquence, ces appareils n'étaient tout simplement jamais mis à jour pendant toute leur durée de vie utile. Malheureusement, nombre d'entre eux existent encore - les serveurs d'impression, les caméras IP et les capteurs de centres de données sont tous de bons exemples de dispositifs fonctionnant de cette manière.

Live Patching

Le "live patching" est le processus qui consiste à modifier le code en cours d'exécution et à remplacer les sections ou les fonctions connues comme boguées par des versions corrigées de ces mêmes sections. Cette opération s'effectue entièrement en mémoire et ne nécessite pas le redémarrage de l'application pour que les nouvelles modifications soient prises en compte. À un moment donné, le logiciel contient un bogue dans une fonction et le moment suivant, une version corrigée de cette fonction est utilisée à la place. 

Il n'y a ni redémarrage, ni redémarrage, ni perturbation. De ce fait, les correctifs peuvent être déployés immédiatement, car l'opération ne nécessite pas de fenêtre de maintenance, ce qui permet de réagir plus rapidement aux menaces émergentes. Plutôt que d'attendre des semaines ou des mois avant de déployer un correctif, comme c'est le cas avec les correctifs traditionnels, cela peut maintenant se faire dans les heures, voire les minutes, suivant la disponibilité d'un correctif.

La complexité supplémentaire du "live patching" se produit au moment de la création du patch. Le patch doit être créé de manière à pouvoir être chargé dans le bon espace mémoire en utilisant les mêmes tailles et alignements de variables que le code original. Cette complexité est cachée aux utilisateurs d'une solution de "live patching", car elle n'est visible que pour le fournisseur du "live patch".

Cela fait maintenant plus de 10 ans qu'un sous-système de correctifs en direct est capable de déployer des correctifs à l'intérieur du noyau Linux, et de multiples solutions différentes ont été créées. KernelCare Enterprise est un exemple d'une telle solution, et peut patcher en direct le noyau Linux, les bibliothèques système critiques, les bases de données, et même les hyperviseurs.

Il existe de nombreuses variantes du "live patching", notamment temporaire et permanent. Il s'agit de la manière dont le processus de "live patching" est mis en œuvre - soit comme une solution provisoire, soit comme une alternative plus permanente au patching traditionnel.

Conclusion

Vous pouvez trouver des informations comparatives sur patching en direct vs patching virtuel iciet la différence entre le live patching permanent et temporaire ici.

Il existe de nombreuses façons d'aborder la question des correctifs. Pour toute organisation qui se préoccupe, ne serait-ce qu'un peu, de la sécurité de ses systèmes, de ses données et de ses utilisateurs, l'application de correctifs est l'une des préoccupations fondamentales qui doit être abordée aux niveaux stratégique et opérationnel. Chaque environnement a ses propres particularités, alors assurez-vous de choisir le bon processus pour votre situation spécifique. 

Résumé
Les nombreux visages du rapiéçage
Nom de l'article
Les nombreux visages du rapiéçage
Description
La mise à jour de vos systèmes peut s'effectuer de différentes manières. Lisez ce guide unique pour comprendre les différentes offres de correctifs disponibles.
Auteur
Nom de l'éditeur
TuxCare
Logo de l'éditeur

Vous cherchez à automatiser la correction des vulnérabilités sans redémarrage du noyau, temps d'arrêt du système ou fenêtres de maintenance programmées ?

Découvrez le Live Patching avec TuxCare

Devenez rédacteur invité de TuxCare

Commencer

Courrier

Rejoindre

4,500

Professionnels de Linux et de l'Open Source
!

S'abonner à
notre lettre d'information