Les résultats du premier test, Windows 8 sans Windows Defender, sont sans appel : 234 menaces se sont exécutées, soit 61 % des malwares, 138 autres (36 %) n’ont pas pu être lancées sur la machine pour diverses raisons
Les résultats du premier test, Windows 8 sans Windows Defender, sont
sans appel : 234 menaces se sont exécutées, soit 61 % des malwares, 138
autres (36 %) n’ont pas pu être lancées sur la machine pour diverses raisons
Les résultats du premier test, Windows 8 sans Windows Defender, sont sans appel : 234 menaces se sont exécutées, soit 61 % des malwares, 138 autres (36 %) n’ont pas pu être lancées sur la machine pour diverses raisons
Les résultats du premier test, Windows 8 sans Windows Defender, sont sans appel : 234 menaces se sont exécutées, soit 61 % des malwares, 138 autres (36 %) n’ont pas pu être lancées sur la machine pour diverses raisons
Et la certains pourront pas dire que windows 8 est installé sur tous les PC et que c'est a cause de ça qu'il y a des virus.
Les résultats du premier test, Windows 8 sans Windows Defender, sont
sans appel : 234 menaces se sont exécutées, soit 61 % des malwares, 138
autres (36 %) n’ont pas pu être lancées sur la machine pour diverses
raisons
Et la certains pourront pas dire que windows 8 est installé sur tous les
PC et que c'est a cause de ça qu'il y a des virus.
Les résultats du premier test, Windows 8 sans Windows Defender, sont sans appel : 234 menaces se sont exécutées, soit 61 % des malwares, 138 autres (36 %) n’ont pas pu être lancées sur la machine pour diverses raisons
Et la certains pourront pas dire que windows 8 est installé sur tous les PC et que c'est a cause de ça qu'il y a des virus.
Yliur
Le Wed, 21 Nov 2012 23:49:08 +0100 lunix a écrit :
[...] 234 menaces se sont exécutées, soit 61 % des malwares, 138 autres (36 %) n’ont pas pu être lancées sur la machine pour diverses raisons
Elle a planté avant ?
Le Wed, 21 Nov 2012 23:49:08 +0100
lunix <local@local> a écrit :
[...] 234 menaces se sont exécutées, soit 61 % des malwares,
138 autres (36 %) n’ont pas pu être lancées sur la machine pour
diverses raisons
"On a default Debian squeeze install, /etc/rc.local ends in an exit 0 command, so that the rootkit is effectively never loaded."
En fait, personne sait trop ... Il faut apparemment un accès root pour l'installer, un noyau 2.6.32-5 et un serveur nginx. Et encore, il n'arrive pas à cacher ses process, il n'arrive pas à se rendre persistant à un reboot etc ...
"On a default Debian squeeze install, /etc/rc.local ends in an exit 0
command, so that the rootkit is effectively never loaded."
En fait, personne sait trop ... Il faut apparemment un accès root pour
l'installer, un noyau 2.6.32-5 et un serveur nginx. Et encore, il
n'arrive pas à cacher ses process, il n'arrive pas à se rendre
persistant à un reboot etc ...
"On a default Debian squeeze install, /etc/rc.local ends in an exit 0 command, so that the rootkit is effectively never loaded."
En fait, personne sait trop ... Il faut apparemment un accès root pour l'installer, un noyau 2.6.32-5 et un serveur nginx. Et encore, il n'arrive pas à cacher ses process, il n'arrive pas à se rendre persistant à un reboot etc ...
Il est loin encore le temps du Linux qui concurrencera Windows en termes de saloperies installables ...
-- Le mode sans échec de Windows est la preuve que son mode normal est un échec !
SONY : It only does everything ... until we remove ! PS3 Firmware update 3.21 : The first software update which downgrade !
Doug713705
Le 22-11-2012, NiKo nous expliquait dans fr.comp.os.linux.debats :
"On a default Debian squeeze install, /etc/rc.local ends in an exit 0 command, so that the rootkit is effectively never loaded."
En fait, personne sait trop ... Il faut apparemment un accès root pour l'installer, un noyau 2.6.32-5 et un serveur nginx. Et encore, il n'arrive pas à cacher ses process, il n'arrive pas à se rendre persistant à un reboot etc ...
En tant que tel il n'y a rien d'étonnant à ce qu'un programme exécuté en kernel land puisse mettre la bazar sur un système, quel qu'il soit.
Il serait plus judicieux de savoir _comment_ ce rootkit est arrivé sur la machine en question car c'est là qu'est le vrai problème.
Comme trop souvent de nos jours on ne regarde que la surface des choses.
Évidemment, le P4, dont la profondeur d'analyse est reconnue de tous, s'agite au moindre pet de mouche sans même essayer de comprendre pourquoi la mouche a péter.
Tiens, pour la peine : http://www.youtube.com/watch?v=OKobbtAzZCI
-- Doug - Linux user #307925 - Slackware64 roulaize ;-) Without freedom of choice there is no creativity. -- Kirk, "The return of the Archons", stardate 3157.4
Le 22-11-2012, NiKo nous expliquait dans fr.comp.os.linux.debats :
"On a default Debian squeeze install, /etc/rc.local ends in an exit 0
command, so that the rootkit is effectively never loaded."
En fait, personne sait trop ... Il faut apparemment un accès root pour
l'installer, un noyau 2.6.32-5 et un serveur nginx. Et encore, il
n'arrive pas à cacher ses process, il n'arrive pas à se rendre
persistant à un reboot etc ...
En tant que tel il n'y a rien d'étonnant à ce qu'un programme exécuté en
kernel land puisse mettre la bazar sur un système, quel qu'il soit.
Il serait plus judicieux de savoir _comment_ ce rootkit est arrivé
sur la machine en question car c'est là qu'est le vrai problème.
Comme trop souvent de nos jours on ne regarde que la surface des choses.
Évidemment, le P4, dont la profondeur d'analyse est reconnue de tous,
s'agite au moindre pet de mouche sans même essayer de comprendre
pourquoi la mouche a péter.
Tiens, pour la peine :
http://www.youtube.com/watch?v=OKobbtAzZCI
--
Doug - Linux user #307925 - Slackware64 roulaize ;-)
Without freedom of choice there is no creativity.
-- Kirk, "The return of the Archons", stardate 3157.4
Le 22-11-2012, NiKo nous expliquait dans fr.comp.os.linux.debats :
"On a default Debian squeeze install, /etc/rc.local ends in an exit 0 command, so that the rootkit is effectively never loaded."
En fait, personne sait trop ... Il faut apparemment un accès root pour l'installer, un noyau 2.6.32-5 et un serveur nginx. Et encore, il n'arrive pas à cacher ses process, il n'arrive pas à se rendre persistant à un reboot etc ...
En tant que tel il n'y a rien d'étonnant à ce qu'un programme exécuté en kernel land puisse mettre la bazar sur un système, quel qu'il soit.
Il serait plus judicieux de savoir _comment_ ce rootkit est arrivé sur la machine en question car c'est là qu'est le vrai problème.
Comme trop souvent de nos jours on ne regarde que la surface des choses.
Évidemment, le P4, dont la profondeur d'analyse est reconnue de tous, s'agite au moindre pet de mouche sans même essayer de comprendre pourquoi la mouche a péter.
Tiens, pour la peine : http://www.youtube.com/watch?v=OKobbtAzZCI
-- Doug - Linux user #307925 - Slackware64 roulaize ;-) Without freedom of choice there is no creativity. -- Kirk, "The return of the Archons", stardate 3157.4
Emmanuel Florac
Le Thu, 22 Nov 2012 20:26:37 +1100, Doug713705 a écrit:
Il serait plus judicieux de savoir _comment_ ce rootkit est arrivé sur la machine en question car c'est là qu'est le vrai problème.
Apparemment ça utilise une faille nginx. Si on n'utilise pas nginx, on est apparemment immunisé.
-- There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. C.A.R. Hoare.
Le Thu, 22 Nov 2012 20:26:37 +1100, Doug713705 a écrit:
Il serait plus judicieux de savoir _comment_ ce rootkit est arrivé sur
la machine en question car c'est là qu'est le vrai problème.
Apparemment ça utilise une faille nginx. Si on n'utilise pas nginx, on
est apparemment immunisé.
--
There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult.
C.A.R. Hoare.
Le Thu, 22 Nov 2012 20:26:37 +1100, Doug713705 a écrit:
Il serait plus judicieux de savoir _comment_ ce rootkit est arrivé sur la machine en question car c'est là qu'est le vrai problème.
Apparemment ça utilise une faille nginx. Si on n'utilise pas nginx, on est apparemment immunisé.
-- There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. C.A.R. Hoare.
Kevin Denis
Le 22-11-2012, Emmanuel Florac a écrit :
Il serait plus judicieux de savoir _comment_ ce rootkit est arrivé sur la machine en question car c'est là qu'est le vrai problème.
Apparemment ça utilise une faille nginx. Si on n'utilise pas nginx, on est apparemment immunisé.
Des news là dessus? -- Kevin
Le 22-11-2012, Emmanuel Florac <eflorac@imaginet.fr> a écrit :
Il serait plus judicieux de savoir _comment_ ce rootkit est arrivé sur
la machine en question car c'est là qu'est le vrai problème.
Apparemment ça utilise une faille nginx. Si on n'utilise pas nginx, on
est apparemment immunisé.
Il serait plus judicieux de savoir _comment_ ce rootkit est arrivé sur la machine en question car c'est là qu'est le vrai problème.
Apparemment ça utilise une faille nginx. Si on n'utilise pas nginx, on est apparemment immunisé.
Des news là dessus? -- Kevin
Kevin Denis
Le 22-11-2012, Doug713705 a écrit :
En tant que tel il n'y a rien d'étonnant à ce qu'un programme exécuté en kernel land puisse mettre la bazar sur un système, quel qu'il soit.
Il serait plus judicieux de savoir _comment_ ce rootkit est arrivé sur la machine en question car c'est là qu'est le vrai problème.
Comme le faisait remarquer je ne sais plus qui, la véritable info, dans cette histoire, c'est que les pirates commencent à coder "réellement" sous linux et non plus scripter des trucs à 3 balles. -- Kevin
Le 22-11-2012, Doug713705 <doug.letough@free.fr> a écrit :
En tant que tel il n'y a rien d'étonnant à ce qu'un programme exécuté en
kernel land puisse mettre la bazar sur un système, quel qu'il soit.
Il serait plus judicieux de savoir _comment_ ce rootkit est arrivé
sur la machine en question car c'est là qu'est le vrai problème.
Comme le faisait remarquer je ne sais plus qui, la véritable info, dans
cette histoire, c'est que les pirates commencent à coder "réellement"
sous linux et non plus scripter des trucs à 3 balles.
--
Kevin
En tant que tel il n'y a rien d'étonnant à ce qu'un programme exécuté en kernel land puisse mettre la bazar sur un système, quel qu'il soit.
Il serait plus judicieux de savoir _comment_ ce rootkit est arrivé sur la machine en question car c'est là qu'est le vrai problème.
Comme le faisait remarquer je ne sais plus qui, la véritable info, dans cette histoire, c'est que les pirates commencent à coder "réellement" sous linux et non plus scripter des trucs à 3 balles. -- Kevin
Emmanuel Florac
Le Thu, 22 Nov 2012 11:45:52 +0000, Kevin Denis a écrit:
Des news là dessus?
l'origine est là:
http://seclists.org/fulldisclosure/2012/Nov/94
-- Don't worry about people stealing your ideas. If it's original, you'll have to ram it down their throats. Howard Aiken, creator of the IBM/Harvard Mark 1 Computer
Le Thu, 22 Nov 2012 11:45:52 +0000, Kevin Denis a écrit:
Des news là dessus?
l'origine est là:
http://seclists.org/fulldisclosure/2012/Nov/94
--
Don't worry about people stealing your ideas. If it's original, you'll
have to ram it down their throats.
Howard Aiken, creator of the IBM/Harvard Mark 1 Computer
Le Thu, 22 Nov 2012 11:45:52 +0000, Kevin Denis a écrit:
Des news là dessus?
l'origine est là:
http://seclists.org/fulldisclosure/2012/Nov/94
-- Don't worry about people stealing your ideas. If it's original, you'll have to ram it down their throats. Howard Aiken, creator of the IBM/Harvard Mark 1 Computer
Kevin Denis
Le 22-11-2012, Emmanuel Florac a écrit :
Des news là dessus?
l'origine est là:
http://seclists.org/fulldisclosure/2012/Nov/94
rien sur la supposée faille de nginx. -- Kevin
Le 22-11-2012, Emmanuel Florac <eflorac@imaginet.fr> a écrit :
