Problème de sécurité préoccupant - potentiellement TRÈS dangereux

http://episteme.arstechnica.com/groupee/fo…/m/698006587731

Décidément, c’est la fête à MacOS ces derniers temps. :heink:

Bien sûr, une intervention de l’utilisateur est toujours nécessaire, mais là, il y a quand même un problème critique qu’Aplle ferait bien de corriger promptement:

"If a script is given an extension such as "jpg" or "mov" and stored within a ZIP archive, Mac OS X will add a binary metadata file to the archive which determines its association. This metafile instructs the operating system on another Mac to open that file with the Terminal application – regardless of its extension or the symbol displayed in the Finder. The Terminal will redirect scripts without an interpreter line directly to bash, the standard shell in OS X."

Il y a effectivement un premier problème: Safari reconnait le fichier comme “sur” et l’execute.

Mais le problème ne vient pas que de Safari, qui ouvre les fichiers de confiance automatiquement, mais de la façon dont ces fichiers sont gérés par le système.
À chaque fichier sont potentiellement attachés des meta-donnés (l’icône si elle est spécifique, l’application à utiliser pour ouvrir le fichier
)

En effet, un simple fichier texte (éventuellement renommé en .jpeg et disposant d’une belle icône) pourra s’executer via le terminal car le fichier en question est reconnu comme executable, alors qu’il n’est pas sensé l’être.

Il y a déjà des solutions de contournement (désactiver l’ouverture automatique des fichiers “sûrs” dans Safari, renommer le terminal en TerminEl.app par exemple…) mais aucune qui soit vraiment satisfaisante en attendant qu’Apple corrige ce problème: un fichier texte qui ne contient pas #!/bin/csh (ou equivalent) en entête ne devrait pas pouvoir s’executer directement dans le terminal sans l’intervention de l’utilisateur.

:ouch:

ah ouais, ça devient du lourd quand même. A propos de la fonction de Safari mise en cause, celle ci avait déjà été pointée du doigt lors de la “faille” des widgets de Tiger (non exploitée heureusement). Apple ferait mieux de commencer à s’attaquer à cette fonction (la virer :ane:) avant de colmater ce que tu décris ici.

Pour une fois je ne suis que partiellement d’accord avec toi.
Le fait d’executer n’importe quel fichier avec n’importe quelle application et que ceci ne soit valable que pour ce fichier est vraiment une fantastique possibilité que j’utilise très souvent. Je ne vois effectivement pas pourquoi le système se baserait sur l’extension ; c’est un procédé archaique que j’ai toujours détesté…

Le problème principal est simplement que le zip contenant le faux jpg est considéré comme sur par safari.

> Le fait d’executer n’importe quel fichier avec n’importe quelle application et que ceci ne soit valable que pour ce fichier est vraiment une fantastique possibilité que j’utilise très souvent.

Tou à fait.

> Je ne vois effectivement pas pourquoi le système se baserait sur l’extension ; c’est un procédé archaique que j’ai toujours détesté…

J’ai jamas dit ça. Les extensions, c’est nul.

> Le problème principal est simplement que le zip contenant le faux jpg est considéré comme sur par safari.

Non, le problème est que le terminal tente d’executer un fichier texte tout à fait normal.
Safari a raison d’ouvrir le fichier (que ce soit un jpg ou un texte) mais le terminal a tord de vouloir interpréter les commandes du fichier texte.

News complète et instructive.Merci Franck

Je m’étais arreté trop tôt dans mon résonnement et j’ai effectivement tort :jap:
Je pensais que le “#!/bin/csh” n’avait aucune importance car dans les 2 cas (avec et sens) le script etait bien executé mais, en ajoutant “#!/bin/csh”, le script est bien vu comme un executable et n’est pas executer automatiquement.

Le principal problème vient donc de la console qui autorise l’execution d’un script “mal formaté”.

Voilà. C’est ça, et Apple a intérêt à corriger ça rapidement. (D’ici demain au plus tard !) :wink:

'tain j’en était sur qu’avec la démocratisation d’OSX Intel on allait en chier…

J’ai pas bien compris les tenants et les aboutissants :ane:
En gros :

On a un script shell mal formé (il manque le shebang) renommé en .jpg.
Safari lit les metadonnées et voit que c’est un script (mais ne detecte pas la malformation), donc le lance avec l’appli associée (le Terminal) et là c’est le drame.
Nan ?

Auquel cas la faute est plutôt au terminal qui ne devrait pas lancer de script sans shebang (à moins de le lancer avec “sh /chemin/du/script.jpg” mais c’est pas le cas là) ?

> 'tain j’en était sur qu’avec la démocratisation d’OSX Intel on allait en chier…

Alors que ça n’a aucun rapport :neutre:

> Safari lit les metadonnées et voit que c’est un script

Non Safari voit un fichier texte (s’il y avait eu un sheband, Safari aurait mis un joli message d’alerte)

> Auquel cas la faute est plutôt au terminal qui ne devrait pas lancer de script sans shebang

C’est tout à fait ça.

Mmmh merci pour les précisions, mais alors, pourquoi Safari passe-t-il le texte au Terminal et pas au bloc-note ? Il y a un flag executable sur le fichier qui se conserve par le protocole de transfert utilisé ?

Pas si sûr :neutre:

La dernière màj de Saft corrige le problème au niveau de Safari, dirait-on