Il y a trois choses dont vous pouvez être sûr dans la vie : la mort, les impôts – et les nouveaux CVE. Pour les organisations qui s’appuient sur CentOS 8, l’inévitable s’est maintenant produit, et cela n’a pas pris longtemps. À peine deux semaines après avoir atteint la fin de vie officielle, quelque chose s’est cassé de façon spectaculaire, laissant Cent OS 8 les utilisateurs exposés à un risque majeur d’attaque grave – et sans le soutien de CentOS.

On pourrait penser que ce problème n’affecte plus un nombre important d’organisations, car à ce jour, les entreprises auraient migré de CentOS 8 vers un système d’exploitation activement pris en charge par les fournisseurs. Après tout, le support des fournisseurs est essentiel pour la sécurité et la conformité.

Mais comme c’est toujours le cas avec ces choses, vous pouvez compter sur le fait qu’un grand nombre d’utilisateurs de CentOS 8 continuent avec un système d’exploitation non pris en charge, bien qu’ils soient conscients des risques. Avec ce risque qui se cristallise maintenant, nous utilisons cet article pour examiner CVE-2021-4122la vulnérabilité récemment découverte dans le chiffrement LUKS, et pour discuter de vos options pour l’atténuer.

Attendez, qu’est-ce que LUKS ?

Donc qu’est-ce LUKS? LUKS signifie Linux Unified Key Setup et est un mécanisme utilisé dans les systèmes Linux pour prendre en charge, entre autres, le chiffrement complet du disque. Il est recommandé dans de nombreux guides de « meilleures pratiques » en tant qu’option essentielle de renforcement du système pour les équipes informatiques soucieuses de la sécurité.

Comment fonctionne LUKS ? Eh bien, lors du déploiement du système, vous pouvez créer une partition uniquement lisible – c’est-à-dire que les données qu’elle contient ne sont compréhensibles qu’avec un mot de passe fourni par l’utilisateur. LUKS est assez complexe et de nombreux systèmes de sécurité interagissent avec LUKS, mais un guide LUKS complet n’est pas l’objectif de cet article.

Le fait d’avoir un disque entièrement crypté (dispositif de bloc dans Linux « speak ») garantit que les données sont à l’abri des regards indiscrets même lorsqu’elles sont au repos, ce qui signifie qu’un attaquant qui vole un ordinateur portable, par exemple, est toujours incapable de voir les données confidentielles contenues dans ce.

Vous pouvez renforcer la sécurité en liant un périphérique de bloc spécifique à un ordinateur spécifique via TPM (Trusted Platform Module). Cela ajoute un autre obstacle pour un attaquant, ce qui rend plus difficile l’extraction physique des données chiffrées d’une machine et leur connexion à un système hautes performances dans le but de forcer brutalement l’accès aux données. Cependant, comme toujours, la probabilité de réussite dépend de la puissance de calcul, de l’algorithme de cryptage sélectionné et de la chance.

Dans l’ensemble, LUKS offre une excellente protection et pour cette raison, il est souvent utilisé pour sécuriser les systèmes dans diverses organisations.

Comprendre la faille LUKS

CVE-2021-4122 a été attribué à la fin de l’année dernière, mais une compréhension complète des risques de sécurité autour de LUKS n’est apparue que récemment. Il s’avère qu’il est possible, au moins partiellement, de déchiffrer un disque chiffré par LUKS et d’accéder aux données qu’il contient sans posséder le mot de passe utilisé pour configurer le chiffrement.

Une fonctionnalité clé de LUKS est la possibilité de changer, à la volée, la clé utilisée pour chiffrer un appareil donné. Vous feriez cela, par exemple, pour les rotations de clés planifiées dans des environnements à haute sécurité.

Cette fonction de rechiffrement à la volée signifie que l’appareil reste disponible pendant le processus de changement de clé. C’est ce qu’on appelle le « rechiffrement en ligne » – qui fait référence à la possibilité de rechiffrer un disque avec une clé différente lorsqu’il est en ligne et en cours d’utilisation.

C’est dans ce processus qu’une vulnérabilité a été identifiée. Il s’avère que si vous savez ce que vous faites, vous pouvez effectuer cette opération sans posséder le mot de passe original et actuel. Même sans mot de passe, vous pouvez demander un rechiffrement.

En exploitant la faille, ce processus semblerait alors avorté et certaines des données seraient rendues disponibles non cryptées. À aucun moment, l’appareil ne subit de comportement anormal, il serait donc difficile de repérer un attaquant effectuant l’opération simplement en regardant l’état de l’appareil de blocage.

Il est fortement conseillé aux administrateurs système de mettre à niveau cryptsetup, le package prenant en charge LUKS, sur tous les systèmes sous leur contrôle, car la vulnérabilité peut entraîner la divulgation d’informations.

Ok, donc je vais juste patcher et passer à autre chose… ?

Exactement. C’est ce que chaque administrateur système doit faire sur son système : remplacer le package concerné. Mais pour certains administrateurs système, ce sera plus facile à dire qu’à faire. Quels administrateurs système auront du mal ? Vous avez bien deviné – ceux qui dépendent encore de CentOS 8.

La plupart des fournisseurs ont été avertis rapidement du bogue et fournissent déjà des packages mis à jour pour leurs distributions. Et de même avec Red Hat, qui soutient CentOS. Mais, CentOS 8 n’étant plus officiellement pris en charge, un correctif CentOS 8 pour la faille LUKS n’apparaîtra pas.

Pour les utilisateurs de CentOS 8, les choses sont donc assez sombres. Les systèmes non corrigés sont vulnérables au vol de données en raison d’une faille publiée et largement connue. Il s’agit d’une situation grave et d’une manière ou d’une autre, vous devez déployer des versions corrigées à jour du package concerné.

Ne rien faire n’est pas une option lorsque des données confidentielles sont en danger. Et, essentiellement, toutes vos données sont confidentielles et ne doivent pas être divulguées au public (sinon elles auraient déjà été rendues publiques), et vous comptez sur une solution de chiffrement complet du disque comme LUKS précisément pour éviter la divulgation.

Vos options de patch si vous êtes toujours sur CentOS 8

Il existe deux chemins disponibles pour les administrateurs système s’appuyant sur les systèmes Linux concernés fonctionnant au-delà de leur fin de vie. Une option consiste à télécharger la source du projet en amont et à la compiler localement, en créant un package système de remplacement. L’autre option consiste à signer avec un fournisseur de support étendu qui fournira les correctifs qui ne sont plus publiés par le fournisseur d’origine.

L’approche de construction locale a des inconvénients. Premièrement, le code source du projet d’origine ne fait aucune allocation spéciale pour une distribution spécifique. Chaque distribution ou famille de distributions a ses propres particularités. La famille RHEL, qui comprend CentOS, aura également ces bizarreries.

Cela inclut des éléments tels que les emplacements binaires, les configurations de démarrage du service, les paramètres, etc. Votre équipe locale devra les ajuster manuellement. Que votre équipe informatique locale possède l’expertise nécessaire est une autre question. De même, les équipes techniques étant généralement sous pression pour faire avancer les choses, il y a un risque que votre effort de patching DIY soit retardé. Aussi, sur la page du projet LUKS lui-mêmeil y a ce sinistre « Veuillez toujours préférer les outils de construction spécifiques à la distribution pour configurer manuellement cryptsetup ».

Votre alternative est de considérer les fournisseurs de support étendu comme une approche fiable, rentable et plus simple pour résoudre ce problème. Support de cycle de vie étendu de TuxCare service fait exactement cela. TuxCare fournit des correctifs de haute qualité pour les distributions en fin de vie telles que CentOS 8 et le fait à temps.

De plus, vous bénéficiez également d’un support complet pour les correctifs. Le déploiement est simple, vous déployez les correctifs TuxCare aussi facilement que les correctifs pris en charge par les fournisseurs.

Vous devez agir – maintenant

Si vous décidez de ne pas opter pour une assistance externe, vous devez néanmoins faire quelque chose dès maintenant pour protéger vos systèmes contre la nouvelle vulnérabilité. Vous pouvez décider de mordre la balle et de compiler cryptsetup et ses dépendances localement, et d’effectuer le déploiement sur tous vos systèmes.

Mais ce n’est certainement pas le dernier CVE à sortir qui affecte CentOS 8. Pour vous donner une idée de l’étendue de ce dont nous parlons : même aujourd’hui, il y a encore des vulnérabilités qui affectent les systèmes CentOS 6. Dans quelle mesure est-il viable à long terme de continuer à gérer un flux continu de CVE affectant CentOS 8 ?

Vous utilisez peut-être CentOS 8 en ce moment car vous n’avez pas pu migrer vers une alternative pour une raison ou une autre. Cela peut être la compatibilité, le support ou l’une des multiples raisons.

Les vulnérabilités ne s’arrêteront pas à la date de fin de vie, alors simplifiez la vie de vos équipes informatiques, sécurisez davantage vos professionnels de la sécurité et respectez les exigences de conformité en matière de correctifs pour votre entreprise – consultez La famille de services de TuxCare, et plus particulièrement le support étendu du cycle de vie. C’est un moyen solide d’obtenir une protection continue contre les nouveaux CVE qui affectent Cent OS 8 – vous faire gagner du temps pour migrer vers un autre système d’exploitation.