ce pourrait il que ce comportement de cmd soit volontaire, une sorte de mechanism de backdoor demandé a microsoft par la nsa :)
ok je sort.
ce pourrait il que ce comportement de cmd soit volontaire, une sorte de mechanism de backdoor demandé a microsoft par la nsa :)
ok je sort.
La faille est notée top critique à 10/10. Dans la source en anglais, l'équipe Rust remercie le gars qui a découvert la faille et la manière dont il a discrètement informé l'équipe. Et là, hop, on trouve une solution (on a surement retrouvé la documentation...). La fin de l'article ironise même que le gvt US avait peu avant demandé d'utiliser Rust pour une plus grande sécurité. Je n'y trouve pas de mention d'une quelconque mauvaise documentation. Windows procède de la sorte depuis toujours. Toutes les versions de Rust avant le patch qui corrige la faille, donc depuis que Rust existe (10 ans à la grosse louche), il est ridiculement facile d'exploiter cette faille (peut-être découverte par d'autres avant et qui ne l'ont pas dit, on sait pas).
Un gars a fait une démo, où en 3 lignes il parvient a faire s'ouvrir la calculette de Windows via cette faille. Mais on pourrait exécuter n'importe quoi.
L'Equipe de Rust demande d'immédiatement passer à la dernière version. C'est un peu comique pour une équipe qui vante la sécurité de son langage (je ne fais qu'ironiser comme dans la source en anglais), et pour ceux qui se soucie de la sécurité, rien que le fait de devoir passer à la hâte à une autre version, devrait rendre fou les gens qui essayent de bien faire les choses en prenant le temps de validé la nouvelle version avant de l'utiliser (même si ça n'apporte aucun gain technique)...
D'autres langages sont touchés. Mais puisque l'on trouve normal d'utiliser, ... bla bla bla :-)
Vous connaissez mon point de vue... Ah, oui, j'oubliais, le C/C++ ne sont pas concernés ;-)
Peace & Love à tous.
Le cas du logiciel embarqué critique est particulier : on se limite à des OS assez simples avec une API minimale, voire pas d'OS du tout. On a forcément plus de contrôle des détails. Et encore, si tu te retrouves à travailler avec des OS comme VxWorks, ou similaire, je serais surpris que tu analyses systématiquement son comportement dans absolument tous les cas possibles pour t'assurer que la doc est correcte et exhaustive.Citation:
Envoyé par OuftiBoy
Pour le sujet en question, à savoir l'API Win32, c'est hors sujet. Si tu fais de l'embarqué en Rust, tu vas travailler en mode "no_std", où tu n’auras pas non plus de problème avec l'API Win32, vu que la bibliothèque standard est amputée de ses dépendances à l'OS.
Auditer la fiabilité de l'OS ne rentre pas dans le domaine de compétence d'un langage de programmation. Les dev de la bibliothèque standard de Rust ont utilisé l'API standard de Microsoft qu'ils n'avaient aucune raison particulière d'imaginer problématique, comme beaucoup d'autres l'ont fait depuis bien plus longtemps qu'eux sans que personne n'ait vu le problème.Citation:
Envoyé par OuftiBoy
Rust a beau prendre la sécurité au sérieux, ça reste un langage de programmation, il ne prétend pas être un outil magique qui résoudra tous les problèmes de sécurité possible à tous les niveaux.
Tous les gens qui font appels à des fichiers de commande avec des paramètres manipulables par un tiers sont touchés par ce problème sous Windows, que le langage soit directement impliqué ou non :Citation:
Envoyé par OuftiBoy
Les langages qui ont eu des bulletins d’alertes sont ceux qui avaient mis en place une abstraction autour de CreateProcess censé fournir un échappement sécurisé des paramètres. Cet échappement ne fonctionnait pas dans le cas particulier des scripts de commande, ce qu'ils ont du corriger ou documenter.
Pour les langages qui n'ont pas eu de CVE, comme le C et le C++, ça n'est pas parce qu'ils ont anticipé quoi que ce soit, mais au contraire parce qu'ils ne font rien et laissent l'utilisateur appeler CreateProcess directement, ou quasi directement, sans fournir la moindre garantie. Il n'y a en effet rien à corriger au niveau du langage vu que c'est l'utilisateur qui doit faire l'échappement lui même. Cependant, comme le problème n’était pas vraiment connu, pas officiellement documenté, et pas facile à résoudre correctement, il est à peu près certain que aucun des utilisateurs actuels de CreateProcess, dans les cas qui posaient problème en Rust, ne l'utilise de manière sécurisée. Et vu que rien n'a changé pour les langages qui n'encapsulent pas les appel a CreateProcess, il est probable que la situation dure pour leurs utilisateurs, là où Rust protège maintenant contre ce type de problèmes.
J'ai juste pris ça comme exemple de comportement inattendu d'une API (peut importe qu'il soit malicieux ou non), difficile à anticiper, et qui ne constitue qu'un cas parmi une infinité de possibilité. On ne peut pas attendre de l'utilisateur d'une l'API, quelque soit sont niveau de technique, qu'il anticipe tous les cas non documentés possibles, c'est infini. S'il ne peut pas faire confiance au comportement décrit dans la documentation, la seule solution serait d'auditer le code, mais ça n'est clairement pas le boulot du créateur d'un langage, ce n'est même pas possible officiellement dans le cas de l'API Win32.Citation:
Envoyé par OuftiBoy
Justement, alors que le problème existe depuis possiblement 30 ans, il a été découvert en premier sur du Rust, où il a rapidement été rendu inexploitable depuis sa bibliothèque standard. D'un autre coté, Java a décidé de ne rien faire et Microsoft n'a, semble-il à l'heure actuelle, même pas mis à jour sa documentation officielle.Citation:
Envoyé par OuftiBoy
On voit quand même une sacré différence dans la gestion des risques. Pour rappel, Rust n'a jamais prétendu empêcher 100% des failles de sécurité, mais clairement, il prend le problème au sérieux.
CreateProcess est il me semble une fonction historique de l'API Win32, je ne sais pas exactement si elle est présente depuis le tout début de l'API et si elle a toujours permis d’exécuter les fichiers de commande, mais si c'est le cas, ce qui ne me parais pas impossible, ça remonterait au milieu des années 90.Citation:
Envoyé par OuftiBoy
La correction ne s'est certainement pas faite en 5 minutes. Si tu veux une source vraiment intéressante sur le sujet, je te conseille plutôt l'article de la personne qui a signalé la faille.Citation:
Envoyé par OuftiBoy
On voit que le problème a été sérieusement analysé avant d'être corrigé et révélé car il n'est pas si trivial à corriger qu'il n'y parait au premier abord.
Il y explique aussi pourquoi le score de 10/10 est à prendre avec des pincettes.
Ce qui ne veut rien dire en soi, ce n'est qu'un article tiers, absolument pas exhaustif. Par contre c'est assez facile de trouver la doc officielle de CreateProccess. Tu peux y vérifier toi même que la documentation actuelle ne précise rien sur ce qui se passe en cas d’exécution directe de fichiers de commande. Elle indique juste qu'ils peuvent être exécutés indirectement en démarrant soi-même "cmd.exe" avec le paramètre "/c".Citation:
Envoyé par OuftiBoy