BleedingTooth: une vulnérabilité dans BlueZ qui permet l'exécution de code à distance

Les ingénieurs de Google ont publié à travers un message qu'ils ont identifié une vulnérabilité sérieuse (CVE-2020-12351) dans la pile Bluetooth "BlueZ" qui est utilisé dans les distributions Linux et Chrome OS.

La vulnérabilité, nom de code BleedingTooth, permet à un attaquant non autorisé d'exécuter votre code au niveau du noyau Linux sans intervention de l'utilisateur en envoyant des paquets Bluetooth spécialement conçus.

Le problème peut être exploité par un attaquant qui se trouve à portée Bluetooth et en plus du fait qu'un appairage préalable entre l'appareil attaquant et la victime n'est pas nécessaire, la seule condition est que Bluetooth doit être actif sur l'ordinateur.

À propos de la vulnérabilité

Pour une attaque, il suffit de connaître l'adresse MAC de l'appareil de la victime, qui peut être déterminée par traçage ou, sur certains appareils, calculée en fonction de l'adresse MAC Wi-Fi.

Vulnérabilité est présent dans les composants qui traitent les paquets L2CAP (Logical Link Control and Adaptation Protocol) au niveau du noyau Linux.

Lors de l'envoi d'un paquet L2CAP spécialement conçu avec des données supplémentaires pour le canal A2MP, un attaquant peut écraser une zone en mémoire mapped, qui peut potentiellement être utilisé pour créer un exploit pour exécuter du code arbitraire au niveau du noyau.

En spécifiant un CID autre que L2CAP_CID_SIGNALING, L2CAP_CID_CONN_LESS et L2CAP_CID_LE_SIGNALING dans le paquet, le gestionnaire 2cap_data_channel () est appelé dans BlueZ, qui pour les canaux dans les modes L2CAP_MODE_CONN_LESS, et L2CAP_CID_LE_SIGNALING dans le paquet, le gestionnaire 2cap_data_channel () est appelé dans BlueZ, qui pour les canaux dans les modes L2CAP_MODE_CONN_LESS et L2CAP_CID_LE_SIGNALING dans le paquet, le gestionnaire XNUMXcap_data_channel () est appelé dans BlueZ, qui, pour les canaux dans les modes LXNUMXCAP_MODE_CONN_LESS, et LXNUMXCAP_MODE_ERTM filterSumter_Sumter_Canal est mis en correspondance avec les modes de checksum_ap_ap_sipter_AP et le filtre_AP_Sumter_Canal LXNUMXCAP et le filtre_AP_Sumter_Contact_AP_sumter . Pour les paquets avec CID LXNUMXCAP_CID_AXNUMXMP, il n'y a pas de canal, donc pour le créer, la fonction aXNUMXmp_channel_create () est appelée, qui utilise le type "struct amp_mgr" lors du traitement du champ chan-> data, mais le type de ce champ doit être " Chaussette de structure ".

La vulnérabilité est apparue depuis le noyau Linux 4.8 Et malgré les affirmations d'Intel, il n'a pas été abordé dans la version 5.9 récemment publiée.

Matthew Garrett, un développeur de noyau Linux bien connu qui a reçu un prix de la Free Software Foundation pour sa contribution au développement de logiciels libres, affirme que les informations contenues dans le rapport d'Intel sont incorrectes et que le noyau 5.9 n'inclut pas les correctifs appropriés. vulnérabilité, des correctifs ont été inclus dans la branche linux-next, pas dans la branche 5.9).

Il a également exprimé son indignation face à la politique d'Intel de divulgation des vulnérabilités: les développeurs de distribution Linux n'ont pas été informés du problème avant la publication du rapport et n'ont pas eu la possibilité de pré-exporter les correctifs pour leurs packages de noyau.

De plus, deux autres vulnérabilités auraient été identifiées dans BlueZ:

  • CVE-2020-24490 - Débordement de la mémoire tampon du code d'analyse HCI (hci_event.c). Un attaquant distant peut provoquer des dépassements de tampon et exécuter du code au niveau du noyau Linux en envoyant des annonces de diffusion. L'attaque n'est possible que sur les appareils prenant en charge Bluetooth 5, lorsque le mode scan est actif sur eux.
  • CVE-2020-12352: perte d'informations de la pile pendant le traitement des paquets A2MP. Le problème peut être exploité par un attaquant qui connaît l'adresse MAC d'un périphérique pour récupérer des données de la pile du noyau, qui pourraient potentiellement contenir des informations sensibles telles que des clés de chiffrement. La pile peut également contenir des pointeurs, le problème peut donc être utilisé pour déterminer la disposition de la mémoire et contourner la protection KASLR (randomisation d'adresse) dans les exploits pour d'autres vulnérabilités.

Enfin, la publication d'un prototype d'exploit pour vérifier le problème a été annoncée.

Sur les distributions, le problème reste non corrigé (Debian, RHEL (vulnérabilité confirmée dans les versions RHEL à partir de 7.4), SUSE, Ubuntu, Fedora).

La plate-forme Android n'est pas affectée par le problème car elle utilise sa propre pile Bluetooth, basée sur le code du projet BlueDroid de Broadcom.

Si vous souhaitez en savoir plus sur cette vulnérabilité, vous pouvez consulter les détails dans le lien suivant.


Un commentaire, laissez le vôtre

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont marqués avec *

*

*

  1. Responsable des données: Miguel Ángel Gatón
  2. Finalité des données: Contrôle du SPAM, gestion des commentaires.
  3. Légitimation: votre consentement
  4. Communication des données: Les données ne seront pas communiquées à des tiers sauf obligation légale.
  5. Stockage des données: base de données hébergée par Occentus Networks (EU)
  6. Droits: à tout moment, vous pouvez limiter, récupérer et supprimer vos informations.

  1.   Aron dit

    La lutte contre la vulnérabilité ne s'arrêtera jamais, c'est un problème qui sera toujours présent. Chaque jour, les pirates chercheront d'autres moyens de lancer des cyberattaques. Rien n'est parfait, il y aura toujours un pourcentage de vulnérabilité. C'est pourquoi, chaque jour, nous devons continuer à travailler dans la lutte contre ces attaques.