IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Ubuntu 26.10 achève la transition vers les utilitaires de base écrits en Rust
Devenant la première distribution à remplacer entièrement les utilitaires GNU coreutils par l'implémentation uutils basée sur Rust

Le , par Alex

163PARTAGES

9  0 
Ubuntu 26.10 « Stonking Stingray », dont la sortie est prévue le 15 octobre, deviendra la première distribution à remplacer entièrement les utilitaires GNU coreutils par l’implémentation uutils basée sur Rust. Trois commandes — cp, mv et rm — avaient auparavant conservé leurs versions GNU après qu’un audit de sécurité réalisé eut révélé des conditions de concurrence TOCTOU, mais les correctifs apportés en amont ont désormais permis une migration complète. L’intérêt de Canonical pour Rust est principalement motivé par la sécurité mémoire plutôt que par les performances, et la feuille de route prévoit notamment de faire du client NTP basé sur Rust le client par défaut dans la version 27.10.

Ubuntu est une distribution Linux fondée sur Debian. Elle est développée, commercialisée et maintenue pour les ordinateurs individuels (Desktop), les serveurs (Server) et les objets connectés (Core) par la société britannique Canonical. Ubuntu est disponible en deux versions, une qui évolue tous les six mois, et une version LTS, pour Long Term Support (« Support long terme ») qui évolue tous les deux ans. Ubuntu se définit comme « un système d'exploitation utilisé par des millions de PC à travers le monde » et avec une interface « simple, intuitive, et sécurisée ».

Il y a près d'un an, Canonical annonçait Ubuntu 25.10 « Questing Quokka », introduisant GNOME 49 comme bureau par défaut, fonctionnant exclusivement sur Wayland avec les pilotes NVIDIA, et livré avec le noyau Linux 6.17. Depuis cette version, Canonical a montré son engagement à accroître la résilience des logiciels système critiques dans Ubuntu en adoptant des implémentations modernes de composants clés tels que sudo et coreutils. Dans le cadre de cette initiative, Ubuntu 25.10 utilise sudo-rs, une nouvelle implémentation Rust de l'outil sudo. L'introduction d'un sudo sécurisé en mémoire offre de nombreux avantages par rapport à l'implémentation traditionnelle. Pour les utilisateurs, la réduction de la surface d'attaque dans l'outil sudo améliorera la sécurité globale d'Ubuntu.

Récemment, un rapport a révélé qu'Ubuntu 26.10 « Stonking Stingray », dont la sortie est prévue le 15 octobre, deviendra la première distribution à remplacer entièrement les utilitaires GNU coreutils par l’implémentation uutils basée sur Rust. Trois commandes — cp, mv et rm — avaient auparavant conservé leurs versions GNU après qu’un audit de sécurité réalisé eut révélé des conditions de concurrence TOCTOU, mais les correctifs apportés en amont ont désormais permis une migration complète.

Cette version devrait intégrer le noyau Linux 7.3 et GNOME 51, avec une version bêta prévue pour le 24 septembre. L’intérêt de Canonical pour Rust est principalement motivé par la sécurité mémoire plutôt que par les performances, et la feuille de route prévoit notamment de faire du client NTP basé sur Rust le client par défaut dans la version 27.10. Par ailleurs, l’image d’installation pour ordinateur de bureau 24.04.5 a été temporairement retirée en raison d’un bug dans le programme d’installation.


Ubuntu 26.10 : première distribution à remplacer entièrement les utilitaires GNU coreutils par l’implémentation uutils basée sur Rust

Ubuntu s’apprête à franchir une étape importante. La version 26.10 « Stonking Stingray », prévue pour le 15 octobre, deviendra la première distribution à remplacer entièrement les utilitaires GNU de base (coreutils) par une implémentation en Rust : le code sous-jacent des commandes les plus couramment utilisées, telles que ls, cat, chmod et du, a été entièrement migré vers le projet uutils. Cette transition marque la phase finale de la stratégie de « Rustification » à l’échelle de la distribution menée par Canonical, lancée en 2025. La version 25.10 avait déjà fait de la version de sudo réécrite en Rust (sudo-rs) la version par défaut, mais trois commandes de manipulation de fichiers — cp, mv et rm — avaient dû conserver leurs versions GNU après qu’un audit de sécurité eut révélé des problèmes. Ce n’est qu’avec la version 26.10 que les trois dernières pièces du puzzle ont été mises en place.

La motivation principale de Canonical pour la « rustification » complète des coreutils n’est pas le gain de performances, mais la sécurité de la mémoire. Le langage Rust permet d’intercepter les erreurs de mémoire dès la phase de compilation, ce que le C ne peut pas faire. Pour une distribution de système d’exploitation, les coreutils constituent le fondement de l’ensemble de la pile logicielle : éliminer une catégorie de vulnérabilités mémoire à la base signifie que toute la chaîne de dépendances évite un vaste éventail de risques potentiels.

Ce qui bloquait auparavant la migration de cp, mv et rm était un rapport d’audit de sécurité. Canonical a chargé la société de sécurité Zellic d’auditer uutils, ce qui a permis de mettre au jour un ensemble de conditions de concurrence TOCTOU (time-of-check to time-of-use). Ce type de vulnérabilité est le plus critique pour les outils de gestion de fichiers : les attaquants peuvent altérer des fichiers dans l’intervalle entre le moment où un programme vérifie l’état d’un fichier et celui où il l’utilise réellement, contournant ainsi les contrôles d’autorisation ou provoquant la corruption des données.

La version 26.04 LTS étant une version à support à long terme (LTS) soumise à des exigences plus strictes en matière de stabilité et de sécurité, Canonical avait alors décidé de conserver les implémentations GNU pour ces trois commandes. Le projet uutils en amont ayant désormais résolu les problèmes concernés, la version 26.10 a pu mener à bien le remplacement complet.

Rust Coreutils dans Ubuntu 26.10 : objectif d’une migration transparente

Créé à l'origine par Jordi Boggiano en 2013, le projet uutils, aussi connu sous le nom de Rust Coreutils, vise à réécrire en Rust tous les utilitaires individuels inclus dans le projet GNU Coreutils. Le projet a pour objectif de fournir des remplacements immédiats pour les programmes Coreutils, en ajoutant la protection contre la concurrence d'accès et la sécurité de la mémoire que Rust fournit. En février 2022, Sylvestre Ledru, le développeur principal du projet Rust Coreutils, a annoncé que le projet était en bonne voie et apportait des améliorations significatives par rapport à l'ancienne implémentation en C. Rust Coreutils continuait également d'augmenter son niveau de compatibilité avec GNU Coreutils.

En mai 2025, Canonical prévoyait d'utiliser davantage de composants système écrits en Rust, en annonçant la transition vers Rust Coreutils « uutils » à la place de GNU Coreutils. Il avait également été confirmé que Canonical prévoit d'utiliser sudo-rs par défaut en remplacement de sudo. Pour l'annonce, Canonical affirmait : « Bien qu'aucun logiciel - quel que soit le langage - ne soit parfait, nous pensons que la transition vers Rust dans la programmation des systèmes est un pas en avant vital. Il est très excitant de voir Ubuntu s'engager en faveur de sudo-rs et jouer un rôle de premier plan pour faire avancer les choses. »

Le projet uutils est conçu pour être compatible « drop-in » avec GNU coreutils, tout écart de comportement étant considéré comme un bogue. La position de Canonical est claire : les utilisateurs ne doivent pas savoir s’ils utilisent la version GNU ou la version Rust. Il y a eu par le passé un problème de compatibilité avec uutils lié à la commande « date », mais dans l’ensemble, le processus de migration a été pratiquement imperceptible pour les utilisateurs lambda. Pour ceux qui sont déjà habitués au fonctionnement quotidien d’Ubuntu, ce changement d’implémentation sous-jacente ne modifiera en rien leurs habitudes d’utilisation.

La « rustification » complète de coreutils n’est pas une fin en soi. La feuille de route de Canonical indique qu’Ubuntu 27.10 prévoit de faire du client NTP réécrit en Rust par la Fondation Trifecta l’outil de synchronisation horaire par défaut. Canonical verse chaque année 40 000 € à la fondation pour financer la réécriture de logiciels fondamentaux en Rust. Cette série de mesures reflète un effort systématique de la part des responsables de la distribution pour réduire les risques de sécurité posés par l’ancien code C. Alors que la présence de Rust dans les logiciels système de bas niveau continue de s’étendre, l’approche d’Ubuntu pourrait offrir une voie de migration de référence pour d’autres distributions Linux.

Rust a été adopté par de nombreux projets logiciels

Récemment, AMD a montré son souhait d'intégrer Rust plus profondément dans son logiciel graphique que ne l'a jamais fait aucun autre fournisseur de GPU. Harsh Meno, Senior Fellow, a écrit sur LinkedIn que la société mettait en place « une petite équipe d’élite chez AMD pour intégrer Rust en profondeur dans...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de OuftiBoy
Membre éprouvé https://www.developpez.com
Le 15/09/2026 à 20:35
à toutes et tous,

Je ne suis pas un expert de Rust, et la question que je pose ici n'a nullement pour but le débat pour ou contre l'utilisation de Rust vs C. Du tout, la question que je me pose, est en lien avec ceci :

Ce type de vulnérabilité est le plus critique pour les outils de gestion de fichiers : les attaquants peuvent altérer des fichiers dans l’intervalle entre le moment où un programme vérifie l’état d’un fichier et celui où il l’utilise réellement, contournant ainsi les contrôles d’autorisation ou provoquant la corruption des données.
La question est : Est-ce que la vulnérabilité en question est liée à l'intervalle lui-même où est-elle liée à la manière dont est géré cet intervalle ? (car cet intervalle reste existant quelque soit le langage utilité, non ?) En d'autres mots, est-ce que se sont les mécanismes de Rust en eux-même qui permettent d'éviter ou de contourner la vulnérabilité de cet intervalle ? Puisque que in-fine le code générer est du code machine, est-il impensable de penser que la même gestion de cet intervalle en C pourrait permettre le même niveau de sécurité qu'en Rust ?

Aussi, si Rust a permit de résoudre le problème de la gestion de cet intervalle, pourquoi ne pas implémenter ces corrections en C ? La gestion des fichiers étant tellement importante, le moindre gain (éventuellement possible en utilisant (gardant) C à la place de Rust) ne mérite-t-il pas d'être utilisé ?

C'est une question théorique, qui, me semble-t-il, peut être posée sans entrer dans une vaine polémique.

Merci d'avance pour votre participation à ce débat.

BàV et Peace & Love.
5  0 
Avatar de LittleWhite
Responsable 2D/3D/Jeux https://www.developpez.com
Le 16/09/2026 à 11:06
Bonjour,

Citation Envoyé par Freem Voir le message
Les versions historiques en C n'ont PAS ces failles de sécurité critiques que leurs réécritures en Rust ont eu. Ce n'est pas illogique, non plus: aucun langage ne protège et ne protégera jamais contre les bogues, et la mémoire n'est pas le seul point qui crée des problèmes de sécurité, quoi qu'en disent les créateurs de Rust .
D'ailleurs, les inventeurs des rust, mozilla, n'empêchent pas Firefox de fuir (la mémoire utilisée grossit avec le temps, et n'est pas désallouée quand on ferme un onglet, ce qui mène lentement mais sûrement à un crash. Hors, les crash sont un problème de sécurité.
Firefox n'est pas intégralement implémenté en Rust. De plus, la mémoire d'un onglet peut ne pas être désalloué, pour permettre à l'utilisateur de restaurer cet onglet (Ctrl + Shift + T), cela peut donc être un choix (probablement discutable, mais à un moment, dans n'importe quel projet, il faut faire des compromis et prendre une décision). Aussi, cela ne mènera pas nécessairement à un crash, si le programme effectue une sorte de garbage collector lorsqu'on ouvre un nouvel onglet (par exemple, pour voir si on doit demander plus de mémoire au système, ou si le logiciel a déjà la mémoire, juste qu'elle n'a pas été rendu (comme un pool)). Finalement, je ne suis pas certain (et là, c'est un doute que j'ai à titre personnel) que tout crash peut être converti en faille de sécurité. Notamment, une fuite de mémoire, c'est juste un programme qui alloue trop de mémoire et qu'au bout d'un moment, le système lui dit : STOP ! (de manière brutale ). Cela ne me semble pas être utilisable en tant que faille, car ce n'est pas un accès à de la mémoire externe au programme, ni un use after free (il n'y a pas de free ).

Nous avons donc ici du code maintenu et corrigé depuis, au bas mot, 35 ans, qui est réécrit dans un langage "sûr" (non, rust n'est pas sûr, ça n'existe pas un language qui protège contre tous les bugs). Forcément que c'est plus bugué, et sur des outils qui sont le coeur du système, le «shell», c'est donc un choix particulièrement douteux.
Le langage peut aider à avoir un résultat plus "sûr". Voici la métaphore qui expliquerait mon point de vue : c'est comme utilisé un outil plus sophistiqué, plus adapté, plus sécurisé, pour faire la même tâche qu'avant. Par exemple, pour faire un trou, vous pouvez utiliser un simple canif, mais une perceuse avec pointage laser et stabilisateur, ça permet d'obtenir un meilleur résultat et possiblement, de façon moins dangereuse.
Plus précisément, une réécriture d'un logiciel d'il y a 35 ans peut avoir plusieurs avantages :
  • enlever la dette technique ;
  • enlever du code mort qui n'a plus lieu d'être car les systèmes ont changés
  • mieux architecturer, car les problématiques sont mieux comprises (apprises au fil des utilisations)

Bien sûr, il y a risque de réintégrer des bogues. Mais vous pouvez aussi imaginer que ce sera l'occasion de créer des tests (on y pense plus, qu'en 1980) ou même, réutiliser la suite de tests existantes pour valider la nouvelles implémentation.

Je ne dis pas que ce n'est pas bien de pouvoir vérifier à la compilation qu'on ne lit pas de mémoire en dehors de ce que l'on devrais, mais bon, en C, pour ça, il y a les analyseurs statiques.
La ou Rust peut potentiellement briller (je ne l'ai jamais utilisé) c'est dans le cas d'applications multi-threadées. Sauf que bon, `cp`, `ls`, `mv`... le MT on s'en fout un peu hein.
Certes, certains outils de base non peut être pas besoin de multithread, mais il y a aussi des outils qui en ont besoin, et qui ont vu des versions alternatives avec de nombreuses nouvelles fonctionnalités : cat -> bat, fzf, grep...

Après, les implémentations GNU des "coreutils" ont leurs critiques, par exemple: https://9front.org/img/longcat.png
Cela est discutable. Bien sûr la version plan9 est plus courte, mais elle gère beaucoup moins de choses (piper un flux dans cat, les options?). La version GNU de cat reste tout de même assez courte .
5  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 16/09/2026 à 11:55
Citation Envoyé par OuftiBoy Voir le message
La question est : Est-ce que la vulnérabilité en question est liée à l'intervalle lui-même où est-elle liée à la manière dont est géré cet intervalle ? (car cet intervalle reste existant quelque soit le langage utilité, non ?) En d'autres mots, est-ce que se sont les mécanismes de Rust en eux-même qui permettent d'éviter ou de contourner la vulnérabilité de cet intervalle ? Puisque que in-fine le code générer est du code machine, est-il impensable de penser que la même gestion de cet intervalle en C pourrait permettre le même niveau de sécurité qu'en Rust ?
Le problème "TOCTOU" ne fait pas partie des types de bug que Rust interdit par design, contrairement aux erreurs de sécurité mémoire. La probabilité d'avoir ce type de bug est à peu près le même en Rust et en C. Comme uutils reprend de zero la base de code, il y a un vrai risque que la nouvelle implémentation contienne des bugs qui n'existaient pas ou avaient déjà été corrigé dans la version C.
C'est pour ça que remplacer des bases de codes très éprouvées et relativement stables n'est pas, à mon avis, le cas d'usage le plus intéressant pour Rust. Il vaux mieux l'utiliser en priorité dans de nouveaux logiciels, ou ceux qui évoluent beaucoup et pour lesquels le risque d'introduire des régressions est déjà élevé.

Citation Envoyé par Freem Voir le message
D'ailleurs, les inventeurs des rust, mozilla, n'empêchent pas Firefox de fuir (la mémoire utilisée grossit avec le temps, et n'est pas désallouée quand on ferme un onglet, ce qui mène lentement mais sûrement à un crash. Hors, les crash sont un problème de sécurité.
Firefox est un mauvais exemple pour mesurer l'impact général de Rust, car il contient encore à l'heure actuelle 3 fois plus de lignes de code en C et C++ qu'en Rust.

De plus, les fuites mémoire sont des bugs, mais elles ne provoquent pas de failles de sécurité critiques. Au pire ça peut conduire à une faille de type Déni de service, si ça permet de provoquer des plantages rapides en boucle.
C'est pour cela que Rust n'interdit pas, par design, les fuites mémoires. Il fournit des mécanismes qui les préviennent dans la plupart des cas, mais elles restent possible en faisant des références circulaires avec les pointeurs avec comptage de référence, ou même en le demandant de manière explicite.

Citation Envoyé par Freem Voir le message
Si on regarde https://cwe.mitre.org/top25/archive/..._kev_list.html par exemple, on voit que seules les éléments aux positions 2, 3, et 9 sont liées à des bogues mémoire (enfin, j'ai pas creusé les autres en détail, mais au vu des titres...). Ce qui signifie que, sur les 10 types de failles de sécurité réellement exploitées dans la réalité, 70% ne sont pas liées à la mémoire, et donc Rust n'aide absolument pas.
Il est vrai que 70% des types de failles dans cette liste ne sont pas des erreurs mémoire. La liste n'étant pas exhaustive c'est même plus dans la réalité. Mais attention, ça ne signifie absolument pas que 70% des failles rencontrées dans les logiciels C et C++ ne sont pas des erreurs mémoires, car tous les type de faille n'ont pas le même nombre d’occurrence.
Le contexte d'utilisation du langage a aussi son importance. Par exemple les cas 7 et 10 de cette liste s'appliquent surtout au contexte des applications Web où C++ et Rust sont rarement utilisés.
Dans la pratique, pour les grosses applications C++, les acteurs sérieux sur la sécurité (qui ont déjà déployés les outils existants d'analyse statique, dynamique, fuzzing, etc...) arrivent généralement à la conclusion inverse : 70% de leurs vulnérabilités critiques sont liées à la sécurité mémoire. Donc, si Rust n'est clairement pas la panacée, il soigne une maladie très courante et potentiellement grave.

Citation Envoyé par Freem Voir le message
Je ne dis pas que ce n'est pas bien de pouvoir vérifier à la compilation qu'on ne lit pas de mémoire en dehors de ce que l'on devrais, mais bon, en C, pour ça, il y a les analyseurs statiques.
Justement, la sécurisation mémoire de Rust fonctionne plus ou moins comme un analyseur statique intégré au compilateur. Mais son gros avantage par rapport au C, c'est que le langage force à spécifier, dans le code source, des informations précises sur la durée de vie des variables, ce qui lui permet d'offrir bien plus de garanties.
Comme disait le créateur de Rust : si les outils d'analyses statique de C/C++ suffisaient à garantir la sécurité mémoire, Mozilla n'aurait jamais investi dans Rust à l'origine.
3  0 
Avatar de Freem
Membre émérite https://www.developpez.com
Le 16/09/2026 à 3:02
Les versions historiques en C n'ont PAS ces failles de sécurité critiques que leurs réécritures en Rust ont eu. Ce n'est pas illogique, non plus: aucun langage ne protège et ne protégera jamais contre les bogues, et la mémoire n'est pas le seul point qui crée des problèmes de sécurité, quoi qu'en disent les créateurs de Rust .
D'ailleurs, les inventeurs des rust, mozilla, n'empêchent pas Firefox de fuir (la mémoire utilisée grossit avec le temps, et n'est pas désallouée quand on ferme un onglet, ce qui mène lentement mais sûrement à un crash. Or, les crash sont un problème de sécurité.

Si on regarde https://cwe.mitre.org/top25/archive/..._kev_list.html par exemple, on voit que seules les éléments aux positions 2, 3, et 9 sont liées à des bogues mémoire (enfin, j'ai pas creusé les autres en détail, mais au vu des titres...). Ce qui signifie que, sur les 10 types de failles de sécurité réellement exploitées dans la réalité, 70% ne sont pas liées à la mémoire, et donc Rust n'aide absolument pas.
Chose très amusante, "Improper Control of Generation of Code ('Code Injection')" c'est notamment les injections SQL, PHP ou JS, des failles de sécu tellement bâteau que c'est littéralement le 1er truc que j'ai appris à faire, étant ado, il y a 25 ans.

Nous avons donc ici du code maintenu et corrigé depuis, au bas mot, 35 ans, qui est réécrit dans un langage "sûr" (non, rust n'est pas sûr, ça n'existe pas un language qui protège contre tous les bugs). Forcément que c'est plus bugué, et sur des outils qui sont le coeur du système, le «shell», c'est donc un choix particulièrement douteux.

Je ne dis pas que ce n'est pas bien de pouvoir vérifier à la compilation qu'on ne lit pas de mémoire en dehors de ce que l'on devrais, mais bon, en C, pour ça, il y a les analyseurs statiques.
La ou Rust peut potentiellement briller (je ne l'ai jamais utilisé) c'est dans le cas d'applications multi-threadées. Sauf que bon, `cp`, `ls`, `mv`... le MT on s'en fout un peu hein.
Après, les implémentations GNU des "coreutils" ont leurs critiques, par exemple: https://9front.org/img/longcat.png
1  0 
Avatar de OuftiBoy
Membre éprouvé https://www.developpez.com
Le 16/09/2026 à 12:04
Quelque soit le langage, une réécriture dans un autre langage n'est pas forcément un bon réflexe...

Une erreur de "logique", de "design" ou de "conception" n'a rien a voir avec le langage utilisé (même si certains langages offrent plus de possibilités pour implémenter tel ou tel "design" et/ou "concept"). Et ici, si je comprend bien, le soucis est qu'il y a un "moment" (non unicité de temps) entre 2 changements d'états offrant une potentiel surface d'attaque, et ce n'est pas un problème de langage, me semble-t-il.

Voici la métaphore qui expliquerait mon point de vue : c'est comme utilisé un outil plus sophistiqué, plus adapté, plus sécurisé, pour faire la même tâche qu'avant. Par exemple, pour faire un trou, vous pouvez utiliser un simple canif, mais une perceuse avec pointage laser et stabilisateur, ça permet d'obtenir un meilleur résultat et possiblement, de façon moins dangereuse.
Oui et non, car l'utilisation d'un outil plus sophistiqué apporte son lot de problèmes également, car il est plus difficile d'usage et/ou de compréhension. Pour faire un trou (sans autre précision), j'utiliserai non pas un canif, ni un système avec pointage laser, mais une pelle

C'est un sujet assez vaste, concernant la maintenance d'un programme durant son exploitation. Je ne pense pas qu'il y'a 1 bon moyen de faire, une bonne méthode, mais que cela reste du cas par cas, influencé par énormément de paramètres...

BàV et Peace & Love.
2  1 
Avatar de fdecode
Membre habitué https://www.developpez.com
Le 17/09/2026 à 11:08
Citation Envoyé par Freem Voir le message
D'ailleurs, les inventeurs des rust, mozilla, n'empêchent pas Firefox de fuir (la mémoire utilisée grossit avec le temps, et n'est pas désallouée quand on ferme un onglet, ce qui mène lentement mais sûrement à un crash.
Rust a été codéveloppé avec le moteur expérimental Servo programmé en Rust. Il n'a pas été développé pour Firefox.
https://servo.org/
Firefox a hérité de certains développements de Servo, mais ce n'est qu'une petite partie de Firefox. Et depuis 2020, Mozilla s'est délesté des projets Rust et Servo.
0  0 
Avatar de Escapetiger
Expert éminent sénior https://www.developpez.com
Le 21/09/2026 à 13:00
Citation Envoyé par Alex Voir le message
Ce qui bloquait auparavant la migration de cp, mv et rm était un rapport d’audit de sécurité. Canonical a chargé la société de sécurité Zellic d’auditer uutils, ce qui a permis de mettre au jour un ensemble de conditions de concurrence TOCTOU (time-of-check to time-of-use). Ce type de vulnérabilité est le plus critique pour les outils de gestion de fichiers : les attaquants peuvent altérer des fichiers dans l’intervalle entre le moment où un programme vérifie l’état d’un fichier et celui où il l’utilise réellement, contournant ainsi les contrôles d’autorisation ou provoquant la corruption des données.
https://en.wikipedia.org/wiki/Time-o...to_time-of-use
Time-of-check to time-of-use

« En développement logiciel, le délai de vérification à l'heure d'utilisation [time-of-check to time-of-use] (TOCTOU, TOCTTOU ou TOC/TOU) est une catégorie de bugs logiciels causés par une course critique [race condition [1]] impliquant la vérification de l'état d'une partie d'un système (comme une certification de sécurité) et l'utilisation des résultats de cette vérification.

Les courses critiques TOCTOU sont courantes dans Unix entre les opérations sur le système de fichiers, mais peuvent se produire dans d'autres contextes, notamment les sockets locaux et l'utilisation inappropriée des transactions de base de données. Au début des années 1990, l'utilitaire mail de BSD 4.3 UNIX avait une course critique exploitable pour les fichiers temporaires car il utilisait la fonction mktemp(). Les premières versions d'OpenSSH avaient une une course critique exploitable pour les sockets de domaine Unix.

Elles restent un problème dans les systèmes modernes ; en 2019, une course critique TOCTOU dans Docker permet un accès root au système de fichiers de la plateforme hôte. Lors de la compétition Pwn2Own 2023 à Vancouver, une équipe de hackers a réussi à compromettre la passerelle dans une Tesla Model 3 mise à jour en utilisant ce bug. En 2025, une course critique TOCTOU dans le système de gestion DNS d'Amazon Web Services pour DynamoDB a provoqué une panne majeure dans la région US-EAST-1. L'incident est dû à l'application de plans DNS obsolètes après que les plus récents aient déjà été réhabilités, entraînant la suppression des adresses IP des terminaux et une défaillance généralisée du service ... »
(Traducteur web)

https://fr.wikipedia.org/wiki/Situat...mp%C3%A9tition
Situation de compétition

« Une situation de compétition (ou situation de concurrence, accès concurrent, concurrence critique, course critique, séquencement critique; race condition en anglais [1], littéralement « situation de course »), est une situation caractérisée par un résultat différent selon l'ordre dans lequel agissent les acteurs du système. Le terme est plutôt employé à propos de programmes informatiques et de systèmes électroniques. C'est généralement considéré comme un défaut car source de panne ou de blocage.

Une situation de compétition peut survenir dès que plusieurs acteurs tentent d'accéder au même moment à une ressource partagée (fichier, imprimante, etc.) et qu'au moins l'un d'entre eux est susceptible de modifier son état. Cette définition implique que les systèmes dont les ressources partagées sont immuables (dont l'état ne peut pas changer) soient immunisés contre ce problème.

Les situations de compétition sont des problèmes particulièrement difficiles à identifier et à corriger puisqu'ils ne surviennent qu'à la suite de l'ordonnancement particulier et difficilement reproductible d'une séquence d'évènements.... »

[1]
https://en.wikipedia.org/wiki/Race_condition
0  1