Qubes OS : un simple nom de fichier pouvait franchir la frontière jusqu’à dom0

Qubes OS repose sur une idée assez saine : si une application se fait pirater, elle ne devrait pas entraîner tout l’ordinateur avec elle. Le système sépare donc le travail, la navigation, les fichiers sensibles et les tâches d’administration dans des machines virtuelles distinctes. Au centre se trouve dom0, le domaine de confiance qui pilote l’interface et les autres qubes. On n’y ouvre normalement ni navigateur ni pièce jointe. C’est la salle des clés.

Le bulletin de sécurité QSB-118 révèle pourtant qu’un nom de fichier spécialement fabriqué pouvait franchir cette frontière. La faille touche l’outil qvm-copy-to-vm lorsqu’un utilisateur copie volontairement un fichier depuis dom0 vers un qube déjà compromis ou malveillant.

Le piège était dans le message d’erreur

Après une copie, le qube destinataire peut renvoyer à dom0 le nom du dernier fichier reçu ou une information d’erreur. Qubes nettoyait bien certains caractères, notamment les guillemets et les caractères non ASCII. Pas tous. Des métacaractères compris par le shell pouvaient subsister.

Le chemin devient dangereux un peu plus loin. Pour afficher une boîte de dialogue graphique en cas d’erreur, le code transmettait ce texte à la fonction system(). Autrement dit, une donnée contrôlée par le qube se retrouvait intégrée dans une commande exécutée par dom0. Un attaquant pouvait alors transformer un faux nom de fichier en commande et prendre le contrôle du domaine le plus privilégié du système.

La nuance compte : ce n’est pas une compromission distante en un clic. Il faut d’abord contrôler le qube cible, puis convaincre l’utilisateur d’effectuer une copie depuis dom0 vers celui-ci. Les copies ordinaires entre deux qubes ne suivent pas le même traitement d’erreur et ne sont pas concernées par cette variante.

Que faut-il faire ?

Toutes les versions de Qubes OS sont annoncées comme affectées. Pour Qubes 4.3, le correctif arrive dans le paquet qubes-core-dom0-linux en version 4.3.22, d’abord dans le dépôt de test de sécurité puis dans le dépôt stable. Le projet ne demande pas de manipulation exotique : il faut appliquer les mises à jour normales de dom0 et redémarrer si le gestionnaire le réclame.

L’incident n’annule pas l’intérêt de Qubes. Il rappelle plutôt pourquoi les interfaces entre compartiments méritent autant d’attention que les compartiments eux-mêmes. Une porte blindée peut être excellente. Si le visiophone exécute ce que lui dicte le visiteur, le plan de sécurité commence tout de même à tousser.

En bref : la faille est grave, mais son scénario est précis et un correctif est disponible par le canal habituel. L’isolation reste une excellente idée, à condition de traiter chaque message qui remonte vers dom0 comme potentiellement hostile.

Sources

• Bulletin de sécurité Qubes QSB-118
• Guide officiel de mise à jour de Qubes OS

Le Bien Heureux · Rédaction Capibara · Lundi 31 août 2026