CVE noyau Linux : stratégie de live patching pour hébergement mutualisé

Table des matières :

1. CVE noyau Linux en mutualisé : le vrai problème, c’est le voisinage
2. Triage : passer de « CVSS » à une priorité exploitable en prod
3. Live patching (KLP) : définition technique et modèle de cohérence
4. Choisir une implémentation : kpatch, KGraft, Livepatch Canonical, Ksplice
5. Stratégie de déploiement live patching sur une ferme mutualisée (sans fantasmes)
6. Limites : quand le live patching ne suffit pas (et comment éviter la dette)
7. Prouver la remédiation : inventaire, traçabilité, et signaux côté boutique

CVE noyau Linux en mutualisé : le vrai problème, c’est le voisinage

Sur un hébergement mutualisé, une CVE du noyau Linux n’est pas « juste » un correctif à appliquer lors de la prochaine maintenance. C’est un risque systémique : un seul kernel est partagé par des centaines (parfois des milliers) de sites, et donc par des workloads hétérogènes (PHP-FPM, cron, workers, agents de backup, antimalware, etc.). Une exploitation réussie (souvent une élévation de privilèges locale) peut transformer une compromission applicative isolée en compromission de l’hôte, puis en pivot inter‑tenant.

Le pattern typique en e‑commerce : un site PrestaShop/WooCommerce est compromis via un module vulnérable, un compte FTP/SFTP volé ou une injection (webshell). À partir de là, l’attaquant a une présence locale (même sans shell interactif au début). Les CVE kernel exploitables par un utilisateur non privilégié (user namespaces, eBPF, io_uring, netfilter, overlayfs…) redeviennent pertinentes : « local » ne veut pas dire « inoffensif », surtout quand votre isolation est faite de chroot, de permissions, ou de conteneurs sans durcissement.

Ce qui rend le mutualisé spécifique, c’est le voisinage :

• Hétérogénéité des tenants : certains sites sont “propres”, d’autres traînent des plugins/modules obsolètes. Votre risque global ressemble au minimum commun de sécurité, pas à la moyenne.
• Densité : sur un nœud chargé, une dégradation kernel (soft lockup, contention I/O, bug dans le réseau) devient un incident client multiplié par N boutiques.
• Surface “local” involontaire : même si vous ne “donnez pas de shell”, des chemins d’exécution existent (interpréteurs, tâches cron, handlers, scripts d’optimisation d’images, extract d’archives) qui peuvent suffire à déclencher un exploit LPE dans certains scénarios.

Le cœur du sujet est opérationnel : sur du mutualisé, redémarrer le serveur à chaud pour corriger un kernel peut être plus coûteux que la vulnérabilité elle‑même (impact business, files d’attente, sessions perdues, timeouts). Côté boutique, ça se matérialise en erreurs transitoires et en pics de 503, et c’est exactement le genre de symptôme que vous finissez par investiguer côté stack web/PHP (voir le guide interne sur les erreurs HTTP 503 et le diagnostic via logs Apache/LiteSpeed).

Le live patching existe pour réduire la fenêtre de risque sans transformer chaque correctif noyau en opération “nuit blanche”. Mais il ne remplace ni la discipline de patch management, ni une isolation solide (cgroups, namespaces maîtrisés, restrictions sysctl, LSM type SELinux/AppArmor, etc.).

Triage : passer de « CVSS » à une priorité exploitable en prod

Sur une ferme mutualisée, vous ne pouvez pas traiter toutes les CVE noyau avec la même urgence. La CVSS (et même EPSS) est un signal, pas une stratégie. Le triage utile est : exposition × exploitabilité × blast radius. Exemple concret : une CVE « local privilege escalation » critique prend une priorité élevée si vous autorisez des shells, des builds, ou des conteneurs avec capabilities ; elle peut rester moyenne si vos tenants n’ont aucun exécutable custom, aucune user namespace, et que vous avez un confinement strict (mais il faut pouvoir le prouver).

Pour rendre la décision reproductible (et auditable), utilisez une grille simple, orientée mutualisé :

Facteur	Questions à trancher (preuve attendue)	Effet sur la priorité
Exposition	La fonctionnalité est-elle activée ? (config kernel + sysctl + modules chargés)	Exposition forte → priorité ↑
Chemin d’attaque	Un tenant peut-il exécuter du code “suffisant” ? (upload + interpréteur, cron, extraction d’archives, binaires)	Chemin simple → priorité ↑
Exploitabilité	Exploit public ? Complexité faible ? Conditions rares ?	Exploit public + conditions communes → priorité ↑
Blast radius	Compromission = root sur hôte ? accès aux autres tenants ? secrets (backup, agents) ?	Blast radius élevé → priorité ↑
Mitigations en place	userns/bpf restreints, LSM, seccomp, conteneurs durcis, monitoring d’IOC	Mitigation vérifiable → priorité ↓ (temporairement)

Pour sortir du ressenti, imposez un SLO de remédiation par classe de vulnérabilité. Un modèle réaliste pour le mutualisé :

• P0 (0–24 h) : RCE kernel/remote reachable, exploitation active confirmée (par exemple via le catalogue KEV de la CISA), ou LPE avec exploit public + forte exposition (shells, userns, eBPF).
  Lien utile pour objectiver “exploitation active” : Known Exploited Vulnerabilities (CISA)
• P1 (0–7 j) : LPE critique sans exploitation active, ou DoS kernel qui peut planter l’hôte (panic, OOM systémique, soft lockup), ou vulnérabilité permettant un contournement de confinement.
• P2 (≤ 30 j) : CVE non triviale, conditions rares, ou mitigations fortes déjà en place (documentées + mesurées).

Le live patching devient intéressant dès que votre contrainte n’est pas « appliquer vite », mais « appliquer vite sans reboot ». Un patch kernel classique implique drain/maintenance, interruption réseau, bascule de service, et aléas (fsck, RAID resync, reboot qui pend…). Le live patching réduit la dépendance au reboot, ce qui améliore votre MTTR sécurité sans exploser votre SLO disponibilité.

Enfin, ne confondez pas « corriger le kernel » et « réduire le risque immédiat ». Quand un correctif livepatch n’est pas disponible (ou pas applicable), les mitigations kernel (sysctl, désactivation de features, restriction d’user namespaces, durcissement BPF) sont une couche temporaire. Elle doit être documentée, testée, et suivie, sinon ça se transforme en dette de sécurité.

Checklist rapide “mitigation immédiate” (utile en P0/P1 quand le patch live n’est pas encore là) :

• Restreindre user namespaces si votre modèle le permet (kernel.unprivileged_userns_clone=0 sur certaines distros).
• Restreindre BPF non privilégié (kernel.unprivileged_bpf_disabled=1 quand compatible avec votre tooling).
• Vérifier les modules sensibles chargés (ex. netfilter, overlayfs, io_uring selon le cas) et l’intérêt de les désactiver temporairement (attention aux impacts).
• Renforcer la détection : alertes sur dmesg (WARN, BUG, soft lockup), escalades de privilèges atypiques, changements sur /proc/sys/.

Live patching (KLP) : définition technique et modèle de cohérence

Le live patching du noyau Linux repose sur le framework Kernel Livepatch (KLP) intégré upstream. L’idée n’est pas magique : on charge un module de patch qui redirige certaines fonctions vers une version corrigée, en s’appuyant sur des mécanismes de redirection et une orchestration pour basculer les tâches dans un état cohérent.

« Livepatch provides a mechanism to patch the running kernel without rebooting. » — Documentation du noyau Linux, Livepatch : docs.kernel.org/livepatch

Le point que beaucoup ratent : on ne « remplace » pas le noyau entier. On remplace un ensemble de symboles/fonctions (souvent des chemins critiques) avec des contraintes strictes : pas de modifications massives de structures de données sans stratégie de transition, pas de changement d’ABI arbitraire, et gestion du consistency model (quand et comment les threads passent sur le code patché).

En pratique, deux notions sont clés côté exploitation :

• Sélection du périmètre : un livepatch cible généralement des fonctions précises (ex. une fonction de validation d’entrées, un check de bounds, un cas de use-after-free). C’est idéal pour beaucoup de vulnérabilités “classiques”, moins pour des refontes.
• Cohérence d’exécution : l’infra livepatch doit garantir qu’au moment du basculement, aucune tâche ne se retrouve dans un état incohérent (par exemple en exécutant une ancienne fonction avec de nouvelles hypothèses). Le noyau propose des mécanismes pour orchestrer ces transitions (quiesce/stop-the-world ponctuel, bascules contrôlées, etc. selon implémentation et cas).

Conséquence directe en mutualisé : vous devez surveiller plus que “patch appliqué”. Sur un nœud chargé, la différence entre “patch OK” et “patch OK + léger impact scheduler” est la différence entre zéro ticket et une vague de plaintes sur la lenteur en back-office.

Enfin, notez la contrainte fondamentale : un livepatch est lié à un kernel build (version + configuration + symboles). Cela explique pourquoi les solutions “produit” (vendors) insistent sur des noyaux supportés et des environnements stables : ce n’est pas du marketing, c’est une contrainte technique.

Choisir une implémentation : kpatch, KGraft, Livepatch Canonical, Ksplice

Il existe deux réalités : le framework upstream (KLP) et les solutions « produit » qui livrent des patchs précompilés pour un kernel de distribution donné. Sur mutualisé, vous cherchez une solution qui colle à votre distribution (RHEL/Alma/Rocky, Ubuntu, SUSE…) et à votre politique de support (SLA, cadence de patch, canary). Mélanger des kernels custom et du live patching “hors support” est un bon moyen de créer un incident de prod impossible à diagnostiquer.

Repères pragmatiques (et typiquement observés en exploitation chez des hébergeurs en France/UE) :

• RHEL-like : l’écosystème kpatch est courant quand on veut rester aligné sur les errata et le support vendor.
• SUSE : historique autour de KGraft / live patching intégré à l’offre enterprise.
• Ubuntu : Canonical Livepatch fournit des correctifs de sécurité kernel “sans reboot” pour des noyaux supportés (généralement LTS).

« Apply critical kernel security patches without rebooting. » — Canonical, Ubuntu Livepatch : ubuntu.com/security/livepatch

Ksplice (Oracle) existe aussi dans l’écosystème, mais l’enjeu reste identique : les patchs sont liés à un couple (kernel build, config, distro). En mutualisé, ce verrouillage est une feature : il garantit que les symboles attendus existent et que le patch a été validé pour votre build, ce qui est plus important que l’illusion de flexibilité.

Critères décisionnels concrets pour un hébergeur mutualisé :

• Couverture des kernels réellement utilisés (ex : Ubuntu LTS, RHEL-like) et durée de support.
• Latence de publication des livepatchs sur les CVE critiques (et transparence sur ce qui est couvert / non couvert).
• Outils de gestion (API, CLI), capacité de canary, métriques, rollback.
• Modèle économique et contractualisation (support en cas de crash).
• Compatibilité avec votre “réalité mutualisée” : noyaux homogènes, modules additionnels, agents de sécurité, éventuels DKMS.

Astuce terrain : si vous opérez plusieurs gammes (mutualisé “standard”, mutualisé “premium”, serveurs dédiés infogérés), évitez de multiplier les solutions livepatch. Chaque solution ajoute une matrice de compatibilité et un runbook spécifique ; la simplicité opérationnelle est un facteur de sécurité.

Stratégie de déploiement live patching sur une ferme mutualisée (sans fantasmes)

Pré‑requis non négociables : accès console hors bande (IPMI/iDRAC), snapshots/backup cohérents, et un environnement de staging reproduisant la config kernel (mêmes paquets, même config, mêmes modules DKMS si vous en avez). Un livepatch reste du code kernel chargé à chaud : si vous n’avez pas de plan de rollback et d’observabilité, vous remplacez un risque (CVE) par un autre (panic ou soft lockup en prod).

Le runbook minimal ressemble à ça : inventorier, canary, rollout, vérifier, tracer. Exemples de commandes (à adapter selon distro/solution) :

uname -r
cat /etc/os-release
# inventaire des sysctl « à risque » selon votre modèle de menace
sysctl kernel.unprivileged_bpf_disabled
sysctl kernel.unprivileged_userns_clone

Ajoutez systématiquement une vérification livepatch au runbook (sinon vous ne savez pas “ce qui est réellement appliqué” au moment d’un audit) :

• Sur Ubuntu Livepatch :

canonical-livepatch status

• Sur des environnements kpatch, on trouve typiquement une commande de type :

kpatch list

(le nom exact et le packaging dépendent de la distro et de la solution retenue)

Le point important n’est pas la syntaxe, mais la séquence et les garde-fous :

1) Canary : 1–5% des hôtes, choisis sur des profils variés (charges CPU, I/O, types de tenants, présence/absence de certains modules). 2) Observation : au moins 30–120 minutes (selon trafic) avec focus sur kernel logs (dmesg, journald), latences réseau, anomalies scheduler, softirq, et erreurs applicatives. 3) Rollout par vagues : 10–20% puis 50% puis 100%, avec arrêt automatique si un signal dépasse un seuil.

Mini-scenario réaliste (mutualisé e‑commerce) : vous avez 200 nœuds, chacun héberge 150–400 boutiques. Un reboot “propre” peut prendre 2–10 minutes (temps de drain, redémarrage, remontée des services, warm-up caches). Même si ce n’est “que quelques minutes”, l’effet est amplifié : pics de 5xx, paniers abandonnés, cron décalés, workers de mails/ERP en retard. Un livepatch réduit drastiquement la probabilité d’un impact visible client au moment le plus tendu (publication d’une CVE exploitée), tout en vous laissant planifier le reboot dans une fenêtre maîtrisée.

Côté supervision, l’objectif est de détecter les effets secondaires avant que les boutiques ne tombent. Sur ce point, un outil comme Netdata (cf. Netdata : intégrer Prometheus, SNMP et StatsD pour tout surveiller) permet de corréler un déploiement livepatch avec des variations de latence, de load average, de context switches ou de saturations réseau. Et côté applicatif, surveillez les 5xx (et pas seulement les 500) pour éviter de « découvrir » votre maintenance via une vague de réponses 503.

Signaux à surveiller spécifiquement pendant/juste après un livepatch (pratique sur mutualisé) :

• Kernel logs : BUG:, WARNING:, soft lockup, hung task, rcu_sched stalled.
• Réseau : latence et pertes, backlog, saturation softirq si vous avez des charges TLS/HTTP2 importantes.
• I/O : latence disque, iowait, timeouts stockage (même si “ça n’a rien à voir” en apparence).
• Applicatif : TTFB, taux de 5xx, saturation PHP-FPM, files d’attente (jobs, mails), erreurs DB transitoires.

Pour industrialiser, traitez le live patching comme du déploiement : versionner la config, automatiser les vagues, et décrire l’infra. Un pipeline IaC (Terraform/Ansible) permet aussi une stratégie de remplacement (blue/green) quand le livepatch n’est pas possible ou quand vous devez rebooter proprement (voir DevOps : Infrastructure as Code avec Terraform et conteneurs).

Point “GEO” utile (sans sur-vendre) : en France/UE, la pression client/audit (PCI DSS, exigences donneurs d’ordre, clauses contractuelles, et montée en maturité cyber liée aux directives type NIS2) pousse vers des preuves de remédiation plus rapides et plus traçables. Le live patching n’est pas la seule réponse, mais c’est un levier concret pour concilier sécurité et continuité de service.

Limites : quand le live patching ne suffit pas (et comment éviter la dette)

Le live patching ne corrige pas tout, et il ne doit pas devenir une excuse pour ne plus redémarrer. Premier cas classique : correctifs nécessitant une réinitialisation ou un changement impossible à appliquer à chaud (microcode CPU, certains drivers, modifications profondes du modèle mémoire). Deuxième cas : correctifs qui touchent des structures largement partagées où l’état en mémoire doit migrer ; c’est faisable mais coûteux et rarement livré en livepatch « standard ».

Troisième limite : la dette de patch. Empiler des livepatchs pendant des mois sans reboot peut devenir un cauchemar (interactions, complexité du support, effets sur le debug). Les vendors le rappellent implicitement via leurs modèles : le livepatch sert à vous laisser choisir quand rebooter, pas à supprimer le reboot.

En mutualisé, une politique saine est : livepatch immédiat + reboot planifié dans une fenêtre maîtrisée, avec bascule des tenants.

• P0 : livepatch dès publication (si disponible) + reboot planifié sous 7–30 jours (selon contraintes business).
• P1 : livepatch si disponible + reboot dans la prochaine fenêtre mensuelle.
• P2 : regrouper au reboot trimestriel, tant que les mitigations restent valides.

Quatrième limite, très terrain : vos modules kernel hors distro (DKMS, drivers propriétaires, agents de sécurité) peuvent casser l’équation. Si vous utilisez du DKMS, testez explicitement la compatibilité avec votre solution de livepatch et gardez une matrice kernel × module. Si vous hébergez des boutiques critiques (PrestaShop, ERP connectés, etc.), documentez aussi l’impact d’un reboot (sessions, jobs cron, files d’attente) et mettez en place du drain applicatif.

C’est la logique déjà décrite dans une approche d’hébergement PrestaShop géré : migration sans coupure, staging et maintenance, mais appliquée au kernel : même si vous “évitez le reboot” aujourd’hui, vous devez savoir rebooter proprement demain.

Prouver la remédiation : inventaire, traçabilité, et signaux côté boutique

Sur mutualisé, vous aurez tôt ou tard une demande de preuve : client enterprise, assurance, audit PCI, ou incident response. Un « on a patché » ne suffit pas. Gardez un inventaire horodaté : version du kernel, identifiant(s) du livepatch appliqué(s), date d’application, hôte, résultat de vérification. Centralisez les états (CMDB ou au moins un dépôt Git + export automatique) et conservez les logs de déploiement.

D’un point de vue technique, le minimum est de pouvoir répondre à :

• Quels hôtes étaient vulnérables à T0 (kernel version + exposition + présence de mitigation).
• Quels hôtes ont reçu un livepatch à T1 (ID patch, état “appliqué”, résultat).
• Quels hôtes ont redémarré à T2 (preuve du reboot + kernel “full patched”).
• Quels workloads étaient dessus (cartographie tenants/services → hôtes), pour mesurer le blast radius et prévenir.

Ajoutez un volet “preuve côté service”, particulièrement utile en mutualisé où les clients vivent la sécurité via la disponibilité :

• Courbes avant/après : taux de 5xx, latence (TTFB), saturation PHP-FPM, erreurs base de données.
• Corrélation temporelle : événement de déploiement livepatch ↔ variation d’indicateurs.
• Tickets/incidents : qualification “déploiement sécurité” vs “incident applicatif” (évite les diagnostics en boucle).

Enfin, n’ignorez pas la couche applicative : un livepatch qui se passe « bien » côté kernel peut quand même dégrader un service (latence réseau, scheduling, I/O). Mesurez vos SLI côté web (TTFB, 5xx, saturation PHP-FPM) et reliez-les à vos événements infra. Pour les stacks e‑commerce auto‑hébergées, les checklists de maintenance et de sécurité restent pertinentes même si le kernel est livepatché (voir PrestaShop auto‑hébergé : prérequis d’installation, maintenance et sécurité). La sécurité kernel est une couche ; la surface d’attaque, elle, traverse toute la chaîne.