Hardware-Security

Trouvé à 2 h du matin, en lisant du source ESP-TEE que je n’avais aucune raison de lire. Une ligne semblait bancale. Elle l’était, à un seul caractère près. Ce caractère avait rouvert un CVSS 9.3, à l’intérieur même du correctif censé le fermer. TL;DR Deux failles jumelles dans les wrappers de services sécurisés ESP-TEE. Même code, primitives opposées. L’écriture (CVE-2026-45328, CVSS 9.3 critique, CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H ; le terme C:H est le pire cas chaîné, voir la section impact). Sa cause racine est une validation de pointeurs incomplète. Espressif l’a corrigée, puis un commit oublié a rouvert l’écriture en v6.0.1 : un seul caractère, = au lieu de &= dans _ss_esp_tee_sec_storage_aead_encrypt(), transforme en dead-store la chaîne de validation de pointeurs à cinq termes dès que aad_len != 0. Une application REE pointe l’argument iv vers la mémoire M-mode du TEE ; le TEE appelle ensuite esp_fill_random(iv, iv_len) avant l’exécution du corps AEAD, écrivant un nombre d’octets aléatoires contrôlé par l’attaquant à l’adresse TEE choisie par l’attaquant. ...

Certains bugs se cachent derrière une exploitation astucieuse. Celui-ci est un memcpy sans aucun contrôle de longueur, atteignable avant authentification, depuis n’importe quelle radio BLE à portée. TL;DR CVE-2026-47773 (GHSA-77v6-cw9f-9whg). Un contrôle de bornes manquant dans le handler de write request ATT d’ArduinoBLE. Quand un client écrit dans une caractéristique qui exige le chiffrement (la permission BLEEncryption) alors que le lien n’est pas encore chiffré en AES, ArduinoBLE range l’écriture en attente dans un writeBuffer fixe de 64 octets à l’intérieur de l’objet global ATTClass, pour la rejouer une fois le chiffrement établi. Il copie la valeur fournie par l’attaquant dans ce buffer sans aucun contrôle de longueur. ...