Un correctif de sécurité ? Oui. Mais incomplet. Plusieurs mois après avoir publié deux patchs majeurs pour corriger les vulnérabilités de Quick Share, Google a discrètement comblé deux failles résiduelles, dont l’une permettait toujours d’envoyer un fichier sur Windows sans consentement du destinataire.
On pensait l’histoire réglée. L’été dernier, Google avait été amenée à corriger une dizaine de failles affectant Quick Share, dont deux vulnérabilités importantes dans la version Windows. L’une permettait de provoquer un crash à distance, l’autre de contourner les autorisations de transfert et d’envoyer un fichier à l’insu de la cible. Mais en analysant les correctifs publiés, les chercheurs de SafeBreach ont mis au jour deux failles résiduelles permettant, pour l’une, de contourner la suppression automatique des fichiers non acceptés par le destinataire, et pour l’autre, de faire planter l’application. Il aura donc fallu une deuxième intervention pour refermer complètement la brèche.
Deux failles résiduelles découvertes post-mises à jour
La dernière version de Quick Share pour Windows, estampillée 1.0.2002.2, vient colmater une vulnérabilité jusqu’ici passée entre les mailles du filet. Identifiée CVE-2024-10668, cette faille permettait de contourner le correctif mis en place pour empêcher le transfert de fichiers sans autorisation. En jouant sur la manière dont l’application gère les fichiers en cours de transfert, il était encore possible de déposer un fichier sans consentement sur l’appareil cible, malgré le patch précédent.
Dans le détail, le correctif initial contre le transfert non sollicité avait été conçu pour écrire temporairement le fichier sur le disque, puis le supprimer automatiquement en fin de session s’il n’avait pas été accepté par le destinataire. Une mesure a priori dissuasive, mais de toute évidence insuffisante, puisqu’en envoyant deux fichiers différents avec le même identifiant de transfert, l’attaquant pouvait tromper l’application, qui ne supprimait alors qu’une seule copie sur deux à l’issue de la session, tandis que l’autre était bien conservée sur l'appareil.
La seconde vulnérabilité résiduelle, de portée moindre, visait une faille de type déni de service (DoS). Lors de la première vague de corrections, Google avait tenté de bloquer les noms de fichiers commençant par les caractères nuls \x00. Mais dans les faits, il a suffi d’utiliser une autre séquence UTF-8 invalide (comme \xc5\xff) pour provoquer un crash de Quick Share à distance.
SafeBreach, à l’origine de la découverte, a rapporté ces failles à Google dès août 2024. Le nouveau correctif est désormais disponible. Aucune exploitation active n’a été détectée, mais les versions antérieures de Quick Share pour Windows restent vulnérables aux deux scénarios exposés ci-dessus.
Corriger en surface, ignorer le fond : le vrai problème de Quick Share
La découverte de ces nouvelles failles intervient après une première salve de brèches révélée à l’été 2024. À l’époque, les chercheurs de SafeBreach avaient publié un rapport détaillé intitulé QuickShell, présenté à la DEF CON. Ils y démontraient comment une dizaine de vulnérabilités logiques et techniques, pour certaines assez graves, pouvaient être combinées dans le but d’exécuter du code à distance sur les PC équipés de Quick Share.
Parmi ces failles : des écritures de fichiers non autorisées, des connexions Wi-Fi forcées, des plantages contrôlés à distance, et donc, cette fameuse possibilité d’envoyer un fichier sans qu’il soit validé. Google avait alors émis deux correctifs majeurs (CVE-2024-38271 et CVE-2024-38272), censés boucler l’affaire.
Mais force a été de constater qu’à l’épreuve des faits, ces correctifs se sont révélés incomplets. Pour SafeBreach, cette affaire est aussi et surtout révélatrice d’une pratique hélas courante : corriger les symptômes sans s’attaquer à la racine réelle du problème. Ici, le vrai souci résidait dans le fait que Quick Share puisse écrire les fichiers sur le disque avant même que l’utilisateur ne les accepte. Un processus officiellement pensé pour fluidifier l’expérience utilisateur, au détriment manifeste de la sécurité des appareils.
Source : SafeBreach
17 juillet 2023 à 11h30
