Bonjour les expertes et les experts,
Je me permets déjà de vous souhaiter une bonne année 2005, et une
bonne santé.
Plus important que tout.
Venons en au fait:
ma question est simple: un produit certifié WestCoast Level 1 est-il
un produit qui protège suffisamment ?
Je pense à celui-ci:
http://www.westcoast.com/checkmark/ph_tegam.html
ça aurait pu être un autre bien sur... O:-)
Ce pour demander si un produit qui n'obtient pas la certification de
niveau 2 est-il correct. Je pratique le safe hex, ce qui sous entend
que je suis pas un puriste qui pinaille pour 1% de détection en plus
ou en moins.
Merci de prendre le temps de répondre à cette petite question.
En vous souhaitant une très bonne journée.
Cheers,
Nick Jr III.
Pouvez-vous donner des détails sur : - le test N°6
Appel de la fonction EndTask documentée ici: http://msdn.microsoft.com/library/en-us/winui/winui/windowsuserinterface/windowing/windows/windowreference/windowfunctions/endtask.asp
Donc c'est pas ultrasophistiqué...
En termes de sécurité, c'est une de trop. Que le process soit tué par la méthode 1 ou 26, c'est pareil, le malware emploiera la "bonne" méthode.
Exactement...
Pouvez-vous donner des détails sur :
- le test N°6
Appel de la fonction EndTask documentée ici:
http://msdn.microsoft.com/library/en-us/winui/winui/windowsuserinterface/windowing/windows/windowreference/windowfunctions/endtask.asp
Donc c'est pas ultrasophistiqué...
En termes de sécurité, c'est une de trop. Que le process soit tué par
la méthode 1 ou 26, c'est pareil, le malware emploiera la "bonne"
méthode.
Pouvez-vous donner des détails sur : - le test N°6
Appel de la fonction EndTask documentée ici: http://msdn.microsoft.com/library/en-us/winui/winui/windowsuserinterface/windowing/windows/windowreference/windowfunctions/endtask.asp
Donc c'est pas ultrasophistiqué...
En termes de sécurité, c'est une de trop. Que le process soit tué par la méthode 1 ou 26, c'est pareil, le malware emploiera la "bonne" méthode.
Exactement...
Roland Garcia
Pourtant vous reconnaissez que la protection à 100% n'existe pas. N'est-ce pas ?
Et vous ?
-- Roland Garcia
Pourtant vous reconnaissez que la protection à 100% n'existe pas. N'est-ce
pas ?
Enfin c'est de bonne guerre, pour défendre sa théorie, on doit parfois frôler les limites de la pertinence.
Eviter de sortir d'énormes âneries c'est mieux.
-- Roland Garcia
NickJrIII
"Nicob" a écrit dans le message de news:
On Wed, 19 Jan 2005 17:05:15 +0100, NickJrIII wrote:
Pouvez-vous donner des détails sur : - le test N°6 - les conditions de test : - privilèges du soft soft malveillant - privilèges du process visé - réaction du process visé (popup d'erreur, trace dans les logs)
Je m'exécute: test réalisé sur Windows XP, privilège administrateur pour les deux processus. Le processus cible disparaît du task manager, et de la barre de tâche. Aucun écrit dans le log du logiciel. Cette méthode s'apparente à celle utilisée lors de la fermeture de Windows non ?
Sincèrement, Nick
"Nicob" <nicob@I.hate.spammers.com> a écrit dans le message de news:
pan.2005.01.19.17.32.39.368746@I.hate.spammers.com...
On Wed, 19 Jan 2005 17:05:15 +0100, NickJrIII wrote:
Pouvez-vous donner des détails sur :
- le test N°6
- les conditions de test :
- privilèges du soft soft malveillant
- privilèges du process visé
- réaction du process visé (popup d'erreur, trace dans les logs)
Je m'exécute:
test réalisé sur Windows XP, privilège administrateur pour les deux
processus.
Le processus cible disparaît du task manager, et de la barre de tâche.
Aucun écrit dans le log du logiciel.
Cette méthode s'apparente à celle utilisée lors de la fermeture de Windows
non ?
On Wed, 19 Jan 2005 17:05:15 +0100, NickJrIII wrote:
Pouvez-vous donner des détails sur : - le test N°6 - les conditions de test : - privilèges du soft soft malveillant - privilèges du process visé - réaction du process visé (popup d'erreur, trace dans les logs)
Je m'exécute: test réalisé sur Windows XP, privilège administrateur pour les deux processus. Le processus cible disparaît du task manager, et de la barre de tâche. Aucun écrit dans le log du logiciel. Cette méthode s'apparente à celle utilisée lors de la fermeture de Windows non ?
Sincèrement, Nick
NickJrIII
"Roland Garcia" a écrit dans le message de news:
Enfin c'est de bonne guerre, pour défendre sa théorie, on doit parfois frôler les limites de la pertinence.
Eviter de sortir d'énormes âneries c'est mieux.
Je vais suivre votre conseil. Merci.
Dites moi si je me trompe, mais j'ai l'impression de que vous ne m'aimez pas trop... J'essaie pourtant d'éviter le troll ou les propositions non justifiées, cela malgré mes connaissances lacunaires.
"Roland Garcia" <roland-garcia@wanadoo.fr> a écrit dans le message de news:
41EEA585.6070105@wanadoo.fr...
Enfin c'est de bonne guerre, pour défendre sa théorie, on doit parfois
frôler les limites de la pertinence.
Eviter de sortir d'énormes âneries c'est mieux.
Je vais suivre votre conseil. Merci.
Dites moi si je me trompe, mais j'ai l'impression de que vous ne m'aimez pas
trop...
J'essaie pourtant d'éviter le troll ou les propositions non justifiées, cela
malgré mes connaissances lacunaires.
Enfin c'est de bonne guerre, pour défendre sa théorie, on doit parfois frôler les limites de la pertinence.
Eviter de sortir d'énormes âneries c'est mieux.
Je vais suivre votre conseil. Merci.
Dites moi si je me trompe, mais j'ai l'impression de que vous ne m'aimez pas trop... J'essaie pourtant d'éviter le troll ou les propositions non justifiées, cela malgré mes connaissances lacunaires.
Frederic Bonroy
Si le bloqueur est bien conçu, il bloque l'exécutable.
C'est bien ça la question. Si vous bloquez sur la base d'une liste blanche alors c'est bon (sauf exceptions), si vous bloquez en fonction du comportement alors c'est perdu parce que l'exécutable aura amplement le temps de tenter de terminer le processus du bloqueur. Chose qui n'est pas impossible comme vous l'avez vous-même constaté.
Si le bloqueur est bien écrit, il ne fera que couper l'herbe sous le pied aux virus en sachant où et comment le virus agit. Car tous utilisent souvent les mêmes techniques d'infection (et sur Windows, y'en a pas 36, elles sont connus).
Quand est-ce qu'ils utilisent ces techniques d'infection? Avant ou après avoir terminé le bloqueur? Question rhétorique. :-)
Si cela faillit, virus révolutionnaire par exemple, et bien une nouvelle version sort pour corriger une faille d'analyse comportale.
Si cela faillit surtout la protection 100% s'avèrera être un argument marketing bidon.
Si le bloqueur est bien conçu, il bloque l'exécutable.
C'est bien ça la question. Si vous bloquez sur la base d'une liste
blanche alors c'est bon (sauf exceptions), si vous bloquez en fonction
du comportement alors c'est perdu parce que l'exécutable aura amplement
le temps de tenter de terminer le processus du bloqueur. Chose qui n'est
pas impossible comme vous l'avez vous-même constaté.
Si le bloqueur est bien écrit, il ne fera que couper l'herbe sous le pied
aux virus en sachant où et comment le virus agit. Car tous utilisent souvent
les mêmes techniques d'infection (et sur Windows, y'en a pas 36, elles sont
connus).
Quand est-ce qu'ils utilisent ces techniques d'infection? Avant ou après
avoir terminé le bloqueur? Question rhétorique. :-)
Si cela faillit, virus révolutionnaire par exemple, et bien une nouvelle
version sort pour corriger une faille d'analyse comportale.
Si cela faillit surtout la protection 100% s'avèrera être un argument
marketing bidon.
C'est bien ça la question. Si vous bloquez sur la base d'une liste blanche alors c'est bon (sauf exceptions), si vous bloquez en fonction du comportement alors c'est perdu parce que l'exécutable aura amplement le temps de tenter de terminer le processus du bloqueur. Chose qui n'est pas impossible comme vous l'avez vous-même constaté.
Si le bloqueur est bien écrit, il ne fera que couper l'herbe sous le pied aux virus en sachant où et comment le virus agit. Car tous utilisent souvent les mêmes techniques d'infection (et sur Windows, y'en a pas 36, elles sont connus).
Quand est-ce qu'ils utilisent ces techniques d'infection? Avant ou après avoir terminé le bloqueur? Question rhétorique. :-)
Si cela faillit, virus révolutionnaire par exemple, et bien une nouvelle version sort pour corriger une faille d'analyse comportale.
Si cela faillit surtout la protection 100% s'avèrera être un argument marketing bidon.
NickJrIII
"Nicob" a écrit dans le message de news:
On Wed, 19 Jan 2005 16:37:53 +0100, NickJrIII wrote:
- A supposer qu'un virus anti-ViGUARD tente de fermer le processus de ViGUARD sur un système non sécurisé, la machine va alors planter, ce qui ne permettra pas au virus en question de se propager. Vous pouvez faire vous-même l'essai et fermer le processus de ViGUARD (sdload32.exe) via la barre des tâches sur Windows 95, 98 et ME.
Si on tue le process sous 2K/XP, la machine plante aussi ? Joli DoS, auquel cas.
Je viens de tester, on se trouve avec "accès refusé".
"Nicob" <nicob@I.hate.spammers.com> a écrit dans le message de news:
pan.2005.01.19.17.33.57.236502@I.hate.spammers.com...
On Wed, 19 Jan 2005 16:37:53 +0100, NickJrIII wrote:
- A supposer qu'un virus anti-ViGUARD tente de fermer le processus de
ViGUARD sur un système non sécurisé, la machine va alors planter, ce qui
ne
permettra pas au virus en question de se propager. Vous pouvez faire
vous-même l'essai et fermer le processus de ViGUARD (sdload32.exe) via la
barre des tâches sur Windows 95, 98 et ME.
Si on tue le process sous 2K/XP, la machine plante aussi ?
Joli DoS, auquel cas.
Je viens de tester, on se trouve avec "accès refusé".
On Wed, 19 Jan 2005 16:37:53 +0100, NickJrIII wrote:
- A supposer qu'un virus anti-ViGUARD tente de fermer le processus de ViGUARD sur un système non sécurisé, la machine va alors planter, ce qui ne permettra pas au virus en question de se propager. Vous pouvez faire vous-même l'essai et fermer le processus de ViGUARD (sdload32.exe) via la barre des tâches sur Windows 95, 98 et ME.
Si on tue le process sous 2K/XP, la machine plante aussi ? Joli DoS, auquel cas.
Je viens de tester, on se trouve avec "accès refusé".
Frederic Bonroy
test réalisé sur Windows XP, privilège administrateur pour les deux processus.
Vous pouvez réessayer avec des privilèges "normaux"?
test réalisé sur Windows XP, privilège administrateur pour les deux
processus.
Vous pouvez réessayer avec des privilèges "normaux"?
test réalisé sur Windows XP, privilège administrateur pour les deux processus.
Vous pouvez réessayer avec des privilèges "normaux"?
Roland Garcia
Le problème d'un bloquer qui réagit après le commencement de l'exécution, c'est qu'il réagit après le commencement de l'exécution.
Le problème ? Quel problème ? Si le bloqueur est bien conçu, il bloque l'exécutable.
En cours d'exécution, avant c'est soit de l'heuristique qui est de l'anti-virus, soit de la simple gestion de droits qui n'est pas d l'anti-virus.
Le problème de l'exécution d'un virus est la possible modification de fichiers sains même s'il y a interruption en cours de route par le bloqueur, d'où l'utilisation de contrôleurs d'intégrité pour essayer de réparer tout ça, mais c'est loin de marcher à tous les coups.
Et je pense qu'il l'est.
Bien ou mal concu ne change rien aux grosses limitations de principe.
Ca semble aussi bien, sinon mieux, qu'une analyse par analogie du code viral qui est dépendante de la MAJ. Le risque est plus grand d'avoir une vérole fraichement débarquée, donc non détectée -exception faite de l'heuristique-, que de se trouver en face d'une faille dans un bloqueur bien conçu.
Il n'a jamais été démontré qu'il y ait une grosse différence d'efficacité entre un bloqueur et de l'heuristique.
Si le bloqueur est bien écrit, il ne fera que couper l'herbe sous le pied aux virus en sachant où et comment le virus agit. Car tous utilisent souvent les mêmes techniques d'infection (et sur Windows, y'en a pas 36, elles sont connus).
Si cela faillit, virus révolutionnaire par exemple,
Ou zoo virus anté-diluvien.
et bien une nouvelle version sort pour corriger une faille d'analyse comportale.
CQFD, vous venez de vérifier le théorème de Cohen.
-- Roland Garcia
Le problème d'un bloquer qui réagit après le commencement de l'exécution,
c'est qu'il réagit après le commencement de l'exécution.
Le problème ? Quel problème ?
Si le bloqueur est bien conçu, il bloque l'exécutable.
En cours d'exécution, avant c'est soit de l'heuristique qui est de
l'anti-virus, soit de la simple gestion de droits qui n'est pas d
l'anti-virus.
Le problème de l'exécution d'un virus est la possible modification de
fichiers sains même s'il y a interruption en cours de route par le
bloqueur, d'où l'utilisation de contrôleurs d'intégrité pour essayer de
réparer tout ça, mais c'est loin de marcher à tous les coups.
Et je pense qu'il l'est.
Bien ou mal concu ne change rien aux grosses limitations de principe.
Ca semble aussi bien, sinon mieux, qu'une analyse par analogie du code viral
qui est dépendante de la MAJ.
Le risque est plus grand d'avoir une vérole fraichement débarquée, donc non
détectée -exception faite de l'heuristique-, que de se trouver en face d'une
faille dans un bloqueur bien conçu.
Il n'a jamais été démontré qu'il y ait une grosse différence
d'efficacité entre un bloqueur et de l'heuristique.
Si le bloqueur est bien écrit, il ne fera que couper l'herbe sous le pied
aux virus en sachant où et comment le virus agit. Car tous utilisent souvent
les mêmes techniques d'infection (et sur Windows, y'en a pas 36, elles sont
connus).
Si cela faillit, virus révolutionnaire par exemple,
Ou zoo virus anté-diluvien.
et bien une nouvelle
version sort pour corriger une faille d'analyse comportale.
CQFD, vous venez de vérifier le théorème de Cohen.
Le problème d'un bloquer qui réagit après le commencement de l'exécution, c'est qu'il réagit après le commencement de l'exécution.
Le problème ? Quel problème ? Si le bloqueur est bien conçu, il bloque l'exécutable.
En cours d'exécution, avant c'est soit de l'heuristique qui est de l'anti-virus, soit de la simple gestion de droits qui n'est pas d l'anti-virus.
Le problème de l'exécution d'un virus est la possible modification de fichiers sains même s'il y a interruption en cours de route par le bloqueur, d'où l'utilisation de contrôleurs d'intégrité pour essayer de réparer tout ça, mais c'est loin de marcher à tous les coups.
Et je pense qu'il l'est.
Bien ou mal concu ne change rien aux grosses limitations de principe.
Ca semble aussi bien, sinon mieux, qu'une analyse par analogie du code viral qui est dépendante de la MAJ. Le risque est plus grand d'avoir une vérole fraichement débarquée, donc non détectée -exception faite de l'heuristique-, que de se trouver en face d'une faille dans un bloqueur bien conçu.
Il n'a jamais été démontré qu'il y ait une grosse différence d'efficacité entre un bloqueur et de l'heuristique.
Si le bloqueur est bien écrit, il ne fera que couper l'herbe sous le pied aux virus en sachant où et comment le virus agit. Car tous utilisent souvent les mêmes techniques d'infection (et sur Windows, y'en a pas 36, elles sont connus).
Si cela faillit, virus révolutionnaire par exemple,
Ou zoo virus anté-diluvien.
et bien une nouvelle version sort pour corriger une faille d'analyse comportale.
CQFD, vous venez de vérifier le théorème de Cohen.
