@ Sillage

> Comment fais-tu toutes ces mises en forme ?

Via le site web qui autorise quelque tags HTML, dont em, strong, b, i, s et a.
J'ai supprimé l'app de mon iPhone il y a longtemps car elle le faisait chauffer à outrance alors que l'app du Monde par exemple le laisse froid. Cela s'est peut-être amélioré depuis, mais en même temps comme ça ça limite mes visites à quand je suis devant un ordi...

@ gaurejac : « personne ne dit que la faille vient d'AppleDouble en soit »

Si je voulais chipoter, je citerais la première phrase de ton commentaire précédent. 😉
Mais je me contenterai de faire remarquer que ce qui tombe bien, c’est que je n’ai écrit nulle part que personne avait dit ça.

J’ai juste fait remarquer que je trouvais l’article de Microsoft déséquilibré dans sa présentation de la faille, d’autant plus qu’il passe beaucoup de temps à présenter une recherche de comment créer le fichier ._ qui va bien (me donnant une impression de « je découvre AppleDouble ») alors qu’il y existe une méthode très simple pour le créer.

Au passage, ça permet d’éclaircir les choses pour ceux qui, d’après leurs commentaires plus haut, semblent penser que cette faille est compliquée à exploiter à cause du passage de l’article de MacG parlant de « modification manuelle des informations liées à AppleDouble » : non, il n’y a rien de compliqué. Il suffit d’être sur un Mac, de faire un coup de chmod sur l’application qu’on veut distribuer, puis d’en faire un ZIP à placer sur le serveur de distribution. Pas la peine de se prendre la tête comme l’ont fait les gars de Microsoft dans leur article, MacOS règle tous les détails pour nous. 🙂

« mais la faille vient du fait que le traitement des ressources/metadonnées AppleDouble se faisait en priorité et en amont de l'attribution du tag ACL de quarantaine. »

Ce qui est l’ordre normal des choses : on reconstitue d’abord un fichier d’après le contenu de l’archive, avant de le mettre en quarantaine. Si cet attribut de quarantaine était traité de façon spéciale comme il se doit et non comme n’importe quel autre vulgaire attribut étendu, le problème de ne serait pas posé.
À une époque, pour une telle fonction Apple aurait ajouté un attribut supplémentaire à son système de fichiers (en utilisant un des bits marqués comme « réservés pour usage futur » dans HFS+, et en prévoyant directement cet attribut parmi les métadonnées des fichiers lors de la création d’APFS), au lieu d’utiliser un simple attribut étendu puis de se rendre compte au fur et à mesure que ce n’est pas une bien bonne solution pour une fonction de sécurité.

« il est absolument impossible de télécharger un fichier sur internet qui possède déjà des ACL "apple" »

Il est parfaitement possible de télécharger des fichiers conservant leurs ACL Apple sans utiliser le format AppleDouble. Il suffit de les mettre dans une archive dont le format préserve ces ACL. Par exemple le format XAR (plus maintenu mais existant toujours) ou, surtout, une image-disque incluant un système de fichiers Apple. Je ne sais pas si le format Stuffit, dans ses dernières versions, prenait en charge les ACL.
AppleDouble, c’est utilisé pour les formats d’archives venus d’autres OS (ZIP, TAR) et qui, du coup, ne prévoient rien pour les métadonnées de MacOS.

« En gros quand tu dis qu'on pourrait créer manuellement un fichier ._toto sous macOS... »

Euh… je n’ai pas dit ça. Au contraire, j’ai rappelé qu’en préparant l’archive sur MacOS, on n’avait pas besoin de créer manuellement ce fichier.

« ben oui mais non : car après si tu veux transmettre le fichier à une cible tu passes obligatoirement par un serveur avec un filesystem et par des protocoles de transfert (ftp http) qui ignorent ces ACL apple, et ce faisant cassent l'attaque potentielle. »

Ben non : si tu as préparé le fichier ._toto (que ce soit manuellement ou en laissant MacOS faire le boulot), c’est bien pour ensuite le distribuer conjointement avec le fichier toto, dans une archive, permettant aux métadonnées (dont les ACL) de survivre au passage via les divers systèmes de fichiers et protocoles de transfert.

@ gaurejac : « pas d'accord, je trouverais ça dangereux de pouvoir appliquer le tag com.apple.quarantaine quelles que soient les autorisations.
ça semble un peu le meilleur moyen de planter des systèmes entiers : en pouvant appliquer ce tag à tort sur des exécutables indispensables au système. »

Vu comment le système et les exécutables indispensables sont maintenant protégés sur un volume APFS interdit d’écriture, je pense que ce risque n’en est plus un.

« et c'est bien dans l'implémentation de ça qu'il y a un problème, et non pas dans la gestion des ACL en général. »

Je n’ai pas dit que c’était dans la gestion des ACL en général — mais dans la gestion de la quarantaine via un simple attribut étendu, soumis aux ACL dédiées aux attributs étendus.

Et tu le reconnais toi-même implicitement, puisque la solution que tu proposes consiste à contourner ces ACL (en les ignorant le temps d’écrire l’attribut en question).

« La faille concerne ici uniquement la gestion de l'AppleDouble qui applique des attributs à des fichiers téléchargés en amont de l'application du tag quarantaine et pas l'inverse, et c'est ça qui est problématique. »

La faille n’est déclenchée que par cette gestion de l’AppleDouble lors de la décompression parce que les autres cas problèmatiques ont déjà été identifiés et contournés de la même façon (par exemple, la copie, depuis une image-disque en quarantaine, d’un fichier doté des mêmes ACL). Ce que je dis, c’est que si l’attribut dédié à la quarantaine était un peu plus spécial, il n’y aurait pas besoin d’identifier et corriger un par un tous les cas problématiques (au risque d’en oublier, comme ça avait été le cas jusqu’ici pour le cas présenté dans l’article).