ClickCease Des correctifs sans redémarrage pour 'BleedingTooth' sont en route - TuxCare

Rejoignez notre populaire bulletin d'information

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

2 fois par mois. Pas de spam.

Des patchs sans reboot pour "BleedingTooth" sont en route

16 octobre 2020 - L'équipe de relations publiques de TuxCare

Les patchs sans rebond pour les dents qui saignent sont en cours de réalisationLes chercheurs en sécurité de Google ont récemment découvert une faille dans la façon dont l'implémentation Bluetooth du noyau Linux traite les paquets L2CAP avec le CID A2MP. Un attaquant distant à portée pourrait utiliser cette faille pour faire planter un système ciblé en provoquant un déni de service ou potentiellement exécuter du code arbitraire sur le système en envoyant un paquet L2CAP spécialement conçu. Toutes les distributions Linux sont concernées, mais l'exploitation n'est possible que si vous avez des périphériques connectés via Bluetooth à votre infrastructure.

Nos clients des centres de données pourraient se demander pourquoi une vulnérabilité Bluetooth est un problème critique lorsque l'attaquant doit être à portée du système ciblé, mais il est probable que vous avez des caméras de surveillance, des téléviseurs intelligents, des imprimantes sans fil et d'autres points d'extrémité qui seraient vulnérables à "BleedingTooth". Intel suggère de corriger les serveurs avec les mises à jour des fournisseurs, mais cette méthode nécessite un redémarrage du serveur. KernelCare publie des correctifs de sécurité pour 'BleedingTooth' qui ne nécessiteront pas de redémarrage du serveur, de sorte que les infrastructures critiques, y compris les dispositifs IoT, peuvent être corrigées dans une petite fenêtre de vulnérabilité sans interrompre les services et affecter les accords de niveau de service.

Qu'est-ce que "BleedingTooth" ?

BleedingTooth" n'est pas suivi par un seul CVE mais par plusieurs, à savoir CVE-2020-12351, CVE-2020-12352 et CVE-2020-24490. Le CVE-2020-12351 est le plus important de ces trois, avec un score de gravité de 8,3. Comme il s'agit d'une découverte récente, on sait peu de choses sur cette vulnérabilité à ce jour et les CVE réservés n'ont pas été détaillés, mais elle est suffisamment critique pour qu'Intel et les fournisseurs de Linux suggèrent de la corriger immédiatement. Toutes les distributions Linux sont concernées, donc tout appareil ou serveur exécutant une version non corrigée est vulnérable.

À l'aide d'un paquet L2CAP malveillant utilisé dans la communication Bluetooth, un attaquant peut provoquer un déni de service (DoS) ou exécuter du code sur le système cible. Intel prévient que cet exploit peut également conduire à une élévation de privilèges. L'attaquant doit connaître l'adresse bd (BD_ADDR), qui est un identifiant de 48 bits attribué à chaque périphérique Bluetooth. Un code d'exploitation de type "proof-of-concept" peut être trouvé sur Github.

Dans CVE-2020-12352, les chercheurs de Google indiquent que les clés de chiffrement et d'autres données sensibles pourraient être obtenues en prédisant les dispositions de la mémoire pour déjouer le KASLR (Kernel Address Space Layout Randomization). Une preuve de concept a également été fournie pour démontrer le problème.

Seuls les appareils utilisant des puces Bluetooth 5 sont vulnérables, mais les attaquants peuvent utiliser des puces malveillantes pour exploiter la vulnérabilité. BlueZ est la bibliothèque de protocole responsable de la vulnérabilité, et ses développeurs ont annoncé des correctifs pour les trois CVE ou les utilisateurs peuvent mettre à jour leur version du noyau Linux à 5.9. Toute version antérieure à 5.9 est vulnérable.

Existe-t-il des techniques d'atténuation ?

Les personnes qui utilisent des appareils personnels basés sur Linux avec Bluetooth peuvent le désactiver pour le moment, mais ce n'est pas une option viable pour les appareils d'entreprise. Outre la désactivation de Bluetooth, aucune autre méthode n'est disponible pour atténuer le problème, à part l'application immédiate des correctifs de sécurité nécessaires. Les correctifs publiés par les fournisseurs, cependant, nécessitent un redémarrage du serveur. Les serveurs d'entreprise ne peuvent pas être redémarrés sans discernement, ce qui signifie que les administrateurs doivent effectuer une maintenance d'urgence ou attendre un changement programmé. Attendre pour appliquer les correctifs de sécurité laisse alors les serveurs vulnérables aux exploits, ce qui met l'entreprise en danger. Les correctifs de KernelCare qui seront bientôt publiés ne nécessiteront pas de redémarrage, et tous les clients de KernelCare recevront les mises à jour de sécurité nécessaires pour remédier à "BleedingTooth".

Obtenez un essai GRATUIT de 7 jours avec assistance de KernelCare 

 

 

Conclusion

Bien que cette vulnérabilité puisse sembler sans importance pour une entreprise cliente, il est encore plus crucial qu'elle corrige Linux en raison des nombreux points d'extrémité fantômes disponibles dans un grand environnement réseau. Les déclarations des chercheurs en sécurité indiquent que la mise à jour du noyau Linux est la seule option, ce qui nécessite un redémarrage et une interruption de service. Le service de correctifs en direct de KernelCare déploiera les correctifs de sécurité nécessaires qui ne nécessiteront pas de redémarrage. Vous pouvez vous inscrire pour une période d'essai de 7 jours de KernelCare+ et bénéficier des mises à jour sans redémarrage en début de semaine prochaine. Pour savoir immédiatement quand le correctif sera disponible, vous pouvez suivre cet article de blog sur nos comptes Twitter et Facebook.

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