Bonjour. Je viens d'effacer de mon disque ce cheval de Troie détecté par
Virus Barrier X. J'ai été averti automatiquement par Otego.
Est-ce que de nombreuses personnes ont eu cette peste, apparue le 10
Mai, et qui est très dangereuse sur OS X, car elle efface
irrémédiablement tout le dossier Users?
http://www.intego.com/news/pr42.html
--
J. Pelmont
http://perso.wanadoo.fr/pelmont/index.html
for mail remove "aky"
Tout programme qui gère des fichiers appelle des fonctions pour créer et parfois supprimer des fichiers, alors tout programme peut potentiellement utiliser l'équivalent de "rm". Essayer de bidouiller l'exécutable rm ne sert ainsi pas à grand chose.
Certes. On ne lutte que contre les scripts. Je pense qu'il est de toute façon impossible de lutter contre les applications.
Si déjà, on élimine les AppleScript « do script shell "rm -r ~" » (je ne connais pas la syntaxe exacte), on lutte contre tous les petits scripts idiots qui circulent actuellement.
Quant aux « vraies » applications et aux « vrais » virus, je pense qu'ils pourront toujours contourner toutes les protections que l'on pourra inventer, unix ou pas unix.
-- R: Parce que ça renverse bêtement l'ordre naturel de lecture! Q: Mais pourquoi citer en fin d'article est-il si effroyable? R: Citer en fin d'article Q: Quelle est la chose la plus désagréable sur les groupes de news?
Éric Lévénez <news@levenez.com> wrote:
Tout programme qui
gère des fichiers appelle des fonctions pour créer et parfois supprimer des
fichiers, alors tout programme peut potentiellement utiliser l'équivalent de
"rm". Essayer de bidouiller l'exécutable rm ne sert ainsi pas à grand chose.
Certes. On ne lutte que contre les scripts. Je pense qu'il est de toute
façon impossible de lutter contre les applications.
Si déjà, on élimine les AppleScript « do script shell "rm -r ~" » (je ne
connais pas la syntaxe exacte), on lutte contre tous les petits scripts
idiots qui circulent actuellement.
Quant aux « vraies » applications et aux « vrais » virus, je pense
qu'ils pourront toujours contourner toutes les protections que l'on
pourra inventer, unix ou pas unix.
--
R: Parce que ça renverse bêtement l'ordre naturel de lecture!
Q: Mais pourquoi citer en fin d'article est-il si effroyable?
R: Citer en fin d'article
Q: Quelle est la chose la plus désagréable sur les groupes de news?
Tout programme qui gère des fichiers appelle des fonctions pour créer et parfois supprimer des fichiers, alors tout programme peut potentiellement utiliser l'équivalent de "rm". Essayer de bidouiller l'exécutable rm ne sert ainsi pas à grand chose.
Certes. On ne lutte que contre les scripts. Je pense qu'il est de toute façon impossible de lutter contre les applications.
Si déjà, on élimine les AppleScript « do script shell "rm -r ~" » (je ne connais pas la syntaxe exacte), on lutte contre tous les petits scripts idiots qui circulent actuellement.
Quant aux « vraies » applications et aux « vrais » virus, je pense qu'ils pourront toujours contourner toutes les protections que l'on pourra inventer, unix ou pas unix.
-- R: Parce que ça renverse bêtement l'ordre naturel de lecture! Q: Mais pourquoi citer en fin d'article est-il si effroyable? R: Citer en fin d'article Q: Quelle est la chose la plus désagréable sur les groupes de news?
lists
Éric Lévénez wrote:
Pas sûr car "rm" doit pouvoir marcher avec un système minimum et pour les AppleEvents, je suppose qu'il faut un démon de lancé pour que cela marche.
On ne peut pas faire un T-vector test pour vérifier que les API AppleEvent sont disponibles ? De plus, AppleEvent en lui-même ne nécessite pas d'interface graphique à mon avis.
Au boot, rm est beaucoup utilisé par le système. Il n'y a pas d'interface graphique à ce moment. De plus unix est multitâche et multiutilisateur, ainsi plusieurs utilisateurs peuvent utiliser "rm" en même temps, mais si la version actuelle de Mac OS X n'en accepte qu'un en mode Aqua (mais n en ssh, telnet, X11...)
Le but est de lutter contre les scripts lancés par un double-clic malheureux, rien de plus et en particulier on est pas en train de parler de la conception d'un antivirus...
Il est évident que dans bien des cas, on ne pourra pas ouvrir une boîte de dialogue. Je dis seulement d'en ouvrir une, lorsque c'est possible.
Dans le cas qui nous préoccupe, (je télécharge un fichier que je crois être une application quelconque, je l'ouvre. En fait, c'était un applescript qui efface tout le dossier Users/moi), l'interface graphique est forcément disponible.
Marchera pas. Cela supposerait que ces chevaux de Troie utilisent le programme "rm" alors qu'il y a l'appel système remove beaucoup plus rapide et qui ne lance pas un process en plus.
C'est sûr. Mais là, on peut pas y faire grand chose.
Sous MacOS 9, on aurait pu patcher FSpDelete ou un truc dans le genre. Il me semble que MacOS X ne permet pas ça (ce qui d'ailleurs n'est peut-être pas plus mal)
-- R: Parce que ça renverse bêtement l'ordre naturel de lecture! Q: Mais pourquoi citer en fin d'article est-il si effroyable? R: Citer en fin d'article Q: Quelle est la chose la plus désagréable sur les groupes de news?
Éric Lévénez <news@levenez.com> wrote:
Pas sûr car "rm" doit pouvoir marcher avec un système minimum et pour les
AppleEvents, je suppose qu'il faut un démon de lancé pour que cela marche.
On ne peut pas faire un T-vector test pour vérifier que les API
AppleEvent sont disponibles ?
De plus, AppleEvent en lui-même ne nécessite pas d'interface graphique à
mon avis.
Au boot, rm est beaucoup utilisé par le système. Il n'y a pas d'interface
graphique à ce moment. De plus unix est multitâche et multiutilisateur,
ainsi plusieurs utilisateurs peuvent utiliser "rm" en même temps, mais si la
version actuelle de Mac OS X n'en accepte qu'un en mode Aqua (mais n en ssh,
telnet, X11...)
Le but est de lutter contre les scripts lancés par un double-clic
malheureux, rien de plus et en particulier on est pas en train de parler
de la conception d'un antivirus...
Il est évident que dans bien des cas, on ne pourra pas ouvrir une boîte
de dialogue. Je dis seulement d'en ouvrir une, lorsque c'est possible.
Dans le cas qui nous préoccupe, (je télécharge un fichier que je crois
être une application quelconque, je l'ouvre. En fait, c'était un
applescript qui efface tout le dossier Users/moi), l'interface graphique
est forcément disponible.
Marchera pas. Cela supposerait que ces chevaux de Troie utilisent le
programme "rm" alors qu'il y a l'appel système remove beaucoup plus rapide
et qui ne lance pas un process en plus.
C'est sûr. Mais là, on peut pas y faire grand chose.
Sous MacOS 9, on aurait pu patcher FSpDelete ou un truc dans le genre.
Il me semble que MacOS X ne permet pas ça (ce qui d'ailleurs n'est
peut-être pas plus mal)
--
R: Parce que ça renverse bêtement l'ordre naturel de lecture!
Q: Mais pourquoi citer en fin d'article est-il si effroyable?
R: Citer en fin d'article
Q: Quelle est la chose la plus désagréable sur les groupes de news?
Pas sûr car "rm" doit pouvoir marcher avec un système minimum et pour les AppleEvents, je suppose qu'il faut un démon de lancé pour que cela marche.
On ne peut pas faire un T-vector test pour vérifier que les API AppleEvent sont disponibles ? De plus, AppleEvent en lui-même ne nécessite pas d'interface graphique à mon avis.
Au boot, rm est beaucoup utilisé par le système. Il n'y a pas d'interface graphique à ce moment. De plus unix est multitâche et multiutilisateur, ainsi plusieurs utilisateurs peuvent utiliser "rm" en même temps, mais si la version actuelle de Mac OS X n'en accepte qu'un en mode Aqua (mais n en ssh, telnet, X11...)
Le but est de lutter contre les scripts lancés par un double-clic malheureux, rien de plus et en particulier on est pas en train de parler de la conception d'un antivirus...
Il est évident que dans bien des cas, on ne pourra pas ouvrir une boîte de dialogue. Je dis seulement d'en ouvrir une, lorsque c'est possible.
Dans le cas qui nous préoccupe, (je télécharge un fichier que je crois être une application quelconque, je l'ouvre. En fait, c'était un applescript qui efface tout le dossier Users/moi), l'interface graphique est forcément disponible.
Marchera pas. Cela supposerait que ces chevaux de Troie utilisent le programme "rm" alors qu'il y a l'appel système remove beaucoup plus rapide et qui ne lance pas un process en plus.
C'est sûr. Mais là, on peut pas y faire grand chose.
Sous MacOS 9, on aurait pu patcher FSpDelete ou un truc dans le genre. Il me semble que MacOS X ne permet pas ça (ce qui d'ailleurs n'est peut-être pas plus mal)
-- R: Parce que ça renverse bêtement l'ordre naturel de lecture! Q: Mais pourquoi citer en fin d'article est-il si effroyable? R: Citer en fin d'article Q: Quelle est la chose la plus désagréable sur les groupes de news?
Éric Lévénez
Le 22/05/04 13:54, dans <1ge6wr2.1gc5314pr2ducN%, « Julien Salort » a écrit :
Éric Lévénez wrote:
Tout programme qui gère des fichiers appelle des fonctions pour créer et parfois supprimer des fichiers, alors tout programme peut potentiellement utiliser l'équivalent de "rm". Essayer de bidouiller l'exécutable rm ne sert ainsi pas à grand chose.
Certes. On ne lutte que contre les scripts. Je pense qu'il est de toute façon impossible de lutter contre les applications.
Un script est une application non binaire.
Si déjà, on élimine les AppleScript « do script shell "rm -r ~" » (je ne connais pas la syntaxe exacte), on lutte contre tous les petits scripts idiots qui circulent actuellement.
Non. En perl ou en tout langage on peut faire des rm. La seule façon de ne pas effacer son disque dur est de ne pas lancer n'importe quelle appli trouvée sur le net.
Quant aux « vraies » applications et aux « vrais » virus, je pense qu'ils pourront toujours contourner toutes les protections que l'on pourra inventer, unix ou pas unix.
Le problème n'est pas sur les virus, mais sur les applications trouvées sur Internet et lancées manuellement par l'utilisateur.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 22/05/04 13:54, dans <1ge6wr2.1gc5314pr2ducN%lists@juliensalort.org>,
« Julien Salort » <lists@juliensalort.org> a écrit :
Éric Lévénez <news@levenez.com> wrote:
Tout programme qui
gère des fichiers appelle des fonctions pour créer et parfois supprimer des
fichiers, alors tout programme peut potentiellement utiliser l'équivalent de
"rm". Essayer de bidouiller l'exécutable rm ne sert ainsi pas à grand chose.
Certes. On ne lutte que contre les scripts. Je pense qu'il est de toute
façon impossible de lutter contre les applications.
Un script est une application non binaire.
Si déjà, on élimine les AppleScript « do script shell "rm -r ~" » (je ne
connais pas la syntaxe exacte), on lutte contre tous les petits scripts
idiots qui circulent actuellement.
Non. En perl ou en tout langage on peut faire des rm. La seule façon de ne
pas effacer son disque dur est de ne pas lancer n'importe quelle appli
trouvée sur le net.
Quant aux « vraies » applications et aux « vrais » virus, je pense
qu'ils pourront toujours contourner toutes les protections que l'on
pourra inventer, unix ou pas unix.
Le problème n'est pas sur les virus, mais sur les applications trouvées sur
Internet et lancées manuellement par l'utilisateur.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 22/05/04 13:54, dans <1ge6wr2.1gc5314pr2ducN%, « Julien Salort » a écrit :
Éric Lévénez wrote:
Tout programme qui gère des fichiers appelle des fonctions pour créer et parfois supprimer des fichiers, alors tout programme peut potentiellement utiliser l'équivalent de "rm". Essayer de bidouiller l'exécutable rm ne sert ainsi pas à grand chose.
Certes. On ne lutte que contre les scripts. Je pense qu'il est de toute façon impossible de lutter contre les applications.
Un script est une application non binaire.
Si déjà, on élimine les AppleScript « do script shell "rm -r ~" » (je ne connais pas la syntaxe exacte), on lutte contre tous les petits scripts idiots qui circulent actuellement.
Non. En perl ou en tout langage on peut faire des rm. La seule façon de ne pas effacer son disque dur est de ne pas lancer n'importe quelle appli trouvée sur le net.
Quant aux « vraies » applications et aux « vrais » virus, je pense qu'ils pourront toujours contourner toutes les protections que l'on pourra inventer, unix ou pas unix.
Le problème n'est pas sur les virus, mais sur les applications trouvées sur Internet et lancées manuellement par l'utilisateur.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Éric Lévénez
Le 22/05/04 13:54, dans <1ge6wyl.1a1y57c1kqqkn4N%, « Julien Salort » a écrit :
Éric Lévénez wrote:
Pas sûr car "rm" doit pouvoir marcher avec un système minimum et pour les AppleEvents, je suppose qu'il faut un démon de lancé pour que cela marche.
On ne peut pas faire un T-vector test pour vérifier que les API AppleEvent sont disponibles ? De plus, AppleEvent en lui-même ne nécessite pas d'interface graphique à mon avis.
J'ai parlé de démon, pas d'interface graphique. Je ne vois pas l'intérêt de réécrire "rm" alors qu'il existe des dizaines de façon d'effacer des fichiers ou des les véroler sans utiliser "rm".
Au boot, rm est beaucoup utilisé par le système. Il n'y a pas d'interface graphique à ce moment. De plus unix est multitâche et multiutilisateur, ainsi plusieurs utilisateurs peuvent utiliser "rm" en même temps, mais si la version actuelle de Mac OS X n'en accepte qu'un en mode Aqua (mais n en ssh, telnet, X11...)
Le but est de lutter contre les scripts lancés par un double-clic malheureux, rien de plus et en particulier on est pas en train de parler de la conception d'un antivirus...
Non, ce problème n'a rien à voir avec un virus mais avec un cheval de Troie. Quand les utilisateurs arrêterons de cliquer sur tout ce qu'ils trouvent sur Internet, le problème sera résolu.
Il est évident que dans bien des cas, on ne pourra pas ouvrir une boîte de dialogue. Je dis seulement d'en ouvrir une, lorsque c'est possible.
Toute commande unix est potentiellement dangereuse. Tu n'as pas l'air de voir le nombre de façon d'effacer un fichier sous unix. "rm" est le bout de l'iceberg qui cache la forêt :-)
Dans le cas qui nous préoccupe, (je télécharge un fichier que je crois être une application quelconque, je l'ouvre. En fait, c'était un applescript qui efface tout le dossier Users/moi), l'interface graphique est forcément disponible.
Si tu lances n'importe quoi, c'est ton problème. Et pourquoi penses-tu qu'une application malveillante va sagement appeler ton "rm" que tu as "sécurisé" ? Ne penses-tu pas que le b.a.ba du cracker est justement de ne pas faire ce genre de bêtise.
Marchera pas. Cela supposerait que ces chevaux de Troie utilisent le programme "rm" alors qu'il y a l'appel système remove beaucoup plus rapide et qui ne lance pas un process en plus.
C'est sûr. Mais là, on peut pas y faire grand chose.
Voilà.
Sous MacOS 9, on aurait pu patcher FSpDelete ou un truc dans le genre. Il me semble que MacOS X ne permet pas ça (ce qui d'ailleurs n'est peut-être pas plus mal)
Je suppose et j'espère que ce n'est pas possible. Mais si cela l'était pourquoi un cheval de Troie ne patcherait pas ton patch ? Hein ? :-)
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 22/05/04 13:54, dans <1ge6wyl.1a1y57c1kqqkn4N%lists@juliensalort.org>,
« Julien Salort » <lists@juliensalort.org> a écrit :
Éric Lévénez <news@levenez.com> wrote:
Pas sûr car "rm" doit pouvoir marcher avec un système minimum et pour les
AppleEvents, je suppose qu'il faut un démon de lancé pour que cela marche.
On ne peut pas faire un T-vector test pour vérifier que les API
AppleEvent sont disponibles ?
De plus, AppleEvent en lui-même ne nécessite pas d'interface graphique à
mon avis.
J'ai parlé de démon, pas d'interface graphique. Je ne vois pas l'intérêt de
réécrire "rm" alors qu'il existe des dizaines de façon d'effacer des
fichiers ou des les véroler sans utiliser "rm".
Au boot, rm est beaucoup utilisé par le système. Il n'y a pas d'interface
graphique à ce moment. De plus unix est multitâche et multiutilisateur,
ainsi plusieurs utilisateurs peuvent utiliser "rm" en même temps, mais si la
version actuelle de Mac OS X n'en accepte qu'un en mode Aqua (mais n en ssh,
telnet, X11...)
Le but est de lutter contre les scripts lancés par un double-clic
malheureux, rien de plus et en particulier on est pas en train de parler
de la conception d'un antivirus...
Non, ce problème n'a rien à voir avec un virus mais avec un cheval de Troie.
Quand les utilisateurs arrêterons de cliquer sur tout ce qu'ils trouvent sur
Internet, le problème sera résolu.
Il est évident que dans bien des cas, on ne pourra pas ouvrir une boîte
de dialogue. Je dis seulement d'en ouvrir une, lorsque c'est possible.
Toute commande unix est potentiellement dangereuse. Tu n'as pas l'air de
voir le nombre de façon d'effacer un fichier sous unix. "rm" est le bout de
l'iceberg qui cache la forêt :-)
Dans le cas qui nous préoccupe, (je télécharge un fichier que je crois
être une application quelconque, je l'ouvre. En fait, c'était un
applescript qui efface tout le dossier Users/moi), l'interface graphique
est forcément disponible.
Si tu lances n'importe quoi, c'est ton problème. Et pourquoi penses-tu
qu'une application malveillante va sagement appeler ton "rm" que tu as
"sécurisé" ? Ne penses-tu pas que le b.a.ba du cracker est justement de ne
pas faire ce genre de bêtise.
Marchera pas. Cela supposerait que ces chevaux de Troie utilisent le
programme "rm" alors qu'il y a l'appel système remove beaucoup plus rapide
et qui ne lance pas un process en plus.
C'est sûr. Mais là, on peut pas y faire grand chose.
Voilà.
Sous MacOS 9, on aurait pu patcher FSpDelete ou un truc dans le genre.
Il me semble que MacOS X ne permet pas ça (ce qui d'ailleurs n'est
peut-être pas plus mal)
Je suppose et j'espère que ce n'est pas possible. Mais si cela l'était
pourquoi un cheval de Troie ne patcherait pas ton patch ? Hein ? :-)
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 22/05/04 13:54, dans <1ge6wyl.1a1y57c1kqqkn4N%, « Julien Salort » a écrit :
Éric Lévénez wrote:
Pas sûr car "rm" doit pouvoir marcher avec un système minimum et pour les AppleEvents, je suppose qu'il faut un démon de lancé pour que cela marche.
On ne peut pas faire un T-vector test pour vérifier que les API AppleEvent sont disponibles ? De plus, AppleEvent en lui-même ne nécessite pas d'interface graphique à mon avis.
J'ai parlé de démon, pas d'interface graphique. Je ne vois pas l'intérêt de réécrire "rm" alors qu'il existe des dizaines de façon d'effacer des fichiers ou des les véroler sans utiliser "rm".
Au boot, rm est beaucoup utilisé par le système. Il n'y a pas d'interface graphique à ce moment. De plus unix est multitâche et multiutilisateur, ainsi plusieurs utilisateurs peuvent utiliser "rm" en même temps, mais si la version actuelle de Mac OS X n'en accepte qu'un en mode Aqua (mais n en ssh, telnet, X11...)
Le but est de lutter contre les scripts lancés par un double-clic malheureux, rien de plus et en particulier on est pas en train de parler de la conception d'un antivirus...
Non, ce problème n'a rien à voir avec un virus mais avec un cheval de Troie. Quand les utilisateurs arrêterons de cliquer sur tout ce qu'ils trouvent sur Internet, le problème sera résolu.
Il est évident que dans bien des cas, on ne pourra pas ouvrir une boîte de dialogue. Je dis seulement d'en ouvrir une, lorsque c'est possible.
Toute commande unix est potentiellement dangereuse. Tu n'as pas l'air de voir le nombre de façon d'effacer un fichier sous unix. "rm" est le bout de l'iceberg qui cache la forêt :-)
Dans le cas qui nous préoccupe, (je télécharge un fichier que je crois être une application quelconque, je l'ouvre. En fait, c'était un applescript qui efface tout le dossier Users/moi), l'interface graphique est forcément disponible.
Si tu lances n'importe quoi, c'est ton problème. Et pourquoi penses-tu qu'une application malveillante va sagement appeler ton "rm" que tu as "sécurisé" ? Ne penses-tu pas que le b.a.ba du cracker est justement de ne pas faire ce genre de bêtise.
Marchera pas. Cela supposerait que ces chevaux de Troie utilisent le programme "rm" alors qu'il y a l'appel système remove beaucoup plus rapide et qui ne lance pas un process en plus.
C'est sûr. Mais là, on peut pas y faire grand chose.
Voilà.
Sous MacOS 9, on aurait pu patcher FSpDelete ou un truc dans le genre. Il me semble que MacOS X ne permet pas ça (ce qui d'ailleurs n'est peut-être pas plus mal)
Je suppose et j'espère que ce n'est pas possible. Mais si cela l'était pourquoi un cheval de Troie ne patcherait pas ton patch ? Hein ? :-)
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Saïd
Éric Lévénez :
Non. En perl ou en tout langage on peut faire des rm. La seule façon de ne pas effacer son disque dur est de ne pas lancer n'importe quelle appli trouvée sur le net.
Certes certes. Mais la Apple donne un moyen a n'importe quel page web de lancer une application (je ne parle du troyen MS Office). C'est vraiment de l'irresponsabilite.
Sur cette page <http://www.unsanity.com/haxies/pa/whitepaper/> on trouve le passage suivant: ********* An example is a link titled ?Click this to receive your free radio!?, which, instead of giving the user a free radio, mounts malware onto his computer. I don't believe that Apple should try to protect against this type of infection because this is a social and educational issue, not a technical one. "You can't protect users against their own stupidity." *********
Je ne suis pas d'accord avec la conclusion. Avant de monter un volume exteieur l'utilisateur doit avoir donné son accord explicite par l'intermediaire d'une fenetre qui dit exactement ce qui va se passer. La stupidite en l'occurence elle ne vient pas de l'utilisateur mais de chez Apple. Le systeme ne doit pas laisser le soin aux pages webs d'expliquer ce qu'elles font quand il s'agit de quelque chose d'aussi important que le montage d'un volume.
Sans parler du reste de la faille expliquée qui est une preuve d'irresponsabilite complete de la part d'Apple. (Le systeme monte des volumes externes sans demander l'avis explicite de l'utilisateur. Il fait confiance a ces volumes pour redefinir un protocole. Et lance une application qui se trouve sur le volume externe en suivant les indication contenue dans l'application presente sur un disque externe. Chapeau!)
-- Saïd.
Éric Lévénez :
Non. En perl ou en tout langage on peut faire des rm. La seule façon de ne
pas effacer son disque dur est de ne pas lancer n'importe quelle appli
trouvée sur le net.
Certes certes. Mais la Apple donne un moyen a n'importe quel page web de
lancer une application (je ne parle du troyen MS Office). C'est vraiment de
l'irresponsabilite.
Sur cette page <http://www.unsanity.com/haxies/pa/whitepaper/> on trouve
le passage suivant:
*********
An example is a link titled ?Click this to receive your free radio!?, which,
instead of giving the user a free radio, mounts malware onto his computer. I
don't believe that Apple should try to protect against this type of
infection because this is a social and educational issue, not a technical
one. "You can't protect users against their own stupidity."
*********
Je ne suis pas d'accord avec la conclusion. Avant de monter un volume
exteieur l'utilisateur doit avoir donné son accord explicite par
l'intermediaire d'une fenetre qui dit exactement ce qui va se passer. La
stupidite en l'occurence elle ne vient pas de l'utilisateur mais de chez
Apple. Le systeme ne doit pas laisser le soin aux pages webs d'expliquer ce
qu'elles font quand il s'agit de quelque chose d'aussi important que le
montage d'un volume.
Sans parler du reste de la faille expliquée qui est une preuve
d'irresponsabilite complete de la part d'Apple. (Le systeme monte des
volumes externes sans demander l'avis explicite de l'utilisateur. Il fait
confiance a ces volumes pour redefinir un protocole. Et lance une
application qui se trouve sur le volume externe en suivant les indication
contenue dans l'application presente sur un disque externe. Chapeau!)
Non. En perl ou en tout langage on peut faire des rm. La seule façon de ne pas effacer son disque dur est de ne pas lancer n'importe quelle appli trouvée sur le net.
Certes certes. Mais la Apple donne un moyen a n'importe quel page web de lancer une application (je ne parle du troyen MS Office). C'est vraiment de l'irresponsabilite.
Sur cette page <http://www.unsanity.com/haxies/pa/whitepaper/> on trouve le passage suivant: ********* An example is a link titled ?Click this to receive your free radio!?, which, instead of giving the user a free radio, mounts malware onto his computer. I don't believe that Apple should try to protect against this type of infection because this is a social and educational issue, not a technical one. "You can't protect users against their own stupidity." *********
Je ne suis pas d'accord avec la conclusion. Avant de monter un volume exteieur l'utilisateur doit avoir donné son accord explicite par l'intermediaire d'une fenetre qui dit exactement ce qui va se passer. La stupidite en l'occurence elle ne vient pas de l'utilisateur mais de chez Apple. Le systeme ne doit pas laisser le soin aux pages webs d'expliquer ce qu'elles font quand il s'agit de quelque chose d'aussi important que le montage d'un volume.
Sans parler du reste de la faille expliquée qui est une preuve d'irresponsabilite complete de la part d'Apple. (Le systeme monte des volumes externes sans demander l'avis explicite de l'utilisateur. Il fait confiance a ces volumes pour redefinir un protocole. Et lance une application qui se trouve sur le volume externe en suivant les indication contenue dans l'application presente sur un disque externe. Chapeau!)
-- Saïd.
Éric Lévénez
Le 22/05/04 15:09, dans , « Saïd » a écrit :
Éric Lévénez :
Non. En perl ou en tout langage on peut faire des rm. La seule façon de ne pas effacer son disque dur est de ne pas lancer n'importe quelle appli trouvée sur le net.
Certes certes. Mais la Apple donne un moyen a n'importe quel page web de lancer une application (je ne parle du troyen MS Office). C'est vraiment de l'irresponsabilite.
C'est un tout autre problème, et là c'est un très gros problème effectivement.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 22/05/04 15:09, dans <slrncauk93.6lp.said@brian.lan>, « Saïd »
<said@brian.lan> a écrit :
Éric Lévénez :
Non. En perl ou en tout langage on peut faire des rm. La seule façon de ne
pas effacer son disque dur est de ne pas lancer n'importe quelle appli
trouvée sur le net.
Certes certes. Mais la Apple donne un moyen a n'importe quel page web de
lancer une application (je ne parle du troyen MS Office). C'est vraiment de
l'irresponsabilite.
C'est un tout autre problème, et là c'est un très gros problème
effectivement.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Non. En perl ou en tout langage on peut faire des rm. La seule façon de ne pas effacer son disque dur est de ne pas lancer n'importe quelle appli trouvée sur le net.
Certes certes. Mais la Apple donne un moyen a n'importe quel page web de lancer une application (je ne parle du troyen MS Office). C'est vraiment de l'irresponsabilite.
C'est un tout autre problème, et là c'est un très gros problème effectivement.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Patrick Stadelmann
In article , Saïd wrote:
Le systeme ne doit pas laisser le soin aux pages webs d'expliquer ce qu'elles font quand il s'agit de quelque chose d'aussi important que le montage d'un volume.
Les liens qui montent des volumes, c'est pas nouveau : afp, smb, ftp ... le font tous, le problème n'est pas là. Un volume monté ne doit pas être dangereux en soit (pas plus que ne doit l'être un CD ou une image disque). Le problème est dans la gestion des applications associées aux divers protocole.
Patrick -- Patrick Stadelmann
In article <slrncauk93.6lp.said@brian.lan>, Saïd <said@brian.lan>
wrote:
Le systeme ne doit pas laisser le soin aux pages webs d'expliquer ce
qu'elles font quand il s'agit de quelque chose d'aussi important que le
montage d'un volume.
Les liens qui montent des volumes, c'est pas nouveau : afp, smb, ftp ...
le font tous, le problème n'est pas là. Un volume monté ne doit pas être
dangereux en soit (pas plus que ne doit l'être un CD ou une image
disque). Le problème est dans la gestion des applications associées aux
divers protocole.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
Le systeme ne doit pas laisser le soin aux pages webs d'expliquer ce qu'elles font quand il s'agit de quelque chose d'aussi important que le montage d'un volume.
Les liens qui montent des volumes, c'est pas nouveau : afp, smb, ftp ... le font tous, le problème n'est pas là. Un volume monté ne doit pas être dangereux en soit (pas plus que ne doit l'être un CD ou une image disque). Le problème est dans la gestion des applications associées aux divers protocole.
